The Bus Bridge metalanguage allows a device driver to communicate with the driver for its parent bus bridge. The device may be a leaf device or another bridge.
A driver region may use the Bus Bridge metalanguage in any of four roles. For each role there's a corresponding channel ops vector, which is registered via an associated udi_ops_init_t structure. The Bus Bridge metalanguage roles are:
Both the udi_cmos and pseudod sample drivers use the device role, and provide the udi_bus_device_ops_t vectors shown below.
|cmos_udi.c sample code (cont.)|
/* * Driver "bottom-side" entry points for the Bus Bridge Metalanguage. */
|pseudod.c sample code (cont.)|
/* * Driver "bottom-side" entry points for the Bus Bridge Metalanguage */ static udi_channel_event_ind_op_t pseudo_bus_channel_event; static udi_bus_bind_ack_op_t pseudo_bus_bind_ack; static udi_bus_unbind_ack_op_t pseudo_bus_unbind_ack;
As child devices of the parent bus bridge, the sample drivers must manage bus bindings with the bridge driver and handle interrupts coming from the bridge driver.
Each of the entries in the cmos_bus_device_ops and pseudo_bus_device_ops arrays is a function that handles one of these corresponding service calls from the UDI environment (in this case, the bus bridge driver):
|udi_channel_event_ind||Used by the environment to signal that a generic event has occurred on the other end of the channel. The type of event that has occurred, and additional parameters for the event, are contained in a udi_channel_event_cb_t control block passed as part of the service call. The sample drivers provide driver-side entry points cmos_parent_channel_event and pseudo_bus_channel_event for this call.|
|udi_bus_bind_ack||Used by a bridge driver to acknowledge binding with a child device driver (or failure to do so, as indicated by status), as originally requested by a udi_bus_bind_req operation from the driver. The sample drivers provide the cmos_bus_bind_ack and pseudo_bus_bind_ack entry points.|
|udi_bus_unbind_ack||Used by a bridge driver to acknowledge unbinding with a child device driver as originally requested by a udi_bus_unbind_req operation from the driver. The sample drivers provide the cmos_bus_unbind_ack and pseudo_bus_unbind_ack entry points.|
|udi_intr_attach_ack||Used by an interrupt dispatcher driver to acknowledge attachment of an interrupt handler (or failure to do so, as indicated by status), as requested by a udi_intr_attach_req operation. The sample drivers do not use the udi_intr_attach_req operation, and so never expect an acknowledgement. They use the environment-providedudi_intr_attach_ack_unused proxy function instead of defining an entry point.|
|udi_intr_detach_ack||Used by an interrupt dispatcher driver to acknowledge detachment of an interrupt handler, as requested by a udi_intr_detach_req operation. The sample drivers do not use the udi_intr_detach_req operation, and so never expect an acknowledgement. They use the environment-provided udi_intr_detach_ack_unused proxy function instead of defining an entry point.|
The specifics of the driver-side functions are discussed in the section ``Channel operations''.
The Bus Bridge environment service calls are described in detail in the Bus Bridge Metalanguage section of the UDI Physical I/O Specification. Also see udi_channel_event_ind(3udi).