Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Nov 2007 10:24:34 GMT
From:      Hans Petter Selasky <hselasky@FreeBSD.org>
To:        Perforce Change Reviews <perforce@FreeBSD.org>
Subject:   PERFORCE change 129490 for review
Message-ID:  <200711251024.lAPAOY8k078160@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=129490

Change 129490 by hselasky@hselasky_laptop001 on 2007/11/25 10:24:32

	
	Update documentation.

Affected files ...

.. //depot/projects/usb/src/sys/dev/usb/README#21 edit

Differences ...

==== //depot/projects/usb/src/sys/dev/usb/README#21 (text+ko) ====

@@ -258,17 +258,19 @@
   force_short_xfer
 	This flag forces the last transmitted USB packet to be short.
 	A short packet has a length of less than "xfer->max_packet_size",
-	which derives from "wMaxPacketSize".
+	which derives from "wMaxPacketSize". This flag can be changed
+	during operation.
 
   short_xfer_ok
 	This flag allows the received transfer length, "xfer->actlen" 
 	to be less than "xfer->sumlen" upon completion of a transfer.
+	This flag can be changed during operation.
 
   use_polling
 	This flag can be used with any callback and will cause the
 	"usbd_transfer_start()" function to wait using "DELAY()",
 	without exiting any mutexes, until the transfer is finished or
-	has timed out.
+	has timed out. This flag can be changed during operation.
 
 	NOTE: If polling is used the "timeout" field should be non-zero!
 	NOTE: USBD_CANCELLED is returned in case of timeout
@@ -284,12 +286,12 @@
 	2) The failing USB transfer performs a successful transfer.
 
 	The purpose of this flag is to avoid races when multiple
-	transfers are queued for execution on an USB endpoint, and
-	the first executing transfer fails leading to the need
-	for clearing of stall for example. In this case this flag
-	is used to prevent the following USB transfers from being
-	executed at the same time the clear-stall command is
-	executed on the USB control endpoint.
+	transfers are queued for execution on an USB endpoint, and the
+	first executing transfer fails leading to the need for
+	clearing of stall for example. In this case this flag is used
+	to prevent the following USB transfers from being executed at
+	the same time the clear-stall command is executed on the USB
+	control endpoint. This flag can be changed during operation.
 
 	"BOF" is short for "Block On Failure"
 
@@ -304,17 +306,26 @@
 	stored in the "xfer->max_data_length". For control transfers
 	the USB kernel will allocate additional space for the 8-bytes
 	of SETUP header. These 8-bytes are not counted by the
-	"xfer->max_data_length" variable.
+	"xfer->max_data_length" variable. This flag can not be changed
+	during operation.
 
   ext_buffer
 	Setting this flag will cause that no DMA data buffer will be
 	allocated. Instead the USB client can use its own DMA buffer.
+	This flag can not be changed during operation.
 
   manual_status
 	Setting this flag causes that the STATUS stage of a control
 	transfer needs to be sent separately like a zero-length USB
 	frame. This flag has currently no effect on non-control
 	transfers. This flag is mostly useful for the USB device side.
+	This flag can be changed during operation.
+
+  bdma_enable
+	Setting this flag allows you to load virtual buffers directly
+	into DMA. Virtual buffers are loaded by a call to
+	"usbd_set_frame_data()".  This flag can not be changed during
+	operation.
 
 - The "bufsize" field sets the total buffer size in bytes. If
   this field is zero, "wMaxPacketSize" will be used, multiplied by the



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711251024.lAPAOY8k078160>