pub enum EndpointRequest {
GetInfo {
responder: EndpointGetInfoResponder,
},
RegisterVmos {
vmo_ids: Vec<VmoInfo>,
responder: EndpointRegisterVmosResponder,
},
UnregisterVmos {
vmo_ids: Vec<u64>,
responder: EndpointUnregisterVmosResponder,
},
QueueRequests {
req: Vec<Request>,
control_handle: EndpointControlHandle,
},
CancelAll {
responder: EndpointCancelAllResponder,
},
}Expand description
Endpoint Interface. Pre-registered VMOs associated with the Endpoint are tied to the lifetime of the Endpoint. When the Endpoint is closed, all outstanding registered VMOs are unregistered, references to their handles dropped and any necessary actions for DisableEndpoint will be called.
Variants§
GetInfo
Gets endpoint information
Fields
responder: EndpointGetInfoResponderRegisterVmos
Registers and pins VMOs to the vmo_ids. Returns
- vmo: Handles to successfully registered vmo_ids. VMO IDs that are already are registered to will fail.
UnregisterVmos
Unregisters the VMOs corresponding to the vmo_ids. Returns
- failed_vmo_ids: vmo_ids that failed to unregister.
- errors: Error values that correspond 1:1 to failed_vmo_ids above.
QueueRequests
Submit Requests to queue. Processed starting with the 0th Request. Submitting a vector of Requests allows for pre-buffering.
Clients are responsible for cache management and ensuring cache coherency. The explanation to follow concerns VMOs that have been previously registered via RegisterVmos. The following rules must be followed:
-
After writing to VMO-backed buffers, the caller must call zx_cache_flush with ZX_CACHE_FLUSH_DATA before invoking QueueRequests, causing the hardware to DMA-process the buffer. This avoids both stale buffer data being DMA-read, and a concurrent race between the hardware and CPU to update the same addresses.
-
Before reading from VMO-backed buffers, the caller must call zx_cache_flush with ZX_CACHE_FLUSH_DATA | ZX_CACHE_FLUSH_INVALIDATE after the buffer contents have been DMA-written by the hardware. This implies a non-dirty cache (see #1 above) and ensures any subsequent CPU-reads fetch the previously DMA-written data from RAM.
Failing to adhere to these rules will result in the exchange of corrupted and/or stale data. If the VMO is not virtually mapped (uncommon), zx_vmo_op_range should be used in lieu of zx_cache_flush. If the usb::FidlRequest types are in use, they contain helpers for these operations.
Requests may be pre-buffered. In other words, requests may be queued for data that is not present/ready in the buffer yet. The USB Endpoint Server consuming requests does not care if the data in the buffer is ready or not and will always process requests on schedule. It is the responsibility of the USB Endpoint Client that submits requests to ensure that data is ready on schedule (taking into consideration cache management above).
- Definition of “on schedule” varies for different endpoints and controllers. In general,
this will be communicated by the
lead_timeparameter returned byGetInfo.
CancelAll
Cancels all requests. Returns
- ZX_ERR_IO_NOT_PRESENT: If device is not running, disconnected, or inactive.
- ZX_ERR_IO: If cancel failed due to an unsuccessful request.
Fields
responder: EndpointCancelAllResponderImplementations§
Source§impl EndpointRequest
impl EndpointRequest
pub fn into_get_info(self) -> Option<EndpointGetInfoResponder>
pub fn into_register_vmos( self, ) -> Option<(Vec<VmoInfo>, EndpointRegisterVmosResponder)>
pub fn into_unregister_vmos( self, ) -> Option<(Vec<u64>, EndpointUnregisterVmosResponder)>
pub fn into_queue_requests( self, ) -> Option<(Vec<Request>, EndpointControlHandle)>
pub fn into_cancel_all(self) -> Option<EndpointCancelAllResponder>
Sourcepub fn method_name(&self) -> &'static str
pub fn method_name(&self) -> &'static str
Name of the method defined in FIDL