Inter-device conflict resolution on a multimedia link

A source device communicates multimedia data to a sink device over a multimedia channel of a multimedia link. The source device comprises an interface to a full duplex control channel of the multimedia link. The source device also comprises first arbitration logic to control transfer of control data with the sink device via the full duplex control channel. The first arbitration logic ignores requests to receive inbound control data from the sink device while the source device is transmitting outbound control data to the sink device. The sink device, on the other hand, comprises second arbitration logic to control transfer of control data with the source device via the full duplex control channel. The second arbitration logic stops transmitting outbound control data via the full duplex control channel responsive to receiving a request to receive incoming control data from the source device.

TECHNICAL FIELD

The disclosed embodiments relate generally to Multimedia High Definition Link (MHL) standards, and more specifically to methods and devices that provide backward compatibility between MHL 3 devices and legacy MHL software.

BACKGROUND

Under the legacy MHL 1/2 protocol, a local MHL device communicates with a peer MHL device using a legacy MHL (MHL 1/MHL 2) link. The legacy link, in turn, has a half-duplex legacy control bus that enables exchange of control packets between the local and peer MHL devices. Additionally, in a legacy MHL device, legacy device software interfaces with a half duplex translation layer and therefore also receives or transmits control data in half duplex. Thus, in the legacy MHL 1/2 configuration, the local MHL device, the peer legacy device, the local and peer device software, as well as the legacy MHL control bus are all configured to operate in half-duplex.

Under the MHL 3 protocol, a local MHL 3 device communicates with a peer MHL 3 device using an MHL 3 link that includes a full-duplex enhanced control bus (eCBUS). Additionally, the MHL 3 device has the capability to interface with legacy MHL software through a half-duplex translation layer. But the half duplex nature of the translation layer could result in data transfer conflict, for instance, when packet receive requests arrive at the local MHL 3 device while the local device is already in the process of transmitting control data to a peer device.

SUMMARY

Accordingly, some embodiments provide a source device for communicating over a multimedia link. The source device comprises a half duplex translation layer, a link layer for coupling to a full duplex control channel of the multimedia link, and an arbitration logic to control transfer of control data with a sink device via the full duplex control channel. The arbitration logic controls the source device to ignore requests to receive inbound control data from the sink device while the source device is transmitting outbound control data corresponding to the half-duplex translation layer to the sink device through the link layer. In some embodiments, the arbitration logic comprises a state machine that controls flow of control data between the half-duplex translation layer and the full-duplex link layer.

In some embodiments, the arbitration logic initializes a packet transmission event by entering one or more transmission states for transmitting outbound control data to the sink device; and during the one or more transmission states, the arbitration logic receives a request to receive inbound control data from the sink device. In some embodiments, the one or more transmission states correspond to a header transmission state indicating a start of the packet transmission event, a higher order byte transmission state, a lower order byte transmission state, or a stop transmission state during which the source device awaits a positive or a negative acknowledgement signal from the sink device.

In some embodiments, the arbitration logic initializes a packet transmission event after asserting a transmission request signal to the link layer, and after receiving, from the link layer, a transmission grant signal authorizing access to the full duplex control channel.

In some embodiments, if the arbitration logic receives a request to receive inbound control data from the sink device after asserting a transmission request signal to the link layer of the source device and before receiving, from the link layer, a transmission grant signal, the arbitration logic aborts transmission by de-asserting the transmission request signal and processes the request to receive inbound control data from the sink device.

In some embodiments, responsive to receiving a request to receive inbound control data from the sink device, the arbitration logic determines whether the packet transmission event at the source device is completed; and in accordance with a determination that the packet transmission event is not completed, the arbitration logic ignores the request to receive inbound control data from the sink device by continuing the packet transmission event. In some embodiments, determining whether the packet transmission event at the source device is completed comprises determining whether a positive or a negative acknowledgement signal was received from the sink device corresponding to the packet transmission event.

