BACKGROUND

|0001] A data port may transfer data or power between a plurality of devices. The data port may be a Universal Serial Bus (USB) port, an Institute of Electrical and Electronics Engineers (IEEE) 1394 port, a Telecommunications Industry Association (TiA}-232 port, a Mini DispiayPort, a High-Definition Multimedia Interface (HDMI) port, a Digital Visual Interface {DV!) port, an external peripheral component interconnect express (PCSe) port, or the like. The data port may include a plurality of pins, such as a data pin, a high speed transmit pin, a high speed receive pin, a configuration pin, a ground pin, a power pin, or the like. In some examples, the data port may include pairs of pins for data communication (e.g., a pair of data pins, a pair of high speed transmit pins, a pair of high speed receive pins, etc.). Separate pins may be used for data communication and for power transfer. For example, the power and ground pins of the data port may be used to deliver direct current (DC) power. As used herein, the term "signal pin" refers to a data pin, a high speed transmit pin, a high speed receive pin, or a configuration pin.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 is a block diagram of an example system to request a rapid reversal of a power transfer,

[0003] Figure 2 is a block diagram of another example system to request a rapid reversal of a power transfer.

[0004] Figure 3 is a flow diagram of an example method to request a rapid reversal of a power transfer.

[0005] Figure 4 is a flow diagram of another example method to request a rapid reversal of a power transfer,

[0006] Figure 5 is a block diagram of an example device to deliver power in response to a request for a rapid reversal of a power transfer.

[0007] Figure 6 is a block diagram of another example device to deliver power in response to a request for a rapid reversal of a power transfer. DETAILED DESCRIPTION

10008] A first device may transfer power to a second device via the data ports of each device. The devices may be able to negotiate the power to be transferred and perform power ro!e swaps. The negotiation of the power to be transferred may change how much power is transferred between the devices. A power role swap may change the direction thai power flows between the devices, in an exarnpie, the devices may perform a power swap so the second device is transferring power to the first device. After the power role swap, the transfer power may be small, so the devices may negotiate for more power to be transferred.

|0009] To perform a power swap, for example, one of the devices may request the power swap, and the other device may accept the request, if the first device was transferring power to the second device before the power swap request, the second device may transition to a standby state. The first device may transition to a standby state and may send a ready indication when it has done so. The second device may transition to a state where it is able to transfer a power at a default rate to the first device and may send a ready indication when it has done so. The first device may draw power from the first device at the default rate. The default rate may be small. For example, it may be the smallest non-zero rate for transferring power.

0010] The devices may negotiate for more power by determining a power policy to be used to transfer power. As used herein, the term "power policy" refers to the voltage and current used to transfer power. The power policy may aiso include the power source from which the source device receives power (e.g., a fixed supply with a well-regulated voltage output, a battery, a variable supply, etc.). The power policy may be specified by indications of the voltage, current, power, or the like to be used to transfer power. For example, the power policy may be specified by a voltage, a maximum current, and an operating current to be used to transfer power. Alternatively, or in addition, for a variable supply, the power policy may be specified by a maximum voltage, a minimum voltage, a maximum power, and an operating power to be used to transfer power.

