PATENT DOCUMENT

Publication Number: US-8190798-B1
Application Number: US-201113044399-A
Country: US
Kind Code: B1

Title: Client device configuration based on information stored by host device

Abstract:
A host device can enable operation with a client device based on stored or cached enumeration information. The enumeration information can be initially received from the client device during a first configuration process, and stored or cached in volatile and/or non-volatile storage accessible by the host device. During subsequent configuration processes, operation with the client device can be enabled based on the stored or cached enumeration information. Operation between the host device and the client device can be facilitated through a communication protocol, such as the universal serial bus (USB) protocol. A host device and client device can be connected via a traditional USB or USB High Speed Inter-Chip (HSIC) connection.

Claims:
1. A method of operating a host device, the method comprising, by the host device:
 detecting a client device; 
 determining whether enumeration information for the client device is stored by the host device; 
 in the event that the enumeration information for the client device is stored by the host device:
 retrieving the stored enumeration information; and 
 enabling operation with the client device based on the stored enumeration information according to a communication protocol; and 
 
 in the event that the enumeration information for the client device is not stored by the host device:
 receiving enumeration information from the client device; 
 enabling operation with the client device based on the received enumeration information according to a communication protocol; and 
 storing the enumeration information in a storage device accessible to the host device. 
 
 
     
     
       2. The method of  claim 1 , wherein the communication protocol is the universal serial bus (USB) protocol. 
     
     
       3. The method of  claim 2 , wherein the enumeration information includes a set of universal serial bus (USB) descriptors. 
     
     
       4. The method of  claim 1 , further comprising indicating to the client device that the client device is enabled for operation with the host device. 
     
     
       5. The method of  claim 4 , wherein indicating to the client device that the client device is enabled for operation includes sending a configuration value to the client device. 
     
     
       6. The method of  claim 1 , wherein determining if enumeration information for the client device is stored is based on the port to which the client device is connected. 
     
     
       7. The method of  claim 1 , wherein determining if enumeration information for the client device is stored includes:
 receiving a portion of the client enumeration information from the client device; and 
 determining if enumeration information for the client device is stored based on a client device identifier included in the portion of the client enumeration information. 
 
     
     
       8. A host device comprising:
 a processor; 
 a memory device coupled to the processor; and 
 a port coupled to the processor; 
 wherein the processor is configured to:
 initiate a configuration process with an unconfigured client device connected to the port; 
 determine whether configuration information associated with the port is stored in the memory device; and 
 in the event that the configuration information associated with the port is stored, set up operation with the client device using the stored configuration information associated with the port. 
 
 
     
     
       9. The host device of  claim 8 , wherein the port comprises a USB high speed inter-connect (HSIC) port. 
     
     
       10. The host device of  claim 8 , wherein the port comprises a USB connector. 
     
     
       11. The host device of  claim 8 , wherein the host device is an integrated circuit. 
     
     
       12. The host device of  claim 8 , wherein the host device is embedded in the same printed circuit board (PCB) as the client device. 
     
     
       13. The host device of  claim 8 , wherein the processor is further configured to communicate with the client device according to the universal serial bus (USB) protocol after operation is set up. 
     
     
       14. The host device of  claim 8 , wherein the configuration information includes enumeration information. 
     
     
       15. The host device of  claim 14 , wherein the enumeration information includes a set of universal serial bus (USB) descriptors. 
     
     
       16. A method of operating a host device, the method comprising, by the host device:
 detecting a client device connected to the host device via a USB high speed inter-connect (HSIC) connection, wherein the client device is not set up for operation with the host device; 
 receiving enumeration information from the client device; 
 setting up operation with the client device based on the received enumeration information; 
 storing the enumeration information for the client device; 
 subsequently identifying that the client device is no longer set up for operation with the host device; and 
 setting up operation with the client device based on the stored enumeration information. 
 
     
     
       17. The method of  claim 16 , wherein the enumeration information includes a set of USB descriptors. 
     
     
       18. The method of  claim 16 , wherein the enumeration information is stored in volatile memory. 
     
     
       19. The method of  claim 16 , wherein the enumeration information is stored in non-volatile memory. 
     
     
       20. A computer-readable storage medium containing program instructions that, when executed by a host device, causes the host device to execute a method comprising:
 detecting a client device connected to the host device via a communication link, wherein the client device is not enabled for operation with the host device; 
 requesting enumeration information from the client device; 
 receiving enumeration information from the client device; 
 enabling operation with the client device based on the received enumeration information; 
 storing the enumeration information in a storage device locally accessible to the host device; 
 subsequently detecting that the client device is reconnected to the host device via the communication link, wherein the client device is no longer enabled for operation with the host device; 
 retrieving enumeration information for the client device from the storage device locally accessible to the host device; 
 and enabling operation with the client device based on the retrieved enumeration information. 
 
     
     
       21. The computer-readable storage medium of  claim 20 , wherein the enumeration information includes a set of USB descriptors. 
     
     
       22. The computer-readable storage medium of  claim 20 , where the communication link is implemented according to the USB high speed inter-connect (HSIC) standard. 
     
     
       23. A system comprising:
 a client device configured to:
 receive a request for enumeration information; and 
 transmit enumeration information in response to the request; and 
 
 a host device configured to:
 perform an initial configuration process with the client device, wherein the initial configuration process includes:
 requesting enumeration information from the client device; 
 receiving enumeration from the client device; 
 enabling operation with the client device based on the enumeration information received from the client device; and 
 storing the enumeration information received from the client device; and 
 
 perform a subsequent configuration process with the client device, wherein the subsequent configuration process includes:
 retrieving the stored enumeration information for the client device; and 
 using the stored enumeration information to enable operation with the client device via a communication link implemented according to the USB high speed inter-connect (HSIC) standard. 
 
 
 
     
     
       24. The system of  claim 23 , wherein the subsequent configuration process includes requesting enumeration information from the client device. 
     
     
       25. The system of  claim 23 , wherein the host device and the client device are integrated circuits embedded in a single printed circuit board (PCB).

