Transfer of master duties to a slave on a communication bus

Systems and methods to transfer master duties to a slave on a communication bus are disclosed. A master of a communication bus determines that one or more slaves are capable of serving as a sub-master, including providing a clock signal and owning control information bits. Once that determination is made, the master may determine that processing within the master is not required for a particular activity on the bus. The master then alerts one such capable slave to prepare to assume sub-master duties. Once the slave confirms that the slave is ready to assume the sub-master duties, the master may transmit a handover frame on the bus, and the slave begins acting as a sub-master. The master may then enter a low-power state, which may promote power savings, reduce heat generation, and provide other advantages.

BACKGROUND

I. Field of the Disclosure

The technology of the disclosure relates generally to communication buses and, particularly, to controlling master duties on the communication buses.

Computing devices have become increasingly common throughout society. Computing devices have evolved from cumbersome, immobile, multi-room devices that slowly operated on a few instructions to small portable devices that can perform myriad functions effectively simultaneously. The ability to perform such varied functions has led to a general convergence of multiple different types of devices, including telephonic devices, cameras, and audiovisual devices, creating a multifunction multimedia device that may include multiple speakers and multiple microphones.

Various protocols have been promulgated to support the use of multiple speakers and microphones. In particular, the MIPI Alliance has published the Serial Low-power Interchip Media Bus (SLIMbus) standard. The SLIMbus standard has not seen widespread adoption, and the MIPI Alliance has more recently published the SOUNDWIRE standard as an alternative thereto.

SOUNDWIRE has many advantages, but the manner in which the communication bus is managed requires that the bus master remain active for all communication thereon so as to provide a bus clock and to handle any control information that is generated during the communication. Keeping the bus master active consumes power. While such power consumption may not be of great concern in a desktop computing device, such power consumption may be unnecessary in battery-operated devices. Accordingly, battery life for mobile devices may be extended by finding ways that allow the bus master to enter a low-power or sleep state while keeping the bus active.

SUMMARY OF THE DISCLOSURE

Aspects disclosed in the detailed description include systems and methods to transfer master duties to a slave on a communication bus. Exemplary aspects of the present disclosure allow a master of a communication bus to determine that one or more slaves are capable of serving as a sub-master, including providing a clock signal and owning control information bits. Once that determination is made, the master may determine that processing within the master is not required for a particular activity on the bus, such as when the payload transported on the communication bus moves between two or more slaves while not addressing the master. The master then alerts one such capable slave to prepare to assume the sub-master duties. Once the slave confirms that the slave is ready to assume the sub-master duties, the master may transmit a handover frame on the bus, and the slave begins acting as a sub-master. The master may then enter a low-power state, which may promote power savings, reduce heat generation, and provide other advantages. While exemplary aspects are well suited for a SOUNDWIRE communication bus, the present disclosure may be applied to any bus that does not normally allow transfer of master duties.

In this regard in one aspect, a master integrated circuit (IC) is disclosed. The master IC includes a bus interface configured to be coupled to a SOUNDWIRE bus. The master IC also includes a transceiver coupled to the bus interface. The master IC also includes a control system operatively coupled to the transceiver. The control system is configured to instruct a slave device amongst a plurality of slave devices coupled to the SOUNDWIRE bus to prepare to assume sub-master control of the SOUNDWIRE bus. The control system is also configured to pass master duties to the slave device.

In another aspect, a slave IC is disclosed. The slave IC includes a bus interface configured to be coupled to a SOUNDWIRE bus. The slave IC also includes a transceiver coupled to the bus interface. The slave IC also includes a control system operatively coupled to the transceiver. The control system is configured to receive an instruction from a master IC through the SOUNDWIRE bus to prepare to assume sub-master control of the SOUNDWIRE bus. The control system is also configured to assume the sub-master control of the SOUNDWIRE bus.

In another aspect, a method is disclosed. The method includes commencing operation with a plurality of devices coupled to a communication bus. A first device of the plurality of devices operates as a master device, and other devices of the plurality of devices operate as slave devices. The method also includes instructing, through the communication bus, one of the slave devices to prepare to assume sub-master control of the communication bus. The method also includes passing master duties from the master device to the one of the slave devices.

In another aspect, a SOUNDWIRE system is disclosed. The SOUNDWIRE system includes a SOUNDWIRE bus. The SOUNDWIRE system also includes a master IC. The master IC includes a master bus interface configured to be coupled to the SOUNDWIRE bus. The master IC also includes a master transceiver coupled to the master bus interface. The master IC also includes a master control system operatively coupled to the master transceiver. The SOUNDWIRE system also includes a slave IC. The slave IC includes a slave bus interface configured to be coupled to the SOUNDWIRE bus. The slave IC also includes a slave transceiver coupled to the slave bus interface. The slave IC also includes a slave control system operatively coupled to the slave transceiver. The master control system is configured to instruct the slave control system to prepare to assume sub-master control of the SOUNDWIRE bus. The master control system is also configured to pass master duties to the slave IC.