Additionally, some embodiments provide a sink device for communicating over a multimedia link, the sink device comprising a half duplex translation layer; a link layer for coupling to a full duplex control channel of the multimedia link; and arbitration logic to control transfer of control data with the source device via the full duplex control channel. The arbitration logic aborts transmitting outbound control data via the full duplex control channel responsive to receiving a request to receive incoming control data from the source device. In some embodiments, responsive to receiving a request to receive incoming control data from the source device, the arbitration logic determines whether the packet transmission event at the sink device is completed; and in accordance with a determination that the packet transmission event is not completed, the arbitration logic suspends the packet transmission event to the source device by entering a transmission abort state and by initializing a packet receipt event to receive incoming control data from the source device. After completing the packet receipt event, the sink device may start to retransmit the aborted packet, if the transmit request from the translation layer is still asserted.

DESCRIPTION OF EMBODIMENTS

FIG. 1is a high-level block diagram of a system100for data communications, according to one embodiment. The system100includes a source device110communicating with a sink device115through one or more interface cables120,150,180. Source device110transmits multimedia data streams (e.g., audio/video/auxiliary streams) to the sink device115and also exchanges control data with the sink device115through the interface cables120,150,180. In one embodiment, source device110and/or sink device115may be repeater devices.

Source device110includes physical communication ports112,142,172coupled to the interface cables120,150,180. Sink device115also includes physical communication ports117,147,177coupled to the interface cables120,150,180. Signals exchanged between the source device110and the sink device115across the interface cables pass through the physical communication ports.

Source device110and sink device115exchange data using various protocols. In one embodiment, interface cable120represents a High Definition Multimedia Interface (HDMI) cable. The HDMI cable120supports differential signals transmitted via data0+ line121, data0− line122, data1+ line123, data1− line124, data2+ line125, and data2− line126. The HDMI cable120may further include differential clock lines clock+127and clock−128; Consumer Electronics Control (CEC) control bus129; Display Data Channel (DDC) bus130; power131, ground132; hot plug detect133; and four shield lines134for the differential signals. In some embodiments, the sink device115may utilize the CEC control bus129for the transmission of closed loop feedback control data to source device110.

In one embodiment, interface cable150represents a Mobile High-Definition Link (MHL) cable. The MHL cable150supports differential signals transmitted, for example, via data0+ line151, data0− line152. Data lines151and152form a multimedia bus for transmission of multimedia data streams from the source device110to the sink device115. In some embodiments of MHL, there may only be a single pair of differential data lines (e.g.,151and152). Alternatively, a plurality of differential data lines is provided to enable transmission (e.g., concurrently) of multiple differential signals on the multiple differential data lines. Embedded common mode clocks are transmitted through the differential data lines.

The MHL cable150may further include a control bus (CBUS)159, power160and ground161. The CBUS159is a bi-directional bus that carries control information such as discovery data, display identification, configuration data, and remote control commands. CBUS159for legacy MHL (MHL 1/2) operates in half duplex mode. On the other hand, CBUS159for MHL (MHL 3), alternatively referred to as an enhanced CBUS (eCBUS), operates in full duplex. In some embodiments, the eCBUS is single ended and provides single-ended signaling capability over a single signal wire. Alternatively, the eCBUS is differential ended (between differential lines eCBUS+ and eCBUS−) and provides differential-ended signaling capability over a differential pair of signal wires. An MHL 3 device (referred to herein as a local device) has the capability to interface with another MHL 3 device (referred to herein as a peer device) over a full duplex enhanced CBUS. For example, the source device110may be the local device if it is transmitting control information to the sink device115. Alternatively, the sink device115may be the local device if it is transmitting control information to the source device110.

Additionally, in the event that a local MHL 3 device needs to communicate with a legacy MHL device over a legacy MHL link or to operate with legacy MHL software, the local MHL 3 device has the capability to downgrade to a legacy operational mode from the MHL 3 mode. For example, a local MHL 3 device has the capability to interface with a peer MHL 1/2 device over a half-duplex CBUS.