[0011] To negotiate the power policy, the second d vice may indicate the power policies at which it is able to transfer power. The first device may request a power policy at which it would (ike to receive power. The second device may send a response accepting or rejecting the request. If the request is accepted, the first device may go to a different state, such as a standby state. The second device may transition to a state in which it is able to provide power according to the requested power poiicy and may send a ready indication when it has done so. The first device may draw power at the requested power poiicy in response to the ready indication.

|0012| in an example, a second device without a battery may be delivering power to a first device with a battery when a power source for the second device is removed. For example, a connection delivering power to the second device may be unplugged. To continue operation, the first and second device may need to perform a power swap and negotiate a power policy sufficient to power the second device or any devices connected to the second device, However, it may take a significant amount of time to perform the power swap and the negotiation. Power may be iost before the power swap and the negotiation are complete. The first device may then need to detect that the second device has lost power and provide power at a default power poiicy. Afterwards, the devices may negotiate a power policy sufficient to power the second device or any devices connected to the second device. Thus, the second device may experience a ioss of power for a prolonged period. Accordingly, there is a need for a way to provide power rapidiy from the first device to the second device in response to a loss of power at the second device.

I00133 Figure 1 is a block diagram of an example system 100 to request a rapid reversal of a power transfer. The system 100 may include a controller 110. A first data port 20 and a second data port 130 may be electricai!y coupled to the controller 110. As used herein, the term "controller" refers to hardware (e.g., a processor, suc as an integrated circuit, or analog or digital circuitry) or a combination of software (e.g., programming such as machine- or processor- executable instructions, commands, or code such as firmware, a device driver, programming, object code, etc.) and hardware. Hardware includes a hardware eiement with no software elements, such as an application specific integrated circuit (ASIC), a Fieid Programmable Gate Array (FPGA), etc. A combination of hardware and software includes software hosted at hardware (e.g., a software module that is stored at a processor-readable memory, such as random access memory (RAM), a hard-disk or solid-state drive, resistive memory, or optical media such as a digitai versatile disc {DVD}, or executed or interpreted by a processor), or hardware and software hosted at hardware. As used herein, the term "data port" refers to an interfac to mechanically and electrically couple with a data conducting cable. The cable may include dedicated wires for carrying user data and separate dedicated wires For carrying power.

[001 J The controller 110 may cause the first data port 120 to receive power. For example, a cable may be connected to the first data port 120, and the cable may transfer power from an external device, an alternating current (AC)-to-DC converter, or the like. The controller 110 may cause the second data port 130 to output at least a portion of the received power. For example, a cable may be connected to the second data port 130, and the second data port 130 may transfer power to the cable for delivery to an externa! device or the like.

[0015] The controller 110 may detect an impending loss of power to the first data port 120. For example, the controller 10 may detect that a cable coupled to the first data port 120 is being disconnected. Alternatively, or in addition, the controller 110 may detect that a remote device is being disconnected from the cabie. In an example, the controller 110 may receive an indication of the impending loss of power. For example, a remote device may detect an impending loss of power and transmit an indication of the impending loss of power to the controller 110 (e.g., via the first data port 120).

[0016] The controller 110 may cause the second data port 130 to transmit an urgent power request. For example, the controller 110 may cause the second data port 130 to transmit the urgent power request to a remote device coupled to the second data port 130, The urgent power request may indicate to the recipient that the system 100 is about to lose power and needs to receive power without performing a power role swap and negotiation. The system 100 may be able to receive power via the second data port 130, for example, in response to the urgent power request. [0017] Figure 2 is a block diagram of another example system 200 to request a rapid reversai of a power transfer. The system 200 may include a controller 210. The system 200 may also include first, second, and third data ports 220, 230, 240 coupled to the controller 210. in the illustrated example, the second data port 230 may be connected to a computing device 250 by a cable. The third data port 240 may be connected to a first display 260. The first data port 220 may have been previously connected to a second display 270, For example, a cable connecting the first data port 220 to the second display 270 may be in the process of being removed. In other examples, the system 200 may be coupled to an external hard drive, additional computing devices, peripherals, or the like. In some examples, the system 200 may be part of a data port hub, a computing device, a display device, or the like.

|0018] The system 200 may initially have received power from the computing device 250. The controller 2 0 may have determined, for example, that the second display 270 was receiving power from a fixed supply, such as the power grid (e.g., via an AC-to-DC converter). For example, the controller 210 may have received an indication of the power policies supported by the second display 270 for delivering power, which may have included an indication the second display 270 was receiving power from the fixed supply. Accordingly, the controller 210 may have decided that the system 200, the compuiing device 250, or the first display 260 should receive power from the second display 270. The controller 210 may have received indications of the power policies supported b the computing device 250 and the first display 280 for receiving power. Th indications of supported power policies may have been received from the computing device 250, the first display 260, or the second display 270 in response to requests from the controller 210 for such information.

JQ019] The controller 210 may have negotiated with the second display 270 to receive power from the second display 270 at a power policy sufficient to powe the system 200, the computing device 250, the first display 280, etc. The controller 210 may have negotiated a power swap with the compuiing device 250. The controller 21 may have negotiated with each of the computing device 250 and the first display 260 to deliver power to the computing device 250 and the first display 280 at power policies sufficient to support full functionality of each, in some examples, the controller 210 may negotiate with the computing device 250 to deliver power at a power policy sufficient to charge a battery,