DETAILED DESCRIPTION

Aspects disclosed in the detailed description include systems and methods to transfer master duties to a slave on a communication bus. Exemplary aspects of the present disclosure allow a master of a communication bus to determine that one or more slaves are capable of serving as a sub-master, including providing a clock signal and owning control information bits. Once that determination is made, the master may determine that processing within the master is not required for a particular activity on the bus, such as when the payload transported on the communication bus moves between two or more slaves while not addressing the master. The master then alerts one such capable slave to prepare to assume sub-master duties. Once the slave confirms that the slave is ready to assume the sub-master duties, the master may transmit a handover frame on the bus, and the slave begins acting as a sub-master. The master may then enter a low-power state, which may promote power savings, reduce heat generation, and provide other advantages. While exemplary aspects are well suited for a SOUNDWIRE communication bus, the present disclosure may be applied to any bus that does not normally allow transfer of master duties.

In this regard,FIG. 1is a block diagram of an exemplary computing system having a communication bus having a master and multiple slaves. For the purposes of illustration, the communication bus is a SOUNDWIRE bus, although as noted above, exemplary aspects are applicable to other buses that do not allow transfer of master duties. In this regard, the computing system is a SOUNDWIRE system100, which includes an application processor102coupled to a plurality of microphones104(1)-104(2), a codec105, a plurality of speakers106(1)-106(2), and perhaps a modem107by a multi-wire bus108. The multi-wire bus108includes a clock line120and one or more (up to eight) data lines122(1)-122(8). The application processor102is a master of the SOUNDWIRE system100, and the plurality of microphones104(1)-104(2), the codec105, the plurality of speakers106(1)-106(2), and the modem107are slaves, at least with respect to the multi-wire bus108. More information on the SOUNDWIRE specification may be found at Specification for SOUNDWIRE, version 1, released Jan. 21, 2015, available at members.mipi.org/wg/LML/document/folder/8154 to MIPI members. The SOUNDWIRE specification is incorporated by reference in its entirety.

The application processor102may include an interface124configured to be coupled to the multi-wire bus108. The interface124is coupled to a transceiver126(Tx/Rx) that is capable of driving the clock line120and the data lines122(1)-122(8) as is well understood. The application processor102further includes a control system128(CS) and a clock source130. The control system128may interoperate with memory132having software stored therein to effectuate aspects of the present disclosure. For example, software drivers for the transceiver126and/or the interface124may be present in the memory132. The clock source130may receive an input from an external system clock (not shown), have its own crystal oscillator, or otherwise generate a clock signal that is used on the clock line120.

While shown as being separate integrated circuits (ICs), it is possible that multiple components may be incorporated into a single IC. For example, a robust system on a chip (SoC) may include multiple processing cores, including a codec and a modem, in addition to other processing functions. In such an instance, the multi-wire bus108may be completely contained within the single IC or may be partially within the single IC and partially external to the IC. For example, the codec, the modem, and the application processor may be internal with internal links and the speakers and the microphones may be external with the external multi-wire bus108.

In a conventional system, the SOUNDWIRE specification requires that the master remain active during any period there is activity on the bus. In particular, the master provides the clock to the bus and also is the only device that owns the frame size, the synchronization, the opcode, the parity bit, and the control information. The requirement to be active means that the master cannot, in conventional systems, be put into a low-power or sleep mode if there is any activity on the bus, even if there is no traffic addressed to the master. Such prohibition means that the master will continue to draw power, which in turn, accelerates depletion of a battery for a mobile terminal. In many instances, the master is the application processor, which is amongst the most power-intensive circuits in the mobile terminal. Thus, being able to put the master into a low-power mode may have disproportionate power-saving opportunities.

Exemplary aspects of the present disclosure allow the application processor102, in its role as master of the SOUNDWIRE system100, to transfer part of the duties of being master to a slave in the SOUNDWIRE system100when the master is not required for a particular activity taking place on the bus. One such use case is during a phone call where the slaves in the SOUNDWIRE system100include a modem and a codec. The call does not need the application processor102to be involved once the initial setup is performed. Accordingly, exemplary aspects of the present disclosure allow transfer of some master duties to one of the slaves (e.g., the modem or the codec) and allow the application processor102to enter a low-power or sleep mode. However, before the application processor102can do so, the slave in question needs to be capable of operating in a sub-master role.