Embodiments of the present disclosure relate to a system and MHL 3 device architecture for preserving backward compatibility with legacy MHL while allowing reuse of existing circuits and software that were used for legacy MHL. The MHL 3 device is configured to interface with a peer MHL 3 device over an MHL 3 link that includes a full-duplex enhanced control bus (eCBUS). Additionally, the MHL 3 device has the capability to interface with legacy MHL software through a half-duplex translation layer. However, data transfer conflict may arise at the half-duplex translation layer, for instance, when packet receive requests arrive at the local MHL 3 device while the translation layer is already in the process of transmitting control data to a peer device. Under these circumstances, the translation layer, by virtue of being half duplex, would be incapable of receiving the incoming packet while continuing in its own transmission. Embodiments of the disclosure relate to a set of predefined rules and priorities for data transfer between the source and sink devices that facilitate resolution of such conflict.

FIG. 2is a detailed view of a computing device200suitable for use as the source device110or sink device115fromFIG. 1, according to one embodiment. The computing device200can be, for example, a cell phone, a television, a laptop, a tablet, etc. The computing device200includes components such as a processor202, a memory203, a storage module204, an input module (e.g., keyboard, mouse, and the like)206, a display module207(e.g. liquid crystal display, organic light emitting display, and the like) and a transmitter or receiver205, exchanging data and control signals with one another through a bus201.

The storage module204is implemented as one or more non-transitory computer readable storage media (e.g., hard disk drive, solid state memory, etc.), and stores software instructions that are executed by the processor202in conjunction with the memory203. Operating system software and other application software may also be stored in the storage module204to run on the processor202.

The transmitter or receiver205is coupled to the ports for reception or transmission of multimedia data and control data. Multimedia data that is received or transmitted may include video data streams or audio-video data streams or auxiliary data, such as HDMI and MHL data. The multimedia data may be encrypted for transmission using an encryption scheme such as HDCP (High-Bandwidth Digital-Content Protection).

In one embodiment, a representation of circuits within the source device110or sink device115may be stored as data in a non-transitory computer-readable medium (e.g. hard disk drive, flash drive, optical drive). These representations maybe in the form of, for example, behavioral level descriptions, register transfer level descriptions, logic component level descriptions, transistor level descriptions or layout geometry-level descriptions.

Multimedia Source and Sink Devices

FIG. 3includes a block diagram illustrating a source device110and a sink device115communicatively coupled via a multimedia link (in particular, via control bus CBUS159), according to some embodiments. When communicatively coupled to the multimedia sink device115, the multimedia source110device transmits multimedia data streams (e.g., audio/video/auxiliary streams) to the multimedia sink device over a multimedia channel of the multimedia link. The source device110could be a portable computing device (such as a mobile phone, laptop, or hand held device) capable of sourcing multimedia content. A sink device115, on the other hand, could be a television or a display monitor capable of receiving the multimedia content that is provided to it by the source device. To transmit multimedia content to the sink device115, the source device110includes an interface (not shown) to the multimedia channel of the multimedia link; the interface transmits video and/or audio and/or auxiliary data to the sink device via the multimedia channel. In addition, the source device110exchanges control data (e.g., discovery data, display identification, configuration data, remote control commands, and USB tunneling data) with the sink device115over the full-duplex control bus (CBUS159) of the MHL 3 link. To enable this control data exchange, the source device110also includes an interface to the full duplex control channel or control bus of the multimedia link. In some embodiments, the interface to the full duplex control channel of the multimedia link includes a full-duplex link layer circuit330. Functions of the link layer330include providing link layer protocol commands, link layer flow control, bit timings, and packet timings at the local device for transfer of packet data across the control bus. The link layer330implements link layer protocols for sending and receiving control data between the source device110and sink device115across the control bus159. The link layer protocols specify schemes for framing control data (e.g. encoding, protocol, arbitration, flow control, bit timings, packet timings) into link layer packets. For example, for legacy MHL, the link layer330may generate link layer packets for CBUS related data that include one or more sync bits, header bits, control bits, data or command bits for translation layer data, and parity bits. The link layer330also decodes incoming packets of CBUS related data from the control bus. The link layer330additionally controls timing and synchronization of packets transmitted across the control bus159using a TDM (Time Division Multiplexer). TDM divides the use of the control bus into time slots, some of which are for transmitting CBUS related data and some of which are for receiving CBUS related data. By virtue of providing multiple time slots of the control bus, the TDM enables the source device110to serve multiple virtual channels. The link layer330interfaces with software at the source device110via a half duplex translation layer circuit310. In other words, the half duplex translation layer310provides a half duplex interface with the device software. The translation layer circuit310additionally facilitates selection of one among several different logical data channels, such that only one logical data channel has access to the control bus159at a time. Examples of logical data channels in MHL include DDC (Display Data Channel) and MSC (MHL Sideband Channel). Each logical data channel follows a different flow control protocol for transfer of a different type of control information. Each logical data channel may use different flow control packets. For example, DDC may use seven different flow control packets. MSC may use eighteen different flow control packets. The half-duplex translation layer circuit310controls flow of control information between the source device110and sink device115. Specifically, the half-duplex translation layer circuit310generates flow control packets and control data packets that are transmitted to the link layer330. The half-duplex translation layer310also receives flow control packets and control data packets from the link layer330. The half-duplex translation layer circuit310only operates in half-duplex, meaning that it can either transmit or receive data through its internal communication interface to the link layer, but cannot do both at the same time.