Description:
BACKGROUND 
     The present disclosure relates generally to host devices enabling operation with client devices based on enumeration information, and in particular to host devices enabling operation with client devices using enumeration information stored or cached by the host devices. 
     Computing devices have been in use for several decades. Examples of computing devices include, for example, desktop computers, laptop computers, mobile phones, smartphones, tablet devices, portable multimedia players, global positioning system devices, video game players, personal digital assistants (PDAs), portable email devices, multifunction devices, and/or the like. Examples of multi-function devices include various iPhone™ and iPod™ models manufactured and sold by Apple Inc., assignee of the present application. Computing devices can be used for performing a wide variety of tasks, from the simple to some of the most complex. 
     In some instances, two computing devices can be configured to communicate with one other. For example, two computing devices can be connected and communicate over a printed circuit board (“PCB”) trace or cable. To facilitate communication between computing devices, it is common to rely on standard communication protocols, such as the universal serial bus (USB) protocol. The USB specification requires that in order for operation between a host device and client device to be enabled, a configuration process must occur. In some instances, a configuration process can include a client device providing enumeration information (e.g., information about the client device) to the host device, and the host device enabling operation with the client device based on the provided enumeration information. 
     BRIEF SUMMARY 
     According to various embodiments of the present invention, a host device can enable operation with a client device based on stored or cached enumeration information. In some embodiments, enumeration information can be received by the host device during a first configuration process and stored or cached in volatile and/or non-volatile storage. In some embodiments, communication between a host and client device can be facilitated by a communication protocol, such as the universal serial bus (USB) protocol. 
     For example, a host device and client device can be components (e.g., an applications processor and a co-processor respectively) embedded in a printed circuit board (e.g., motherboard) of a smartphone. The host and client devices can be connected via a set of printed circuit board traces, which can be implemented according to the USB High Speed Inter-Chip (HSIC) standard. When the smartphone is powered on, the host device can initiate a configuration process with the client device. During the configuration process, the client device can provide enumeration information to the host device. The host device can thereafter enable operation with the client device based on the received enumeration information. The host device can additionally cache or store the enumeration information in volatile (e.g., dynamic random access memory) and/or in non-volatile storage (e.g., hard drive, flash memory, etc.). During subsequent configuration processes, the host device can retrieve the enumeration information stored in its volatile and/or non-volatile storage to enable operation with the client device. Subsequent configuration processes can occur if the client device becomes unconfigured. A client device can become unconfigured by being turned off and on, suspended and woken up, restarted, rebooted, etc. 
     These and other embodiments of the invention along with many of its advantages and features are described in more detail in conjunction with the text below and attached figures. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a system including a host device connected to a client device according to an embodiment of the present invention. 
         FIG. 2  illustrates a system including a host device connected to a client device according to another embodiment of the present invention. 
         FIG. 3  is a hierarchical diagram illustrating an exemplary set of USB descriptors that can be included in a client device&#39;s enumeration information according to an embodiment of the present invention. 
         FIG. 4  is a flow diagram of a process usable by a host device for enabling operation with a client device according to an embodiment of the present invention. 
         FIG. 5  is a flow diagram of a process usable by a host device for enabling operation with a client device according to another embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     Some embodiments of the present invention provide techniques usable by a host device to quickly enable operation with a client device based on stored or cached enumeration information. In some embodiments, the enumeration information can be received from the client device during a first configuration process, and stored or cached in volatile and/or non-volatile storage accessible by the host device. During subsequent configuration processes, the host device can enable operation with the client device based on the stored or cached enumeration information. In some embodiments, communication between the host device and the client device can be facilitated through a communication protocol, such as the universal serial bus (USB) protocol. 
     Illustratively, a host device and a client device can be components of a multi-function device, such as an iPhone™ device manufactured and sold by Apple Inc. After powering on the multi-function device, the host device can detect the presence of the client device and initiate a configuration process. During the configuration process, the host device can determine if enumeration information for the client device has been previously stored or cached in its locally accessible volatile and/or non-volatile storage. If enumeration information for the client device has not been previously stored or cached, the host device can perform an enumeration process. In particular, the host device can request and receive enumeration information from the client device. Based on the received enumeration information, the host device can enable operation with the client device. The host device can further store or cache the received enumeration information in its volatile (e.g., dynamic random access memory) and/or non-volatile storage (e.g., hard disk, flash memory, etc.). During operation of the multi-function device, the client device can be temporarily powered off in order to conserve energy. After the client device is powered back on, the host device can initiate a subsequent configuration process. Because the host device previously stored the client device&#39;s enumeration information, the host device can use the stored enumeration information to enable operation with the client device instead of repeating the enumeration process. 
     In certain embodiments, a host device can be any suitable computing device without limitation. In some embodiments, a host device can be a component of a personal computer, laptop computer, tablet device, multimedia device, cellular phone, smartphone, global positioning system (GPS) device, gaming device, multi-function device, printer, household device, a smart hub device that permits two or more devices to communicate with one another, any portable or non-portable electro-mechanical device and/or the like. For example, a host device can be a single chip (integrated circuit) applications processor within a smartphone device that is configured to interact with various other co-processors or components of the smartphone device. In other embodiments, a host device can be a personal computer, laptop computer, tablet device, multimedia device, cellular phone, smartphone, global positioning system (GPS) device, gaming device, multi-function device, printer, household device, a smart hub that permits two or more devices to communicate with one another, any portable or non-portable electro-mechanical device and/or the like. 
     In certain embodiments, a client device can be any suitable device capable of communicating with a host device without limitation. In some embodiments, a client device can be a component of a personal computer, laptop computer, tablet device, multimedia device, cellular phone, smartphone, global positioning system (GPS) device, gaming device, multi-function device, wireless communications device, modem, external speaker, external display, input device, printing device, and/or the like. For example, a client device can be a single chip (integrated circuit) co-processor that manages hardware providing mobile telephone network communications (voice and/or data), WiFi communications (e.g., IEEE 802.11 family standards), and/or short-range technology communications (e.g., Bluetooth). In other embodiments, a client device can be a tablet device, multimedia device, cellular phone, smartphone, global positioning system (GPS) device, gaming device, multi-function device, wireless communications device, modem, external speaker, external display, input device, printing device, and/or the like. 
     In certain embodiments, a host device can communicate with a client device via a communication link. In some embodiments, a host device can communicate with a client device via a path that includes more than one communication link. For example, a host device can be connected to a hub device (e.g., a device that allows a single connection from a host device to connect to multiple client devices) via a first communication link. The hub device can then be connected to a client device via a second communication link. During operation, communications between the host and client devices can pass through the first communication link, hub device, and second communication link. 
     Communication links can be any suitable connection type. For example, a host device can be connected to a client device via a direct connection to a USB High-Speed Inter-Chip (HSIC) port, a USB port, a serial port, a parallel port, an Ethernet port, and/or the like. A host device can also be connected to a client device via a wireless medium such as WiFi or Bluetooth. With respect to USB HSIC, these connections are standard connection types optimized for chip-to-chip communications over short distances. USB HSIC connections are designed to reduce cost, power requirements, complexity, and manufacturing risk. In the majority of circumstances, USB HSIC connections are used to enable communication between chips on a single PCB. 
     As discussed, communication between a host and client device can be based on the universal serial bus (USB) protocol. The USB protocol, which was developed in the 1990s, can enable a single USB host device to access the various functionalities provided by one or more USB client devices. To enable operation between a USB host device and a USB client device, the USB protocol requires a configuration process, which includes an enumeration process, to occur. During the enumeration process, the host device can request and receive configuration information, also referred to as enumeration information, from the USB client device. Enumeration information can include USB descriptors, which provide information about the attributes and functions of the USB client device. Based on the enumeration information, the USB host device can establish operation with the USB client device. For example, the USB host device can load software drivers for the client device and/or the like. After this process is completed, the USB host device can signal to the USB client device that operation is enabled by assigning the USB client device a configuration value. 
     Under the USB protocol, a host device can be required to initiate a configuration process each time a client device becomes unconfigured. A client device can be unconfigured if it is turned off and back on, restarted, rebooted, suspended and subsequently woken up, disconnected and later reconnected to the host device, etc. For example, a USB host device and a USB client device can be connected components of a smartphone. During operation of the smartphone, the USB host and client devices can be enabled for operation as a result of an initial configuration process. The smartphone can be later turned off and turned back on. Upon being turned back on, a subsequent configuration process, including an enumeration process, can be required in order for the USB host and client device to be enabled for operation. 
     As discussed, embodiments of the present invention can permit a host device to perform a fast configuration of a client device based on stored or cached enumeration information. By using stored or cached enumeration information, the total time for a host device to configure a client device can be shortened as compared to host devices that rely on enumeration information received from a client device through an enumeration process. Embodiments of the present invention, by using stored or cached enumeration information, can eliminate the need to wait for enumeration information to be received from a client device. Instead, enumeration information can be retrieved quickly from relatively fast volatile and/or non-volatile storage. As a result, the total time to enable operation with a client device can be reduced. 
     The following description primarily refers to communications using the USB protocol. However, one skilled in the art will appreciate that the techniques disclosed in this specification are equally applicable to other types of communication protocols. The following descriptions also primarily refer to communications over USB and USB HSIC connections. However, one skilled in the art will appreciate that the techniques disclosed in this specification are equally applicable to other types of connections, such as wired and wireless connections. 
       FIG. 1  illustrates a system  100  including a host device connected to a client device according to an embodiment of the present invention. The system shown in  FIG. 1  includes a host device  110 , a volatile storage device  120 , a client device  130 , a communication link  150 , non-volatile storage device  112 , and client specific hardware  140 . Although the system of  FIG. 1  shows only one host device, one client device, one communication link, one volatile storage device, one non-volatile storage device, and one client specific hardware, any suitable number of these entities (including zero) can be included. For example, host device  110  can be connected to multiple client devices including, a first client device that manages WiFi communications and a second client device that manages mobile telephone communications. 
     In some embodiments, host device  110 , volatile storage device  120 , client device  130 , non-volatile storage device  112 , and client specific hardware  140  can be wholly or partially enclosed within a housing  180 . Housing  180  can be made of any suitable material. For instance, housing  180  can be made of plastic, metal, glass, ceramics, wood, and/or the like. In certain embodiments, the host device  110  and client device  130  can be implemented on or embedded in the same printed circuit board (e.g., motherboard) within housing  180 . For example, host device  110  and client device  130  can each be a chip embedded in the motherboard of a multi-function device. Communication link  150 , which connects the host device  110  and client device  130 , can be, for example, one or more traces on a printed circuit board (PCB). 
     In some embodiments, host device  110  can include a processor  116  and a client I/O interface  118 . In some embodiments, host device  110  can be implemented as one or more integrated circuits (including e.g., a conventional microprocessor or microcontroller). For example, host device  110  can be a single chip applications processor that integrates processor  116  and client I/O interface  118 . Host device  110  can further be connected to non-volatile storage device  112  and volatile storage device  120  in any suitable manner. 
     Processor  116 , which can be implemented as one or more integrated circuits, can control the operation of host device  110 . For example, in response to user input signals provided via a user interface (not shown), processor  116  can perform various tasks such as selecting and playing media assets that can be stored in non-volatile storage device  112 , interacting with client devices to access various client device functionalities (e.g., accessing a mobile telephone network, the Internet, local area network, external speakers, external displays, and/or the like), executing various software programs  114  (e.g., operating systems and applications) residing on non-volatile storage device  112 , and so on. 
     Client I/O interface  118  can include one or more ports. Each port can include a number of signal paths configured to carry various signals between host device  110  and client device  130 . In some embodiments, each port can include a number of signal paths sufficient for facilitating communication based on a communication protocol. For example, a port can include a number of signal paths suitable for communication using the USB protocol. Other protocols can also be used provided that client I/O interface  118  supports the same protocol as I/O interface  132  of client device  130 . In some embodiments, client I/O interface  118  can be a USB HSIC interface. 
     Non-volatile storage device  112  can be any type of non-volatile memory. For example, non-volatile storage device  112  can be implemented e.g., using magnetic disk, optical disk, flash memory, or any other non-volatile storage medium. Non-volatile storage device  112  can store software programs  114  that are executable by processor  116 , including operating systems and related program code (not explicitly shown) that can be used in managing communications with various client devices, e.g., as described below and/or software programs. Non-volatile storage device  112  can also store any other type of information such as various media assets, information about a user&#39;s contacts (names, addresses, phone numbers, etc.), scheduled appointments and events, notes, and/or other information. In some embodiments, host device  110  can receive configuration information (e.g., enumeration information) from client device  130 , and such information can be stored in non-volatile storage device  112 . Configuration information can include, for example, a set of USB descriptors and any other data suitable for enabling operation with client device  130 . 
     Volatile storage device  120  can be implemented using any type of volatile memory. For instance, volatile storage device  120  can be any suitable volatile memory medium such as any variants of dynamic random access memory (DRAM) and static random access memory (SRAM). Volatile storage device  120  can further store client device configuration information. For example, volatile storage device  120  can store enumeration information including a set of USB descriptors and any other data suitable for enabling operation with client device  130 . 
     In some embodiments, configuration information can be initially stored in non-volatile storage device  112  during an initial enumeration process. The information can be stored such that the information persists across multiple boot-ups of host device  110  and/or system  100 . For example, the configuration information can be stored during manufacturing of system  100 . The stored information can thereafter be used to configure a client device during the lifetime of system  100 . In other embodiments, the configuration information can be stored for only the current operating session of host device  110  and/or system  100 . Illustratively, configuration information can be received from a client device during a boot-up process and stored in volatile storage device  120 . Thereafter, if host device  110  and/or system  100  is rebooted or restarted, the configuration information must again be received from the client device. 
     Software programs  114  (also referred to as software herein) can include any program executable by processor  116 . In some embodiments, certain software programs can be installed on host device  110  by its manufacturer, while other software programs can be installed by a user. Examples of software programs  114  can include operating systems, productivity applications, video game applications, personal information management applications, applications for playing media assets and/or navigating a media asset database, applications for controlling a telephone interface to place and/or receive calls, and so on. Certain software programs  114  can provide communication with and/or control of client devices, and certain software programs  114  can be responsive to control signals or other input from client device  130 . 
     In some embodiments, client device  130  can include an I/O interface  132  and controller  134 . In certain embodiments, client device  130  can be implemented as one or more integrated circuits. For example, client device  130  can be a single chip digital signal processing (DSP) co-processor integrating I/O interface  132  and controller  134 . In some embodiments, client device  130  can be connected to client specific hardware  140  in any suitable manner. 
     I/O interface  132  can include a number of signal paths configured to carry various signals between client device  130  and host device  110 . In some embodiments, the I/O interface  132  can include a number of signal paths sufficient for facilitating communication based on a communication protocol. For example, the I/O interface  132  can include a number of signal paths suitable for communication using the USB protocol. Other protocols can also be used provided that I/O interface  132  supports the same protocol as client I/O interface  118  of host device  110 . In some embodiments, I/O interface  132  can be a USB HSIC interface. 
     Controller  134  can execute program code to manage the various functions of client specific hardware  140 , such as managing mobile phone communications (voice and/or data), WiFi communications, short-range (e.g., Bluetooth) communications, digital audio decoding, analog or digital audio and/or video processing, processing of user input, controlling the functionality of client specific hardware  140  and the like. Controller  134  can also manage communication with host device  110  via I/O interface  132 . For example, mobile telephone voice data from the client specific hardware  140  can be received by controller  134  and subsequently relayed to host device  110 . 
     Client specific hardware  140  can represent any hardware needed to enable any desired functionality. 
     In some embodiments, client specific hardware  140  can include network and/or communication interfaces. The network and/or communication interfaces can provide voice and/or data communication capability for host device  110 . In some embodiments, the network and/or communication interfaces can include wireless transceivers (e.g., using mobile telephone technology such as GSM or CDMA, advanced data network technology such as 3G or EDGE, WiFi (IEEE 802.11 family standards), Bluetooth, or other mobile communication technologies, or any combination thereof), GPS receiver components, and/or other components for accessing wireless voice and/or data networks. In some embodiments, the network and/or communication interfaces can provide wired network connectivity in addition to or instead of a wireless interface. The network and/or communication interfaces can be implemented using any suitable combination of hardware (e.g., antennas, modulators/demodulators, encoders/decoders, and other analog and/or digital signal processing circuits). 
     In other embodiments, client specific hardware  140  can include an RF receiver (e.g., for FM, AM, satellite radio, and/or other bands) and/or an RF transmitter (e.g., a short-range transmitter for personal use). In still other embodiments, client specific hardware  140  can include powered speakers, image displays (e.g., LCDs), input devices, printing devices, etc. 
     In some embodiments, client specific hardware  140  can include components of a user interface. Thus, an application executing on host device  110  can receive user input from client specific hardware  140 , provide output to a user via client specific hardware  140 , and/or control, interact with, or respond to any operation that client specific hardware is capable of performing. 
     Accordingly, client specific hardware  140  can encompass any hardware component for which interoperability with a computing and/or communication device can be desirable. 
     I/O interfaces  118  and  132  can allow host device  110  to be connected to client device  130  via communication link  150 . Communication link  150  can enable data to be transferred between host device  110  and client device  130  using any suitable communication protocol (e.g., the USB protocol). In certain embodiments, communication link  150  can be any suitable connection type. For example, communication link  150  can be a USB HSIC connection. Communication link  150  can further be implemented in any suitable manner. For example, communication link  150  can be implemented as traces on a PCB, a cable, an interconnect wire, a connection over a wireless medium, and/or the like. 
     In some embodiments, communication link  150  can be placed in a suspended or low power mode. Suspending communication link  150  can cause the communication link to use less power relative to when the communication link is active (e.g., enabled for communication). For example, when communication link  150  is suspended, it can draw minimal or no power from host device  110 . 
     In some embodiments, client device  130  can draw power from host device  110  via communication link  150 . As such, when communication link  150  is suspended, client device  130  can likewise be suspended. In other embodiments, client device  130  can draw power from a source other than host device  110 . As a result, client device  130  can remain active while communication link  150  is suspended. It should be noted that in such embodiments, client device  130  can also independently suspend itself. 
     In certain embodiments, communication link  150  can be switched from a suspended mode to an active mode by either host device  110  or client device  130 . Upon activating or “waking up” communication link  150 , operation between host device  110  and client device  130  can resume. In some embodiments, in order for operation to be resumed, host device  110  can be required to initiate a configuration process with client device  130 . 
     In some embodiments, a host device and a client device can be embedded in separate PCBs or in separate housings. For example,  FIG. 2  illustrates a system  200  including a host device connected to a client device according to another embodiment of the present invention. The system illustrated in  FIG. 2  can be similar to the system illustrated in  FIG. 1 . However, in some embodiments, host device  210  and client device  230  can be enclosed in separate housings. For example, host device  210  can be a portable multimedia device and client device  230  can be an external accessory, such as a speaker. In other embodiments, host device  210  and client device  230  can be enclosed in a common housing but embedded in different PCBs. Although the system of  FIG. 2  shows only one host device, one client device, one communication link, one volatile storage device, one non-volatile storage device and one client specific hardware, any suitable number (including zero) of these entities can be included. 
     Referring to  FIG. 2 , host device  210  can be similar to host device  110 . Non-volatile storage device  212  can be similar to non-volatile storage device  112 . Software  214  can be similar to software  114 . Processor  216  can be similar to processor  116 . Client I/O interface  218  can be similar to client I/O interface  118 . Client I/O interface  218  can be any suitable interface for facilitating communication using the USB or any other communication protocol. For example, client I/O interface  218  can include a connector that can be coupled to a USB cable. Client device  230  can be similar to client device  130 . Controller  234  can be similar to controller  134 . I/O interface  232  can be similar to I/O interface  132 . I/O interface  232  can be any suitable interface for facilitating communication using the USB or any other communication protocol. Client specific hardware  240  can be similar to client specific hardware  140 . Volatile storage device  220  can be similar to volatile storage device  120 . Communication link  250  can be similar to communication link  150 .  FIG. 2  further shows that host device  210  can include non-volatile storage device  212  and volatile storage device  220 , and client device  230  can include client specific hardware  240 . 
     In some embodiments, communication link  250  can be implemented as a USB cable, serial cable, etc., allowing host and client devices to be connected or disconnected by a user. 
     It will be appreciated that the devices shown in  FIGS. 1 and 2  are illustrative and that variations and modifications are possible. For example, the host devices shown in  FIGS. 1 and 2  can be indirectly connected to multiple client devices via a hub. 
     As described above, a host device and a client device can communicate using a communication protocol. In some embodiments, the communication protocol can be the USB protocol. Under the USB protocol, enabling operation between a host device and client device occurs via a configuration process, which includes an enumeration process. The configuration process can be initiated through the host device sending a reset signal to the client device upon sensing the presence of the client device. The data rate of the client device can be determined during the reset signaling. After reset, the host device can initiate an enumeration process. In particular, the client device&#39;s enumeration information (e.g., information about the functionality of the client device, attributes, etc.) can be requested and read by the host device and the client device can be assigned a unique 7-bit address. If the client device is supported by the host device, device drivers for the client device can be loaded and the client device can be set to a configured state. If a client device becomes unconfigured at a later time, the configuration process, including the enumeration process, can be repeated by the host device. A client device can become unconfigured if it is powered down and back on, suspended and woken up, restarted, rebooted, disconnected and reconnected to the host device, etc. A client device can also become unconfigured if its host device is powered down and back on, restarted, rebooted, disconnected and reconnected to the client device, etc. In instances where the host device is powered down and back on, restarted, or rebooted, the configuration process can be repeated for all connected client devices. 
     A client device&#39;s enumeration information can include one or more USB descriptors. The descriptors can define a client device&#39;s attributes, supported device configurations, supported interfaces, and the like. Descriptors can include a device and one or more configuration, interface, endpoint, and string descriptors. 
       FIG. 3  illustrates a hierarchical diagram of an exemplary set of USB descriptors that can be included in a client device&#39;s enumeration information according to an embodiment of the present invention. The set of USB descriptors can include a device descriptor  302 . Device descriptor  302  can provide information about the client device&#39;s vendor, product identifier, revision, etc. Device descriptor  302  can be associated with one or more configuration descriptors, such as configuration descriptors  304  and  306 . A client device with more than one configuration descriptor can indicate that the client device supports more than one functionality. For example, a client device can have a first configuration associated with a camera functionality and a second configuration associated with a mass storage device functionality. Configuration descriptors  304  and  306  can provide information about the number of supported interfaces, device power requirements, etc. Each configuration descriptor can additionally be associated with one or more interface descriptors. For instance, configuration descriptor  304  can be associated with interface descriptors  308  and  310 . The interface descriptors can provide information about the different interfaces supported by the client device. Interfaces can facilitate the communication of certain types of information between a host and client device. For example, an audio interface can be used to communicate sound information between a host and client device. Interface descriptors can be associated with one or more endpoint descriptors. For instance,  FIG. 3  shows that interface descriptors  308  and  310  can be associated with one and two endpoint descriptors respectively. Endpoint descriptors can provide information about the endpoint that is to facilitate the communication of information for the client device. Endpoint descriptors can identify, for example, an endpoint address, a data transfer type, and a polling interval. Any number of interfaces and endpoints can be defined within each configuration. 
     Examples of processes that can be used to enable operation with a client device based on stored or cached enumeration information will now be described. 
       FIG. 4  is a flow diagram of a process  400  for enabling operation with a client device according to an embodiment of the present invention. Process  400  can be performed by e.g., host device  110  of  FIG. 1 . Communication among the various entities in process  400  can be facilitated by any suitable communication protocol, such as the USB protocol. Process  400  can be used, in certain embodiments, to communicate with a USB client device. 
     At block  402 , host device  110  can detect an unconfigured client device  130  (i.e. client device not enabled for operation) connected to it via a port of client I/O interface  118 . Client I/O interface  118  can be connected to client device  130  through any suitable connection type. For example, client I/O interface  118  can be connected to client device  130  through a USB HSIC or traditional USB connection. In certain embodiments, host device  110  can perform detection of client device  130  in any suitable manner. For instance, host device  110  can detect client device  130  according to the specifications provided by USB and/or USB HSIC standards. 
     In some embodiments, host device  110 &#39;s detection of unconfigured client device  130  can be caused by a triggering event. For example, host device  110  and client device  130  can be components of a smartphone. Powering on the smartphone can cause client device  130  to become active and cause host device  110  to detect client device  130 &#39;s presence. As another example, host device  110  and client device  130  can again be components of a smartphone. Host device  110  can be enabled for operation with client device  130  after the smartphone is powered on. During operation of the smartphone, client device  130  can be suspended or powered down in order to conserve power. At a later time, client device  130  can be woken up from suspension or powered back on, which can cause host device  110  to detect client device  130 &#39;s presence. It should be noted that because client device  130  was previously suspended or powered down, host device  110  can consider client device  130  to be unconfigured. 
     After detecting unconfigured client device  130 , host device  110  can initiate a configuration process. Through the configuration process, host device  110  can set up or enable operation with client device  130 . For example, host device  110  can be a single chip (integrated circuit) applications processor of a smartphone. Client device  130  can be a single chip DSP co-processor of the smartphone that can provide mobile telephone communication capabilities to host device  110 . Host device  110  and client device  130  can be embedded in a single PCB and connected by a PCB trace or set of PCB traces according to USB HSIC standards. By performing a configuration process, host device  110  can enable operation with and access the mobile telephone communication capabilities provided by client device  130 . 
     At block  404 , host device  110  can begin a configuration process by resetting client device  130 . By resetting client device  130 , host device  110  can cause client device  130  to operate in its default state. While client device  130  is in its default state, host device  110  can communicate with client device  130  using a default device address. 
     At block  406 , host device  110  can determine whether enumeration information for client device  130  has been stored or cached in volatile storage device  120  and/or non-volatile storage device  112 . Host device  110  can make such a determination in any suitable manner. In some embodiments, host device  110  can determine the port to which client device  130  has been connected. Based on the port, host device  110  can determine whether enumeration information for client device  130  is stored in volatile storage device  120  and/or non-volatile storage device  112 . For example, host device  110  can search for enumeration information, based on an identifier for the port (e.g., port number), in a database or look-up table stored in volatile storage device  120  and/or non-volatile storage device  112 . In cases where the physical connection between the host device and the client device is essentially permanent (e.g., devices mounted or embedded in a PCB), the same client can be presumed to be connected to a particular port. 
     If it is determined that enumeration information for client device  130  is not located in volatile storage device  120  and/or non-volatile storage device  112 , host device  110  can initiate an enumeration process at block  408 . In particular, host device  110  can request and receive enumeration information from client device  130 . In some embodiments, the enumeration process can include multiple requests and responses for enumeration information. 
     In some embodiments, host device  110  can begin the enumeration process by sending a request for all or a portion of client device  130 &#39;s enumeration information. For example, host device  110  can send a descriptor request (e.g., a USB “Get Descriptor” request) to client device  130 . Host device  110  can receive, in response to the request, a portion or all of client device  130 &#39;s enumeration information. For instance, host device  110  can receive the whole or a portion of client device  130 &#39;s device descriptor. The host device  110  can use the enumeration information to determine, for example, the maximum packet size supported by client device  130 &#39;s default endpoint (i.e. endpoint 0). 
     In certain embodiments, as part of the enumeration process, host device  110  can, again, reset client device  130 . After the second reset, host device  110  can assign a unique 7-bit address to client device  130  (e.g., by sending a USB “Set Address” request). From this point forward, host device  110  can communicate with client device  130  based on the assigned address. Following assignment of the address, host device  110  can request and receive all (or a portion necessary to enable operation) of client device  130 &#39;s enumeration information. For example, host device  110  can send a descriptor request to client device  130  (e.g., a USB “Get Descriptor” request). Based on the request, host device  110  can receive client device  130 &#39;s device descriptor. In some embodiments, the device descriptor can include the number of configurations supported by the client device and other basic information. After receiving the device descriptor, host device  110  can request, from client device  130 , each of the client device&#39;s configuration descriptors, and receive, in response, the configuration descriptors and any subordinate descriptors (i.e., interface, endpoint, and string descriptors). In some embodiments, host device  110  can repeatedly send requests to client device  130  until all (or a portion sufficient to enable operation) of client device  130 &#39;s enumeration information is obtained. 
     At block  410 , host device  110  can set up operation with client device  130  based on the enumeration information received from client device  130  during the enumeration process. For example, host device  110  can use the enumeration information to determine and load drivers for client device  130 , etc. 
     At block  412 , host device  110  can cache or store the enumeration information received from client device  130 . The enumeration information can be stored or cached in any suitable manner. For example, host device  110  can store or cache the enumeration information in volatile storage device  120 . By storing or caching the enumeration information in volatile storage device  120 , host device  110  can quickly retrieve the enumeration information at a later time during the operation of host device  110 . In some embodiments, host device  110  can additionally or alternatively store the enumeration information in non-volatile storage device  112 . Storing the enumeration information in non-volatile storage device  112  allows the enumeration information to be retrieved even after the host device  110  has been powered down or rebooted. For example, host device  110  can store the enumeration information in a database or look-up table residing on a file system of non-volatile storage device  112 . At a later time, host device  110  (or the entire device within which host device  110  is contained) can be powered down and powered back on. Because the enumeration information was previously stored in non-volatile storage device  112 , host device  110  can retrieve the enumeration information despite having been powered down. In some embodiments, upon boot up (e.g., starting an operating system executed by processor  116 ), host device  110  can automatically retrieve all stored enumeration information on non-volatile storage device  112  and cache the enumeration information in volatile storage device  120 . For example, upon a boot-up, host device  110  can cache or store, in volatile storage device  120 , the enumeration information for three (or any other number of) separate client devices. 
     In some embodiments, the enumeration information can be stored or cached based on the port to which client device  130  is connected. For example, if client device  130  is connected to port A of client I/O interface  118 , host device  110  can store the enumeration information based on an identifier for port A in a database or look-up table residing on non-volatile storage device  112  and/or volatile storage device  120 . 
     Referring again to block  406 , if it is determined that enumeration information for client device  130  is stored or cached in volatile storage device  120  and/or non-volatile storage device  112 , host device  110  can retrieve the enumeration information for client device  130  at block  414 . For example, host device  110  can retrieve a database or look-up table record containing the enumeration information from a database or look-up table residing on non-volatile storage device  112  and/or volatile storage device  120 . In some embodiments, host device  110  can retrieve the database or look-up table record based on the port to which client device  130  is connected. As another example, host device  110  can retrieve client device  130 &#39;s enumeration information from a file residing on non-volatile storage device  112  and/or volatile storage device  120 . In certain embodiments, the file can be identified by a database or look-up table record associated with the port to which client device  130  is connected. 
     Based on the retrieved enumeration information, host device  110  can set up operation with client device  130  at block  416 . In some embodiments, host device  110  can assign client device  130  a unique 7-bit address (e.g., by sending a USB “Set Address” request). From this point forward, host device  110  can communicate with host device  130  using the assigned address. After or in parallel to the assignment of the unique address, host device  110  can set up operation with client device  130  based on the retrieved enumeration information. For example, host device  110  can use the enumeration information to identify and load the proper drivers for client device  130 , etc. 
     By enabling operation with stored or cached enumeration information (which can be retrieved relatively quickly), host device  110  can configure a connection or link to a client without the added transaction time associated with requesting and receiving enumeration information from client device  130 . As a result, the total time for performing a configuration process can be reduced. 
     In some embodiments, host device  110  can, nonetheless, receive enumeration information from client device  130  in order to maintain compatibility (e.g., client device  130  can be a USB client device that requires host devices to initiate an enumeration process). In such embodiments, the enumeration information received from client device  130  can be ignored or not used by host device  110 . Instead, host device  110  can begin the process of enabling operation using stored or cached enumeration information while waiting to receive enumeration information from client device  130 . Thus, total time to perform an enumeration can still be reduced. 
     At block  418 , host device  110  can send a configuration value to client device  130  indicating that client device  130  is in the “configured state” and enabled for operation with host device  110 . Once operation is enabled, host device  110  can access the functionality provided by client device  130 . 
     In some embodiments, a host device can be connected to different client devices at different times through the same port. For example, a host device can be a laptop computer. At a first time, a user can connect a portable multimedia player to the laptop computer&#39;s USB port. At a later time, the user can disconnect the portable multimedia player, and in its place, connect an external speaker. In such embodiments, enumeration information cannot be stored based solely on the port to which a client device is connected. Otherwise, the incorrect enumeration information can be used.  FIG. 5  is a flow diagram of a process  500  for enabling operation with a client device, in situations where different client devices can be connected to the same port, according to another embodiment of the present invention. Process  500  can be performed by e.g., host device  210  of  FIG. 2 . Communication among the various entities in process  500  can be facilitated by any suitable communication protocol, such as the USB protocol. Process  500  can be used, in certain embodiments, to communicate with a USB client device. Blocks  502 ,  504 ,  510 ,  512 ,  514 ,  516 ,  518 ,  520 , and  522  can be similar to blocks  402 ,  404 ,  406 ,  408 ,  410 ,  412 ,  414 ,  416 , and  418  respectively of process  400 . 
     At block  506 , host device  210  can request a portion of client device  230 &#39;s enumeration from client device  230 . For example, host device  210  can send client device  230  a descriptor request (e.g., a USB “Get Descriptor” request). At block  508 , host device can receive, in response to the request, a portion of client device  230 &#39;s enumeration information. For instance, host device  210  can receive the whole or a portion of client device  230 &#39;s device descriptor. The host device  210  can use the received enumeration information to determine, for example, the maximum packet size supported by client device  230 &#39;s default endpoint (i.e. endpoint 0). In some embodiments, the received enumeration information can include device identifiers. Device identifiers can include, for instance, identifiers for client device  230 &#39;s vendor, product, device, manufacturer, serial number, and/or the like. 
     At block  510 , host device  210  can use the information (e.g., device identifiers) provided by the information received from client device  230  to determine whether enumeration information for client device  230  has been previously stored or cached in volatile storage device  220  and/or non-volatile storage device  212 . For example, host device  210  can use a vendor identifier, product identifier, device identifier, manufacturer identifier, product identifier, serial identifier, and/or any combination thereof to perform a search for enumeration information in a database or look-up table residing on non-volatile storage device  212  and/or volatile storage device  220 . By requesting only a portion of host device  210 &#39;s enumeration information (e.g., the whole or a portion of client device  230 &#39;s device descriptor), the amount of time spent receiving and requesting enumeration information can be minimized until it is determined whether enumeration information for client device  230  is stored. 
     As discussed, block  516  can be similar to block  412 . However, the enumeration information can be stored or cached based on any suitable device identifier, such as a vendor identifier, product identifier, device identifier, manufacturer identifier, product identifier, serial identifier, and/or in combination thereof. 
     It should be appreciated that the processes shown in  FIGS. 4 and 5  are illustrative and that variations and modifications are possible. Blocks described as sequential can be executed in parallel, order of blocks can be varied, and blocks can be modified, combined, added, or omitted. Furthermore, one of ordinary skill in the art will recognize that the processes shown in  FIGS. 4 and 5  can be implemented for other host devices. 
     Embodiments of the present invention can be realized using any combination of dedicated components and/or programmable processors and/or other programmable devices. The various processes described herein can be implemented on the same processor or different processors in any combination. Accordingly, where components are described as being configured to perform certain operations, such configuration can be accomplished, e.g., by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as microprocessors) to perform the operation, or any combination thereof. Processes can communicate using a variety of techniques including but not limited to conventional techniques for interprocess communication, and different pairs of processes can use different techniques, or the same pair of processes can use different techniques at different times. Further, while the embodiments described above can make reference to specific hardware and software components, those skilled in the art will appreciate that different combinations of hardware and/or software components can also be used and that particular operations described as being implemented in hardware might also be implemented in software or vice versa. 
     Computer programs incorporating various features of the present invention can be encoded on various computer readable storage media; suitable media include magnetic disk or tape, optical storage media such as compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. Computer readable media encoded with the program code can be packaged with a compatible electronic device, or the program code can be provided separately from electronic devices (e.g., via Internet download). 
     Thus, although the invention has been described with respect to specific embodiments, it will be appreciated that the invention is intended to cover all modifications and equivalents within the scope of the following claims.

Metadata:
Filing Date: 20110309
Publication Date: 20120529
Grant Date: 20120529
Priority Date: 20110309
Inventors: DALAL ANAND
ANDREWS JONATHAN J.
Assignee: APPLE INC
CPC Classifications: [{"code": "G06F13/14", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F2213/0042", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F2213/0042", "inventive": false, "first": false, "tree": "[]"}, {"code": "Y02D10/00", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F13/102", "inventive": true, "first": true, "tree": "[]"}, {"code": "Y02D10/00", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F13/14", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F13/102", "inventive": true, "first": true, "tree": "[]"}]
Family ID: 46086418