FIG. 2illustrates a block diagram of one such slave200capable of operating in a sub-master role. In particular, the slave200may be, for example, the codec105, a part of the codec105, the modem107, or a part of the modem107, and may include an interface202that is configured to couple to the multi-wire bus108containing the clock line120and the data lines122(1)-122(8). The interface202is coupled to a transceiver204(Tx/Rx) that is capable of driving the clock line120and the data lines122(1)-122(8) as is well understood. The slave200further includes a control system206(CS) and a clock source208, which may sometimes be referred to as simply a clock. The control system206may interoperate with memory210having software stored therein to effectuate aspects of the present disclosure. For example, software drivers for the transceiver204and/or the interface202may be present in the memory210. The clock source208may receive an input from an external system clock (not shown), have its own crystal oscillator, or otherwise generate a clock signal that is used on the clock line120when the slave200assumes a sub-master role.

A process300for allowing transfer of master duties to a slave is illustrated inFIG. 3. In this regard, the process300begins with a system having a communication bus having a master and multiple slaves. For example, a SOUNDWIRE system100having an application processor102acting as a master and at least a slave200along with another slave, such as a microphone104(1), is present. The master determines if the slave200is sub-master capable (block302). In an exemplary aspect, this determination is made by reading from a local discovery register stored in the slave or reading a discoverable file (sometimes referred to as a DISCO file) that is readable by a driver associated with either the master or the slave200. In another exemplary aspect, a bit in a register is interrogated. In still another exemplary aspect, the presence of a handover register is reported to the master. In still another exemplary aspect, the control system of the master may receive information about the capabilities of the slaves from an external source. For example, if the master is not the application processor, then the master may receive such information from the application processor. Other possible external sources (regardless of whether the master is the application processor) include, but are not limited to a digital signal processor, a SoC, an operating system or the like. Still other techniques of making the determination of block302are possible without departing from the scope of the present disclosure. Normal operation proceeds (block304) until the master determines that the master processing capabilities are not needed for a particular activity (e.g., a phone call where the master does not perform any processing because a modem and codec are capable of fully processing the call) (block306).

With continued reference toFIG. 3, the master writes to the slave200to prepare to assume control (block308). In an exemplary aspect, the master may write to a handover register (not illustrated) in the slave200. The slave200begins preparing for handover (block310). In an exemplary aspect, such preparation may include starting the clock source208, allowing any phase-locked loop (PLL) to settle, clearing buffers and/or registers for ownership of control information, and the like. The master may determine if the master should abort (e.g., the call has already ended, some other audio process requires the master to remain active, or the like) (block312). If the answer is yes, the master resumes normal operation (block304) and may erase the values in the handover register or otherwise de-assert the handover initiation process.

With continued reference toFIG. 3, then if the master did not abort at block312, the slave200asserts that the slave200is ready for the handover (block314). This assertion may be through an interrupt, a response to being polled, a response to a control message, a message addressed to the master, or the like. The master determines if the master should abort (block316). Again, if the master aborts, normal operation resumes as previously described. Otherwise, if the answer to block316is no, then the master announces the handover (block318). This announcement may be through a broadcast write command to registers in each slave (e.g., a master_handover register) or other technique as needed or desired.

With continued reference toFIG. 3, the master may then transmit the handover frame (block320). The master owns all the bits of the handover frame while the slave200waits to take ownership. After the last bit of the handover frame is transmitted, the slave200assumes its sub-master role (block322). The master may then enter a low-power or sleep mode. The new sub-master runs its clock and owns the control information until either the sub-master requests that the master resume master duties or the master is brought out of the low-power or sleep mode.

While the master is in the low-power or sleep mode, the master may keep necessary and sufficient circuitry (e.g., a framer) to listen to the bus108. The master may act as a slave relative to the sub-master, or the sub-master may not be aware of the master's continued limited presence on the bus108. The sub-master may conclude the activity for which it was initially granted sub-master responsibility and then may broadcast a message that the sub-master is going to release ownership of the bus108. Alternatively, the sub-master may go through a handover sequence as outlined above in the process300, where the original master acts as the master-capable slave. As another alternative, the master may issue an override command which forces a transfer of bus ownership back to the master. This may occur when the master has data or a command for the bus that originated in the master. As still another option, the original master may generate an alert such as by asserting an interrupt that requests bus ownership, and the active sub-master may accept that request and execute a handover when possible (i.e., when there is no audio payload).