Therefore, the source device110also includes arbitration logic320to mediate the communication (signaling) between the full-duplex link layer330and the half-duplex translation layer310. The arbitration logic320controls transfer of control data with the sink device115via the full duplex control channel or control bus159. In some embodiments, the arbitration circuit320comprises a state machine that controls flow of control data between the half-duplex translation layer circuit310and the full-duplex link layer circuit330.

Similarly, the MHL sink device115, also includes an interface to the multimedia channel of the multimedia link; the interface receives video and/or audio and/or auxiliary data from a source device110via the multimedia channel. The sink device115also includes an interface to the full duplex control channel/bus159of the multimedia link. In some embodiments, the interface to the full duplex control channel of the multimedia link includes a full-duplex link layer circuit360. Further, the sink device115comprises a half-duplex translation layer circuit380to interface with software at the sink device115. The sink device115therefore includes its own arbitration logic370to interface or mediate between the full duplex link layer360and the half duplex translation layer380. The arbitration logic370at the sink device115also functions to control transfer of control data to and from the source device110via the full duplex control channel/bus159. In some embodiments, the arbitration logic370of the sink device115also comprises a state machine that controls flow of control data between the half-duplex translation layer circuit380of the sink device and the full-duplex link layer circuit360of the sink device115. The full-duplex link layer circuit360, the half-duplex translation layer circuit380, and the arbitration logic370of the sink device115share various attributes and functions, respectively, with the full-duplex link layer circuit330, the half-duplex translation layer circuit310, and the arbitration logic320of the source device110. For brevity, these details are not repeated here.

Inter-Device Communication in the Absence of Conflict

As described above with reference toFIG. 3, the translation layer circuits310and380of both the source device110and sink device115are configured to generate and receive control information. The translation layers operate in half duplex and interface with legacy device software in half duplex. By virtue of being half duplex, the translation layer of either device is configured to perform either one of packet data transmission or packet data receipt at any given time through its internal interfaces to the arbitration logic and device software of that respective device, but not both concurrently. In other words, referring again toFIG. 3, the translation layer310or380can support packet data transmission from a local device to a peer device by obtaining a control packet from software at the local device, processing the packet, and providing the packet to the link layer330or360respectively (via the arbitration logic320or370respectively) for further transmission to the peer device. Alternatively, the translation layer310or380can support packet receipt at the local device from a peer device by performing the reverse operations—obtaining a received packet from the arbitration logic320or370respectively, processing the packet, and providing the packet to software at the local device. However, the translation layer310or380respectively cannot support both packet data transmission and packet data receipt concurrently since it operates in half-duplex.

This constraint resulting from the half duplex nature of the translation layer at the source device110or the sink device115results in either device being able to perform either one of control data transmit or control data receive at any given instance, but not both. Although this constraint at the translation layer310or380respectively could result in a potential translation layer conflict when both devices attempt to concurrently exchange control data, such constraint would not result in a conflict when only one of the source or sink devices attempts to transmit control data at any given time.