|0020] The controiier 210 may detect the impending loss of power to the first data port 220. For example, a cable connected to the first data port 220 may be in the process of .being disconnected. The signal pins of the cable may be Sanger than the power pins. The controiier 210 may detect that the signal pins have been disconnected while the power pins are still connected. Alternatively, or in addition, the system 200 may store some power, for example, capaeitively, and the controller 210 may detect tha the cabie has been disconnected while some stored power remains. In an example, the controller 210 may detect the impending loss of power by receiving from the second display 270 an indication that the second display 270 detected an impending loss of power, an indication that the second display 270 Is stopping delivery of power (e.g., a hard reset, a soft reset, a request for a power role swap, etc), or the like.

|0021] The controiier 210 may transmit an urgent power request to the computing device 250 based on detecting the impending loss of power. The urgent power request may be readabie at a physical layer to ailow for quicker processing. For example, the urgent power request may include or consist of a preamble and a message identifier indicating the message is an urgent power request. In a USB example, the message identifier may be an ordered set including the USB symbols RST-2, RST-2, Syne-3, Sync-3 or the iike. Alternatively, or in addition, the urgent power request may be indicated by an identifier in the payioad of a message and processed by a higher layer. The controiier 210 may transmit the urgent power request using a power pin, a ground pin, a configuration pin, a data pin, a high speed transmit pin, or the like.

[0022] The controller 210 may cause the second data port 230 to decrease the power being deiivered to the computing device 250 after transmitting the urgent power request. If the urgent power request is readable at the physical layer, the controiier 210 ma cause the second data port 230 to decrease the power being delivered without waiting for response, The controiier 210 may cause the second data port 230 to decrease the power immediately after transmission or may wait a predetermined time after transmission before causing the second data port 230 to decrease the power, if the urgent power request is indicated by an identifier in a message payload, the controller 210 may cause the second data port 230 to decrease the power after an acknowiedgement of a cyclic redundancy check (CRC) is received, after an acceptance is received, a predetermined time after transmission, or the like,

|0023j in the illustrated example; the computing device 250 may receive and evaluate the urgent power request. The computing device 250 may deliver power to the second data port 230 within a predetermined time of receiving the urgent power request. In an example, the computing device 250 may deliver power to the second data port 230 at a previously negotiated power policy. For example, the computing device 250 may have been transferring power to the system 200 at a negotiated power policy before a power role swap was performed and the second display 270 provided power. The computing device 250 may deliver power at that negotiated power policy rather than reverting to a default power policy where minimal power is transferred,

|0024| Alternatively, or in addition, the controller 210 and the computing device 250 may negotiate a tailback power policy, and the computing device 250 may deliver power at the negotiated power policy in response to receiving the urgent power request. For example, the computing device 250 may indicate the power policies at which it is capable of providing power. The controller 210 may determine how much power it requires and may request a fallback power policy based on the amount of power required. The computing device 250 may accept or reject the requested fallback power policy. If the computing device 250 accepts the requested fallback power policy, the computing device 250 may deliver power at the fallback power policy when it receives an urgent power request,

[0025] The controller 210 may determine which fallback power policy to request based on a locai power requirement or a power requirement of another device connected to the system 200. In the illustrated example, the controller 210 may determine its local power requirement and a power requirement of the first display 260, and the controller 210 may select a fallback power policy based on the power requirements (e.g., based on a sum, a maximum, etc. of the voltages, operating currents, maximum currents, etc. required), if the devices connected to the system 200 change, the controller 210 may negotiate a new fallback power policy. For example, if first display 260 was initially unconnected from the third display port 240, the controller 210 may have negotiated a fallback power policy sufficient to support itself only. The controller 210 may have detected the connection of the first displa 280 to the third data port 240 and may have negotiated a ne fallback power policy sufficient to power the controller 210 and the first display 260, In some examples, the device from which power is to be received (e.g., the computing device 250) may not be included in the power requirements, and the current power source (e.g., the second display 270) may or may not be included in the power requirements,