Continuing the phone call example introduced above, the sub-master controls the bus108during the phone call, but when a hang up occurs terminating the call, there is no further audio payload transported between the two slaves, and the sub-master may enter a process to enter a low-power state including releasing control of the bus108or initiating the handover process300.

FIG. 4provides a signal diagram of an exemplary implementation of the process300. In particular,FIG. 4illustrates a master400(which may be the application processor102ofFIG. 1) with its clock source130providing a regular clock signal402. While the clock source130provides the regular clock signal402, the interface of the master400may not output the clock signal onto the clock line120. Specifically, at time T3, at the end of the handover frame, the master clock drives the clock line120high and then releases the bus (i.e., a floating output), which allows another clock driver to drive the clock line120. Thus, as seen on the clock line120, the clock line120stays high between times T3and T5, when the sub-master clock begins driving the clock line120. Likewise, the master400may generate and output data on the data line122(1) until time T3(i.e., the end of the handover frame), at which time the master400may drive the data line low and float the output. This allows the sub-master (i.e., the slave200) to begin driving data on the data line122(1) at time T5.

With continued reference toFIG. 4, the slave200, and particularly, the clock source208of the slave200, begins preparing while the master400waits to receive the slave ready assertion. Note that initially, the slave clock208may not be active. Once the slave200is ready for the handover (i.e., block314), the master400announces the handover (i.e., block318) from time T1to time T2. The slave200may acknowledge the handover announcement between time T1and T2. At time T2, the handover frame commences. After time T3, the slave200begins to drive high the clock line120and drive low the data line122(1) until ready to send clock and data signals at time T5.

The systems and methods for transfer of master duties to a slave on a communication bus according to aspects disclosed herein may be provided in or integrated into any processor-based device. Examples, without limitation, include a set top box, an entertainment unit, a navigation device, a communications device, a fixed location data unit, a mobile location data unit, a global positioning system (GPS) device, a mobile phone, a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a tablet, a phablet, a server, a computer, a portable computer, a mobile computing device, a wearable computing device (e.g., a smart watch, a health or fitness tracker, eyewear, etc.), a desktop computer, a personal digital assistant (PDA), a monitor, a computer monitor, a television, a tuner, a radio, a satellite radio, a music player, a digital music player, a portable music player, a digital video player, a video player, a digital video disc (DVD) player, a portable digital video player, an automobile, a vehicle component, avionics systems, a drone, and a multicopter.

In this regard,FIG. 5is a system-level block diagram of an exemplary mobile terminal500such as a smart phone, mobile computing device tablet, or the like. While a mobile terminal is particularly contemplated as being capable of benefiting from exemplary aspects of the present disclosure, it should be appreciated that the present disclosure is not so limited and may be useful in any system having a SOUNDWIRE bus or other bus that normally does not allow master function transfer.

With continued reference toFIG. 5, the mobile terminal500includes a SLIMbus502, which may be coupled to an application processor504(sometimes referred to as a host) that communicates with a mass storage element506through a universal flash storage (UFS) bus508. The application processor504may further be connected to a display510through a display serial interface (DSI) bus512and a camera514through a camera serial interface (CSI) bus516. Various audio elements such as a microphone518, a speaker520, and an audio codec522may be coupled to the application processor504through the SLIMbus502. Additionally, the audio elements may communicate with each other through a SOUNDWIRE™ bus526. A modem528may also be coupled to the SLIMbus502and/or the SOUNDWIRE bus526. The modem528may further be connected to the application processor504through a peripheral component interconnect (PCI) or PCI express (PCIe) bus530and/or a system power management interface (SPMI) bus532.

With continued reference toFIG. 5, the SPMI bus532may also be coupled to a local area network (WLAN) IC (WLAN IC)534, a power management integrated circuit (PMIC)536, a companion IC (sometimes referred to as a bridge chip)538, and a radio frequency IC (RFIC)540. It should be appreciated that separate PCI buses542and544may also couple the application processor504to the companion IC538and the WLAN IC534. The application processor504may further be connected to sensors546through a sensor bus548. The modem528and the RFIC540may communicate using a bus550.

With continued reference toFIG. 5, the RFIC540may couple to one or more RFFE elements, such as an antenna tuner552, a switch554, and a power amplifier556through a radio frequency front end (RFFE) bus524. Additionally, the RFIC540may couple to an envelope tracking power supply (ETPS)558through a bus560, and the ETPS558may communicate with the power amplifier556. Collectively, the RFFE elements, including the RFIC540, may be considered an RFFE system562. It should be appreciated that the RFFE bus524may be formed from a clock line and a data line (not illustrated).