For example, in a first scenario, when the source device110is configured to transmit control data over the control bus159to the sink device115, but the sink device115does not attempt to transmit control data back to the source device110, the sink device115is receptive to receiving the control data originating from the source device110. Under such circumstances, there is no conflict between the source and sink devices. In the absence of such conflict, the source device110and the sink device115may communicate control data seamlessly over the full-duplex bidirectional enhanced control bus159(eCBUS) of the MHL 3 link.

FIGS. 5A-5Binclude block diagrams illustrating packet transmission from a source device110to a sink device115in the absence of a data transfer conflict, according to some embodiments.

In this scenario, the source device110initiates transmission of control data to the sink device115by requesting access to the control bus159. Specifically, in some embodiments, translation layer310at the source device110transmits a transmit request to the arbitration logic320which, in turn, requests the link layer330to obtain access to CBUS159. The link layer330of the source device110obtains access to the CBUS159and asserts a local grant signal to the arbitration logic320of the source device110indicating that the source device110has gained access to the control bus159. Then, the source device110proceeds to transmit a control packet (Packet Xmit) to the sink device115. Specifically, the translation layer310of the source device initiates packet transmission (Packet Xmit) to transmit control data to the arbitration logic320. The arbitration logic320enters one or more transmission states to propagate the controls packets from the translation layer310to the link layer330.

The sink device115receives the control packet (Packet Rcv) from the source device110. Upon receiving the control packet, the sink device115responds (Send Ack) with a positive or negative acknowledgement signal (Send NACK byte) corresponding to that control packet. In particular, the arbitration logic370at the sink device115may run an error check to determine whether the packet was received in a good (error free) or bad (error-ridden) condition and based on that determination, generate the ACK or NAK signals respectively. Upon receiving the ACK or NAK signal (Rcv Ack), the arbitration logic320at the source device110may send an indication (Xmit Done) to the translation layer310of the source device110, indicating completion of the transmission event. This completes the transmission process from the source device110to the sink device115in the absence of inter-device transmission conflict.

Conversely, in a second scenario, if the source device110itself is not configured to transmit control data to the sink device115at a time when the sink device115attempts to transmit control data over the control bus159to the source device110, then at such time, the source device110is receptive to receiving the control data originating from the sink device115. Therefore, no conflict arises at either source device110or sink device115.

FIGS. 6A-6Binclude block diagrams illustrating packet transmission from a sink device115to a source device110in the absence of a data transfer conflict, according to some embodiments. In this scenario, the sink device115initiates transmission of control data to the source device110by requesting access to the control bus159. The access request from the arbitration logic370may be responsive to the transmission request asserted by the translation layer380at the sink device115. Upon gaining access to the control bus159, the sink device115proceeds to transmit a control packet (Packet Xmit) over the control bus159to the source device110. To do so, the translation layer380propagates a control packet (Packet Xmit) to the arbitration logic370at the sink device115, which in turn, propagates the control packet to the link layer360. Upon receiving the control packet (Packet Rcv), the source device110may positively or negatively acknowledge that control packet (Send Ack) to the sink device115. In particular, the arbitration logic320at the source device110may run an error check to determine whether the packet was received in a good (error free) or bad (error-ridden) condition and based on that determination, generate the ACK or NAK signals respectively. Upon receiving the ACK or NAK signal (Rcv Ack), the sink device115completes the transmission process; for example, a transmit done (Xmit_Done) signal is sent from the arbitration logic370of the sink device115to the translation layer380of the sink device115to indicate end of transmission for that packet.

Inter-Device Communication in the Presence of Conflict

Under the circumstances when both the source device110and the sink device115attempt to transmit control data over the control bus159concurrently, substantially concurrently, or within a specified interval of each other, a potential protocol conflict can arise on the control bus159as well at the half-duplex translation layer of the source or sink devices. A set of predefined rules and priorities need to be defined a-priori in order to handle translation layer conflict arising under these circumstances.