[0026] In the illustrated embodiment, the computing device 250 may have been displaying an image on the first display 260 when the second display 270 was disconnected from the system 200. The system 200 may have been transferring data from the computing device 250 to the first display 280 while it was transferring power from the second display 270 to the computing device 250 and the first display 260. When an impending loss of power was detected, the controller 210 may have caused the second data port 230 to transmit the urgent power request to the computing device 250. When power was received from the computing device 250, the controller 210 may have caused the third data port 240 to deiive at least a portion of the power to the first display 260 so that the first display 260 could continue operation. Because the controller 210 transmitted an urgent power request to respond to the impending loss of power, there may have been no or minimal interruption to operation of the first display 250. In contrast, there would have been a prolonged interruption to the operation of the first display 250 if a power swap and negotiation of a higher power policy or a detection of the power loss and negotiation of a higher power policy were performed by the controller 210 and the computing device 250.

[0027] Figure 3 is a flow diagram of an example method 300 to request a rapid reversal of a power transfer. At block 302, the method 300 may include delivering power to a remote device. For example, DC power may be delivered to a data port of the remote device via a cable. At block 304, the method 300 may include determining an amount of power to receive from the remote device. The amount of power to receive from the remote device may be the amount of power required if a current power source stopped providing power,

|0028] Block 306 may include transmitting a request to the remote device to establish a fallback power policy based on the amount of power determined at biock 304. !n an example, the remote device may have provided an indication of power policies it is capable of providing. The faiiback power policy may be selected based on the power policies the remote device can provide and the required amount of power. The transmission may indicate the selected fallback power policy. Block 308 may include receiving an acceptance of the fallback power policy from the remote device. The acceptance may indicate that the remote device is willing and able to provide power at the fallback power policy in the event that the current power source stops providing power. Referring to Figure 1 , the controlle 110 or the second data port 130, for example, may perform blocks 302, 304, 308, or 308.

|0029] Figure 4 is a flow diagram of another example method 400 to request a rapid reversal of a power transfer, At block 402, the method 400 ma include delivering power to a remote device. The power may be delivered to a remote device that is also able to deliver power. Block 404 may include determining a local power requirement, Block 406 may include determining a power requirement of another device (e.g., a device to which power is currently being transferred). For example, the local power requirement and the power requirement of the other device may be determined based on how much power will be needed locall and at the othe device in the event of a loss of power from a current power source. Determining the power requirement may include determining a voltage required, determining an operating current, determining a maximum current, determining an operating power, determining a maximum power, determining a power source required, or the like. The amount of power required by the other device may be determined based on a currently negotiated power policy, based on a previous indication of its power requirements, by requesting an indication of its power requirements, or the like, |G03G] At block 408, the method 400 may include selecting a power policy based on the local powe requirement and the power requirement of the other device. The power policy may be selected based on a maximum, a sum, or the iike of the voltages, operating currents, maximum currents, operating powers, maximum powers, or the like of the power requirements. For example, the power policy may be selected based on a maximum of the voltages and based on a current sufficient to provide the operating current of each power requirement at the voltage of that power requirement. Alternatively, or in addition, the power po!icy may be selected based on a current sufficient to provide a power reserve able to satisfy a maximum current of at !east one power requirement. In some examples, the remote device may have indicated power policies at which it is capable of providing power. The power policy may be selected: based on. the indicated power policies.

[0031] Block 410 includes transmitting a request to the remote device to establish a fallback power policy. The power policy selected based on the power requirements at block 408 may be requested to be the fallback power policy. The request may indicate that it is contingent on a loss of power from a current source. For example, an indication of the message type for a fallback request may be distinct from the indication of the message type for a request for immediate power. The request may also include a data object indicating the selected power policy. At block 412, the method 400 may include receiving a rejection of the fallback power policy. For example, the remote device may have previously indicated that it could provide power at a particular power policy but now may not be able to do so. The rejection may indicate that the remote device will not provide power at the requested power policy if an urgent power request is received . In some examples, after a rejection of a fallback request, the remote device may provide power at a previously negotiated fallback power policy if it receives an urgent power request. Alternatively, after a rejection of a fallback request, the remote device may not provide power or may only provide power at a default power policy if it receives an urgent power request.

[0032] At block 414, the method 400 may include selecting a different power policy. The different power policy may be selected by determining a device currently receiving power should stop receiving power if power from a current power source is Sost. For example, a device may have indicated that it can give back power if needed, so the different power policy may be selected based on the minimum power needed by the device that can give back power, Aiternativeiy, or in addition, it may be decided that a device should stop receiving power if power from a current power source is lost. In an example, an acceptance may have been received at block 412, and the different power policy may be selected based on another device being connected. Block 418 may include transmitting a request to establish a different fallback power poiicy. The request may indicate that the different power policy selected at biock 414 should be the fallback power poiicy. Biock 418 may include receiving an acceptance of the different fallback power poiicy. The remote device may transmit an acceptance indicating it will provide power at the different fallback power poiicy if it receives an urgent power request,

[0033] At biock 420, the method 420 may include detecting an impending loss of power. For example, detecting the impending loss of power may include detecting the disconnection of signal pins on a plug, receiving an indication from a power source of an impending loss of power, detecting a loss of power whiie capacitively stored power remains, or the like. Block 422 may include transmitting a request to receive power af the different tailback power policy. The request may be readable by a physical layer, may be readable by a higher layer, or the like. For example, the request may include or consist of a preamble and an identifier. The identifier may be interpreted by the remote device as indicating that power at the agreed upon power policy should be provided immediately. Aiternativeiy, or in addition, an indication in the payioad may represent that power at the agreed upon power policy should be provided immediately.

[0034] Biock 424 may include ceasing delivery of power to the remote device. The delivery of power may be ceased after transmitting the request to receive power without delaying, a predetermined time after transmitting the request, after receiving a confirmation the message and CRC were received without error, after receiving a message accepting the request, or the like. The voltage applied to a cable connected to the remote device may be decreased to approximately zero. The remote device may increase the voltage on the cable according to the fallback power poiicy and prepare itself to be able to deliver current according to the fallback power policy. At block 426, the method 400 may include receiving power at the different fallback power policy. Power may be received once the voltage has been increased to the level specified by the fallback power policy, or the power may be drawn as the voltage on the cable is increased to the specified level. The received power may be used to continue or start delivery of power to devices thai had their power requirements included in the determination of the fallback power policy. In an example, the controller 210 and the second data port 230 of Figure 2 may perform blocks 402-426.

[0035] Figure 5 is a block diagram of an example device 500 to deliver power in response to a request for a rapid reversal of a power transfer. The device 500 may include a data port 520 and a controller 5 0 electrically coupled to the data port 520. The controller 510 may cause the data port 520 to receive power, for example, from a remote device. The controller 510 may have negotiated an amount of powe to receive and may cause the device 500 to operate using the power received by the data port 520,

|0036] The controller 510 may determine a power policy for delivering power to the remote device. For example, the controller 510 may determine how much power the remote device would require if it were no longer able to provide power to the device 500, The determined power policy may not be used immediately for providing power to the remote device. Rather, an indication of the power policy may be stored, for example, in a volatile or persistent computer readable medium.

[0037] The controller 510 may receive an urgent power request from a remote device coupled to the data port 520. For example, the remote device may transmit the urgent power request to the data port 520 over a cable. The controller 510 may receive the urgent power request from the data port 520 and identify it as an urgent power request. The controller 520 may include a physical layer for communicating over the cable, and the physical layer may identify the received message as an urgent power request.

[0038] The controller 510 may cause the data port 520 to deliver power at the previously determined power polic to the remote device based on the urgent power request without additional negotiation with the remote device, For example, the controller 510 may cause the data port 520 to deliver power at the power policy without receiving an indication of the power poiicy in the urgent power request or any additional communications after the urgent power request and before power is delivered. In an example, the controiler 510 may cause the data port 520 to deliver power at the power poiicy without transmitting an acceptance of the urgent power request, without transmitting an acknowledgement a message or CRC was received correctly, or the like, The power may he delivered to the remote device over a cable coupled to the data port 520.