In the MHL 3 configuration, the source device110transmits multimedia data streams (e.g., audio/video/auxiliary streams) to the sink device115over a multimedia channel. In other words, the source device110is the originator or provider of the multimedia content and the sink device115is the receiver or recipient. By virtue of being the originator of the multimedia content, the source device110is ascribed multimedia data transmission priority over the sink device115. The sink device115, on the other hand, has a more passive ‘follower’ role in the multimedia data communication process and is therefore ascribed a lower priority than the source device110. Thus, if conflict arises during the process of exchanging control data, the source device110gains priority over the control bus159. Stated differently, when communicatively coupled to the sink device115, the source device is given transmission priority to transmit control data to the sink device over the full duplex control channel in the event of a control data transfer conflict arising on the full duplex control channel. These scenarios are described further with reference to the flowcharts illustrated inFIGS. 4A-4Bas well as the block diagrams ofFIGS. 7A-7B and 8A-8B.

Conflict Handling at the Source Device

FIG. 4Aillustrates a flowchart of a conflict resolution workflow performed on an MHL 3 source device when interfacing with an MHL 3 sink device via an MHL 3 link, according to some embodiments.FIGS. 7A-7Binclude corresponding block diagrams illustrating conflict handling signaling performed at a source device110, according to some embodiments.

By virtue of being the originator of the multimedia content, the source device is ascribed transmission priority over the sink device. By virtue of being the ‘follower’ or recipient, the sink device has the lower priority. If inter-device conflict arises while the source device is transmitting outbound control data to the sink device, priority is given to the source device—source to sink device transmission prevails at the expense of an incoming receive request from the sink device. Specifically, the arbitration logic of the source device ignores requests to receive inbound control data from the sink device while the source device is transmitting outbound control data to the sink device. This is described further with reference toFIG. 4AandFIGS. 7A-7B. For simplicity and ease of explanation,FIG. 4AandFIGS. 7A-7Bare described together.

As shown inFIG. 4A, the source device starts410transmission of control data. For example, referring toFIGS. 7A-7B, the arbitration logic320at the source device110receives a control data transmission request from the translation layer310of the source device110. The arbitration logic320then initializes a packet transmission event by entering one or more transmission states for transmitting outbound control data to the sink device115. In some embodiments, the arbitration logic320initializes a packet transmission event (Packet Xmit) after asserting a transmission request signal to the link layer330of the source device110, and after receiving, from the link layer330, a local transmission grant signal authorizing access to the full duplex control channel/bus159. A control packet that includes three bytes of control data—including a header byte, a higher order byte, and a lower order byte—is received from the translation layer310and transmitted through the link layer330. In such embodiments, the one or more transmission states correspond to a header transmission state, a higher order byte transmission state, and a lower order byte transmission state. In addition, the transmission states also include a stop transmission state during which the source device110awaits a positive or a negative acknowledgement signal from the sink device115.

Referring again toFIG. 4A, the source device110receives415a packet receive request from the sink device115. As illustrated inFIGS. 7A-7B, the translation layer380at the sink device115asserts a transmit request (Xmit Req) to transmit packets to the source device110. This transmit request (Xmit Req) is propagated via the arbitration logic370and the link layer360, over CBUS159, to the source device110. The source device in turn receives this request as a packet receive request (Rcv Req) corresponding to a request to receive inbound control data from the sink device115. As illustrated inFIG. 4A, in some embodiments, the arbitration logic makes a determination418as to whether the packet receive request arrived before the source device gained access to the control bus. In such embodiments, if the arbitration logic320receives a request to receive inbound control data from the sink device115after asserting a transmission request signal to the link layer330of the source device110and before receiving, from the link layer330, a transmission grant signal (i.e., before gaining access to the control bus), the arbitration logic320aborts420transmission by de-asserting the transmission request signal and processes the request to receive inbound control data from the sink device115.

However, in the alternate, if the arbitration logic320receives the packet receive request (Rcv Req) from the sink device115after receiving a transmission grant and while the arbitration logic320is in one of the packet transmission states, the arbitration logic320proceeds to complete transmission; i.e. the source device110ignores422the receive request (Rcv Req) originating at the sink device115. If the arbitration logic320of the source device110has already initiated packet transmission (Packet Xmit), then, responsive to receiving a request (Rcv Req) to receive inbound control data from the sink device115, the arbitration logic320determines whether the packet transmission event at the source device110is completed. In some embodiments, determining whether the packet transmission event at the source device110is completed comprises determining whether a positive or a negative acknowledgement signal was received from the sink device corresponding to the packet transmission event. In accordance with a determination that the packet transmission event is not completed, the arbitration logic320ignores the request to receive inbound control data from the sink device115by continuing the packet transmission event (as illustrated in FIG.7B). In other words, the source device ignores420packet receive request if in a transmission state.

The source device then completes425transmission. For example, as illustrated inFIG. 7C, the source device receives a positive or negative acknowledgement (Rcv Ack) signal from the sink device (Send Ack). The arbitration logic320at the source device exits the transmission states by transmitting a transmit done (Xmit Done) signal to the translation layer310indicating an end of the packet transmission event.

Upon completing transmission, the arbitration logic320enters430an idle state. Additionally, if the packet receive request is detected again, the source device optionally processes430the packet receive request. To do so, the arbitration logic320may enter a receive state during which control data from the sink device is received.

Conflict Handling at the Sink Device

FIG. 4Billustrates a flowchart of a conflict resolution workflow performed on an MHL 3 sink device when interfacing with an MHL 3 source device via an MHL 3 link, according to some embodiments.FIGS. 8A-8Binclude block diagrams illustrating conflict handling signaling performed at the sink device115, according to some embodiments. For simplicity and ease of explanation,FIG. 4BandFIGS. 8A-8Bare described together.

Again, since the sink device is the ‘follower’ or recipient of the multimedia content, the sink device has the lower transmission priority. If inter-device conflict arises while the sink device is transmitting outbound control data to the source device, priority is given to the source device—sink to source device transmission is aborted (e.g., temporarily suspended) in favor of an incoming receive request from the source device. In other words, the arbitration logic of the sink device stops transmitting outbound control data via the full duplex control channel responsive to receiving a request to receive incoming control data from the source device. This is described with reference toFIG. 4andFIGS. 8A-8B.

First, as illustrated inFIG. 4Bthe sink device starts460transmission of control data. For example, referring toFIG. 8A, the arbitration logic370receives a control data transmission request from the translation layer380. The arbitration logic370then requests and is granted access to the control bus159. After receiving access to the control bus159, the arbitration logic370initializes a packet transmission event by entering one or more transmission states for transmitting outbound control data to the source device115. As described above, in some embodiments, the transmitted packet has 3 bytes of control data—the header, a higher order byte, and a lower order byte. Thus, in such embodiments, a transmission event includes a header transmission state indicating a start of the packet transmission event, a higher order byte transmission state, and a lower order byte transmission state. The transmission states at the sink device115also include a stop transmission state during which the source device110awaits a positive or a negative acknowledgement signal from the sink device115.

Returning toFIG. 4B, the sink device receives465a packet receive request (e.g., a request to receive inbound control data) from the source device. In some embodiments, as illustrated inFIG. 8A, the sink device115receives the packet receive request (Rcv Req) after gaining access to the control bus159and, after the arbitration logic370at the sink device115has initiated a packet transmission event (Packet Xmit) by entering one of the transmission states. In other words, the sink device115receives the request to receive inbound control data (Rcv Req) during one or more of its transmission states. Responsive to receiving the request to receive inbound control data from the source device110, the arbitration logic370at the sink device determines whether the packet transmission event at the sink device115is completed. For example, the arbitration logic370determines whether a positive or a negative acknowledgement signal was received from the source device110corresponding to the transmitted packet for that packet transmission event.

If the sink device115receives the request to receive inbound control data from the source device110during the packet transmission event, the sink device aborts470transmission. In other words, based on a determination that the packet transmission event is not completed, the arbitration logic at the sink device suspends the packet transmission event to the source device by entering a transmission abort state. For example, as illustrated inFIG. 8B, arbitration logic370at the sink device115sends a transmit abort (Xmit Abort) signal to translation layer380at the sink device115. Upon receiving the transmit abort, the translation layer380at the sink device115suspends (e.g., temporarily, for a specified period of time) its transmission state.