|0039] Figure 6 is a block diagram of another example device 800 to deiiver power in response to a request for a rapid reversal of a power transfer. The device 600 may include a controller 610 electrically coupled to a data port 620. The data port 620 may be connected to a hub 650, which may be connected to a first monitor 860 and a second monitor 670. The data port 620 and the hub 650 may be connected by a cable able to transfer power and data between the data port 620 and the hub 650. The controller 610 may initially cause the data port 620 to deiiver power to the hub 650. The hub 650 may detect that the second monitor 670 is abie to provide power from a fixed supply, so the hub 650 may negotiate to receive power from the second monitor 670, The controiler 610 and the hub 650 may perform a power role swap and negotiate a power policy sufficient to power the device 600,

0040] The controller 610 may determine a power policy for delivering power to the hub 650, In an example, the controller 610 may determine the power policy based on an amount of power previously delivered to the hub 650 (e.g., a power policy at which power was previously delivered to the hub 650). The controller 610 may determine the power policy by storing an indication of a power poiicy used to deliver power to the hub 650. For example, the controiler 610 may store the indication of the power poiicy when a power roie swap is performed with the hub 650 to receive power from the hub 650, The stored indication may be retrieved and used to determine the power policy at which to deiiver power in response to an urgent power request.

[0041] The controiier 610 and the hub 650 may determine the power policy for delivering power to the hub 650 by negotiating the power policy, In an example, the previous power policy may be a default fallback power policy that can be overridden by explicit negotiation. Alternatively, an explicit negotiation may be required to set the fallback power policy. The hub 650 may determine its power requirements and transmit an indication of a power policy selected based on the hub's power requirements to the controller 610. For example, the hub 650 may determine that power will be needed for the hub 650 and the first monitor 660 if power is lost from the second monitor 870. Alternatively, or in addition, the hub 650 may determine that power will be needed for the hub 650, the first monitor 660, and the second monitor 670. The hub 650 may select a power policy based on the power needed and transmit an indication of the power policy to the controller 810. The controller 610 may accept the power policy and store the transmitted indication or a differently formatted indication of the power policy. The stored indication may be retrieved and used to determine the power policy at which to deliver power when an urgent power request is received.

[0042] The controller 610 may receive an urgent power request from the hub 650. For example, the hub 650 may transmit the urgent power request to the data port 620 over the cable, and the controller 610 ma receive the urgent power request from the data port 620 and decode it. The controller 610 may include a physical layer, and the physical layer may identify a received message as an urgent power request. For example, the urgent power request may include or consist of a preamble and a message identifier. The physical layer may decode the message identifier to identify the message as an urgent power request without additional decoding by higher layers. The physical layer may be able to identify the message faster than if a higher layer had identified the message. Alternatively, or in addition, the message may include an identification as an urgent power request that is deeodable by higher layers.

[0043] In some examples, the controller 610 may cause the device 600 to stop sinking current from the data port 620, For example, the controller 610 may cause elements sinking current to be disconnected from the data port 620 based on receiving the urgent power request. The controller 610 may cause the elements sinking current to be connected to an alternate power source, such as a battery, or to not receive power. The controller 610 may cause the data port 620 to deliver power to the hub 650 at the previously determined power policy based on the urgent power request. Because the power policy has already been determined, the controller 610 may be able to cause the data port 620 to deliver power without additional negotiation with the hub 850, The controller 610 may increase the power output by the data port 620 until it corresponds to the power policy, and the hub 650 ma draw power at the power policy. In some examples, the controller 810 may not need to transmit any additional communications before the hub 650 draws power. For example, the hub 850 may draw power as the power output by the data port 620 is increased. Alternatively, the controller 610 may cause the data port 620 to transmit a ready signal once it is able to output power at the power policy. |0044] The above description is illustrative of various principles and implementations of the present disclosure. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. Accordingly, the scope of the present application should be determined only by the following claims.