In some embodiments, along similar lines as described with reference to the source device110, if the sink device115receives the packet receive request (Rcv Req) from the source device110after requesting access to the control bus159but before gaining access to the control bus, the sink device110may still abort the transmission event. But, in contrast to the source device110, which ignores a receive request that is received after the source device110obtains access to the control bus, the sink device115aborts transmission even if the request is received from the source device110after the sink device gains access to the control bus—in favor of processing the receive request originating at the source device110. Thus, regardless of the relative timing of the receive request from the source device in relation to the sink device obtaining access to the control bus, the source device request is favored at the expense of the sink device transmission event.

Returning toFIG. 4B, upon aborting transmission, the sink device115processes475packet receive request. For example, referring toFIG. 8B, arbitration logic370at the sink device115initializes or enters a packet receipt event to receive incoming control data (Packet Rcv) from the source device110. Control data is received during the packet receipt event. In some embodiments, the arbitration logic enters one or more packet receive states to receive and process the inbound control data.

Then, after completing packet receipt, as illustrated inFIG. 8C, the sink device (arbitration logic370) transmits a positive or negative acknowledgement signal (Send Ack) to the source device (Send Ack). The source device110receives the acknowledgement (Rcv Ack) signal and the arbitration logic320at the source device100exits the transmission states by transmitting a transmit done (Xmit Done) signal to the translation layer310indicating an end of the packet transmission event.

Referring toFIG. 4B, after completing packet receipt, the sink device optionally restarts480transmission of control data. In some embodiments, responsive to completing the packet receipt event, the arbitration logic370of the sink device115enters an idle state and determines whether a request to transmit outbound control data is asserted again at the sink device115. If the transmit request (Xmit Req) is detected at the sink device115, the arbitration logic370at the sink device115resumes the packet transmission event (Packet Xmit) by re-entering the one or more transmission states for transmitting the outbound control data to the source device110.

In some embodiments, for the single transmission event described with reference toFIG. 4A-4B, 5A-5B, 6A-6B, 7A-7B, or8A-8B, the control data may comprise a plurality of control bytes. In such embodiments, the plurality of control bytes may be transmitted non-continuously, in sub-portions (e.g., 1 byte at a time), or intermittently (e.g., interleaved or temporally separated by specified durations of time). For example, various sub-portions of a single control packet may be transmitted during a plurality of distinct and non-adjacent TDM timeslots of the control bus159. For example, if the control bus159is divided into ‘n’ TDM timeslots per TDM period, and a single control packet for a single transmission event comprises 3 bytes of control data (including a first, second, and third control byte), the first byte may be transmitted during a specified (e.g., predefined) TDM timeslot of a first TDM period, the second byte may be transmitted during the corresponding TDM timeslot of a next (second consecutive) TDM period, and the third byte may be transmitted during the corresponding TDM timeslot of the subsequent (third consecutive) TDM period. Thus, in this example, although the three control bytes may not be transmitted continuously or contiguously in time, but rather over three distinct TDM periods, mutually separated from one another by one or more TDM timeslots, it should be understood that the entire event corresponding to the transmission of the three control bytes as well as the receipt of the ACK/NAK signal from the peer device is considered to be one single transmission event corresponding to that single control packet.

Beneficially, embodiments of this disclosure permit reusability and backwards compatibility of one or more components of the legacy MHL device when interfacing with an enhanced MHL device via an enhanced MHL 3 link. In particular, the legacy half duplex translation layer can be reused to interface with both the legacy MHL 1/2 software as well as with a full duplex eCBUS of the enhanced MHL (MHL 3) link. Potential translation layer conflicts arising at the source or sink devices can be averted or resolved by enforcing the predefined set of transmission rules and priorities disclosed herein. Therefore, embodiments of the disclosure enable reusability of legacy software originally designed for compatibility with components of the legacy MHL device and legacy MHL link, with the enhanced (MHL 3) architecture.