Patent Application
20070239921
In some embodiments of the invention, a conventional System Management Bus (SMB) is used as the underlying transport layer for communications between an auxiliary display subsystem (e.g., an auxiliary processor of an auxiliary display subsystem) and a secondary processor of a notebook, or between a secondary processor of a notebook and a keyboard controller or other element of the notebook. The bus protocols implemented by some embodiments of the invention for communication over an SMB between an auxiliary display subsystem (or other element of a notebook) and a secondary processor are compliant with the above-cited System Management Bus (SMB) Specification, Version 2.0. Notation used herein for SMB protocol description is consistent with that employed in the cited System Management Bus (SMB) Specification, Version 2.0.
Still with reference to
Notebook 1 also includes an auxiliary display subsystem (personal media display system 3, to be referred to as “PMD” 3) which includes microprocessor 5 (“auxiliary processor” 5), auxiliary display 7 (coupled to and driven by microprocessor 5), and typically also other elements (to be described below). Microprocessor 5 is coupled by an SMB to EC/KBC 11 for communication with EC/KBC 11, and EC/KBC 11 is configured to operate as a conventional SMB host. Microprocessor 5 is coupled by a conventional USB (universal serial bus) to PC chipset 9 for communication with PC chipset 9. Typically, microprocessor 5 communicates with EC/KBC 11 over the SMB when chipset 9 is in a low-power state (e.g., a standby or hibernation state) or when chipset 9 is fully awake (and in a state in which it consumes full power), and microprocessor 5 communicates with chipset 9 over the USB when chipset 9 is fully awake (and in a state in which it consumes full power).
Notebook 1 typically includes elements (not shown in
PMD 3 typically also includes other elements (not shown in
Examples of system status data that can be received by PMD 3 (e.g., for display on auxiliary display 7) from the non-PMD portion of notebook 1 (e.g., from EC 11 as described below) include indications that notebook 1 is on, off, shutting down, or powering up, indications that notebook 1 is in a standby, suspended, or hibernation state, indications that a battery of notebook 1 is charging or discharging, indications of the charge level of a battery of notebook 1, low battery alarms, indications that communication with the non-PMD portion of notebook 1 is in progress, notifications that the non-PMD portion of notebook 1 has received new email, and current time and date updates.
PMD 3 can also be configured to perform, while PC chipset 9 is in a standby or other low-power state, other functions (e.g., answering incoming telephone calls) that other elements of notebook 1 could perform if notebook 1 were in a fully-powered, normal operating state. When PC chipset 9 is in a low-power state, other major power-consuming elements of notebook 1 (e.g., main display 17) are typically off or in a standby or other low-power state so that notebook 1 as a whole is in a low-power state. Preferably, microprocessor 5 and other elements of PMD 3 are implemented to consume less power (preferably, much less power) than consumed by the elements of notebook 1 other than PMD 3 in a fully-powered, normal operating state. Thus, a user can employ PMD 3 to conserve power while performing useful functions of notebook 1 (while notebook 1 is in a low-power state), without the need to cause notebook 1's CPU (implemented by PC chipset 9) to boot up (which would typically consume significant time).
Functions that can be performed by various embodiments of PMD 3 include cached music file playing (with optional equalization, sample rate conversion, or other audio post processing), display of cached picture slide shows (e.g., on auxiliary display 7), display of world clock, time, and date information, stop watch functionality, display of contact lists, email, reminder memos, timed memos, task lists, battery and other information regarding notebook 1 and users thereof (e.g., user name and information, system information, manufacturer, serial number and model number, OEM support, technical contact information, and logos), password/screen lock support functions, system functions (e.g., placing notebook in an on, off, hibernation, standby, or suspend state), and lid-closed notebook system and application control functions.
In the
Fingerprint sensor 27 is used to authenticate users of PMD 3, using user identity data cached in memory (e.g., memory 29 or 31) of PMD 3. When typically programmed, PMD 3 can be placed in a locked state in which it can be unlocked by an authorized user only after PMD 3 successfully authenticates the user (even while notebook 1 is in a standby state or other low-power state, and without waking up notebook 1) including by comparing user biometric data (e.g., a fingerprint) with cached biometric data.
In the
PMD 3 is typically configured to cache (e.g., in memory 29 and/or memory 31) data received from other elements of notebook 1 as a result of communication over the USB between microprocessor 5 and PC chipset 9. PMD 3 is typically configured to display such cached data (in the case that the cached data are video or other image data) on auxiliary display 7 and to play back the cached data (in the case that the cached data are audio data) on loudspeakers (not shown) of notebook 1. PMD 3 is typically also configured to display (on auxiliary display 7) system status data received by microprocessor 5 from EC/KBC 11 over the SMB. Microprocessor 5 (and other elements of PMD 3) can also be configured to implement digital rights management (e.g., to decrypt content received from elements of notebook 1 external to PMD 3, and to store, in read-only memory, unique identification data for digital rights management algorithms).
PMD 3 is typically also configured to perform one or more of the following functions:
provide low power, instant access to music and multimedia content cached in memory (e.g., memory 29 and/or memory 31) of PMD 3 and other information (e.g., critical information) cached in memory of PMD 3 (e.g., frequently used information transferred from other elements of notebook 1 and cached in PMD 3 before notebook 1 enters a standby or other low-power state);
allow a user to control notebook 1 with the cover of main display 17 closed (e.g., by waking up notebook 1 and controlling notebook 1 by actuating controls on or associated with auxiliary display 7, while main display 17 is covered and thus protected and unavailable); and
provide other functionality such as generating alarms (e.g., for elapsed time or scheduled events, or low battery alarms indicating that notebook 1's battery is nearly discharged), implementing user authentication (or other security functions) preliminary to booting of notebook 1's CPU, collecting and monitoring system diagnostics data (e.g., data indicating whether notebook 1 is shutting down, powering up, whether notebook 1 is in an on, off, standby, suspended, or hibernation state, whether notebook 1's battery is charging/discharging, and the charge level of notebook 1's battery), and communicating with notebook 1's operating system software regarding system power management policies.
Microprocessor 5 is preferably programmed with firmware for executing appropriate functions and with software for executing functions including the following: boot block (e.g., for initializing microprocessor 5's CPU and PMD 3's flash memory 29 and other memory, authenticating a firmware boot loader in PMD 3's flash memory 29, and loading and executing a firmware boot loader), boot loader support (stored in PMD 3's flash memory 29, for authenticating firmware and device drivers and executing firmware), firmware kernel, file system, graphic tool kit, and drivers (e.g., USB, SMB, I2S, display controller, touch screen, and JTAG debugger support).
Several elements of the
We next describe communication over an SMB between an auxiliary processor and a secondary processor (e.g., auxiliary processor 5 and secondary processor 11 of
In a class of implementations of
In some such implementations, microprocessor 5 (an SMB device acting as bus master) sends messages to EC/KBC 11 (an SMB host controller acting as bus slave) in accordance with the SMB host notify protocol described in the above-cited SMB specification. In accordance with this protocol, the SMB device master can send to the SMB host controller (functioning as an SMB slave) 16-bit messages (each preceded by two 8-bit words that indicate the target and sending device addresses, with transmission of each 8-bit word followed by an “acknowledge” bit) in the following format:
In the previous paragraph, “S” denotes the conventional SMB “start condition” which the transmitter of the message (the SMB device master) must assert on the SMB to indicate the start of transmission of a message comprising a number of 8-bit packets separated by “acknowledge” bits, “Wr” denotes a command bit (whose bit value is 0 during transmission in accordance with the host notify protocol), “A” denotes an acknowledge bit (whose value is 0 for an ACK and 1 for a NACK), “P” denotes the conventional SMB “stop condition” which the message transmitter asserts on the SMB to indicate the end of transmission of a message, and the two 8-bit words “Data Byte Low” and “Data Byte High” are the body of the message. The 8-bit sending device address indicates to the message recipient (the SMB host controller slave) the origin of the message.
Depending on the command field value (the above-indicated 8-bit word “Data Byte Low”), all messages from microprocessor 5 to EC/KBC 11 can be divided into two categories: data requests and action requests.
In some embodiments, data requests (asserted from microprocessor 5 to EC/KBC 11) have the format indicated in Tables 1 and 2 below. Table 1 indicates the format of each data request's command field value (the above-indicated 8-bit word “Data Byte Low”), and Table 2 indicates the format of each data request's sub-command field value (the above-indicated 8-bit word “Data Byte High”) and bits 3:0 of the data request's command field.
In accordance with some embodiments, action requests (asserted from microprocessor 5 to EC/KBC 11) have the format indicated in Tables 3 and 4 below. Table 3 indicates the format of each action request's command field value (the above-indicated 8-bit word “Data Byte Low”), and Table 4 indicates the format of each action request's sub-command field value (the above-indicated 8-bit word “Data Byte High”) and bits 3:0 of the action request's command field.
In Tables 3 and 4, “GPIO” denotes “general purpose input/output.” Action requests having the values indicated in Tables 3 and 4 in their command and sub-command fields can be asserted over the SMB to EC/KBC 11 to cause EC/KBC 11 to assert values (indicated by the messages) on specific GPIO pins of EC/KBC 11 (also indicated by the messages) to control other elements of the notebook. The GPIO connections (to the elements of the notebook to be controlled) could be of a type present in a conventional notebook, but they are controlled in some embodiments of the present invention by action requests asserted from PMD 3 over an SMB (or another serial bus, in alternative embodiments) to EC/KBC 11 (or another embedded controller). For example (in one embodiment), microprocessor 5 of PMD 3 could assert action request messages over the SMB of
In variations on the notebook of
We next describe messages sent over the SMB from EC/KBC 11 (an SMB host controller acting as bus master) to microprocessor 5 (an SMB device acting as bus slave), or from another SMB host controller acting as bus master to microprocessor 5 (or another SMB device acting as bus slave). In some embodiments, the SMB write block protocol with the following format is used for all messages sent over the SMB from EC/KBC 11 (acting as bus master) to microprocessor 5. In accordance with this protocol, the SMB host controller master can send to microprocessor 5 (functioning as an SMB slave) N*8-bit messages (where N is an integer), each preceded by three 8-bit words that indicate microprocessor 5's address, a data report command, and a message byte count (indicative of the value of N), with transmission of each 8-bit word followed by an “acknowledge” bit) in the following format:
1
In the previous paragraph, “S” denotes the conventional SMB “start condition” which the transmitter of the message (the SMB host controller acting as bus master) must assert on the SMB to indicate the start of transmission of a message comprising a number of 8-bit packets separated by “acknowledge” bits, “Wr” denotes a command bit (whose bit value is 0 during transmission in accordance with the write block protocol), “A” denotes an acknowledge bit (whose value is 0 for an ACK and 1 for a NACK), “PEC” is a Packet Error Code, “P” denotes the conventional SMB “stop condition” which the message transmitter asserts on the SMB to indicate the end of transmission of a message, and the N 8-bit words “Data Byte” are the body of the message. The 7-bit slave address is the address of microprocessor 5. The Packet Error Code (PEC) byte is an optional CRC-8 error checking byte, and if included, it is appended after the last Data Byte of the message body and its usage is consistent with the PEC support bit included in an EC Capabilities Report (see Table 8 below).
Messages having the above-described format that are sent over the SMB from EC/KBC 11 (acting as bus master) to microprocessor 5 (acting as bus slave) are Data Report messages (each comprising N bytes that follow three initial address, command, and message byte count bytes), with the first byte of each N-byte message being a sub-command (i.e., the sub-command field of the Data Report Message), and the second byte of each N-byte message being a Report Status byte. A non-zero value of the Report Status byte indicates report failure. If the Report Status byte has a zero value, the report data transferred in the subsequent bytes of the message provide system information according to the command and sub-command fields.
The command byte transmitted following the address byte is sometimes denoted herein as the Command field of the Data Report Message. The content of the Command and Sub-Command fields of Data Report Messages from EC/KBC 11 is summarized in Table 5 and Table 6 below.
The Command and Sub-Command fields for each Data Report message from EC/KBC 11 are the same as the respective fields in the above-described data requests from microprocessor 5 with one exception: a “no requestor” tag can be specified if a Data Report is initiated by EC/KBC 11 itself (and is not a response to a data request from microprocessor 5).
Table 7 specifies values of the Report Status byte (the above-described second byte) of each N-byte Data Report message, and allowable Byte Count values that correspond to each value of the Report Status byte.
No data is reported by failed report (no data bytes follow a Report Status byte having a non-zero value). Data fields for all successful Data Reports from EC/KBC 11 are defined below (the requester tag for all report examples below is set to 001b).
Table 8 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of an “EC Capabilities” Data Report message (indicated in Tables 1 and 5 above).
Table 11 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “System Status” Data Report message (indicated in Tables 1 and 5 above).
Table 13 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Slot Status and Capacity Gauge” type (indicated in Table 6 above).
Table 15 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Voltage” type (indicated in Table 6 above).
Table 16 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Remaining Time to Empty” type (indicated in Table 6 above).
Table 17 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Charging/Discharging Rate” type (indicated in Table 6 above).
Table 18 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Remaining Capacity” type (indicated in Table 6 above).
Table 19 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Last Full Charge Capacity” type (indicated in Table 6 above).
Table 20 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Design Capacity” type (indicated in Table 6 above).
Table 21 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Manufacturer” type (indicated in Table 6 above).
Table 22 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Model” type (indicated in Table 6 above).
Table 23 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Type” type (indicated in Table 6 above).
In some embodiments, EC/KBC 11 is configured to follow the following behavioral rules for communication with microprocessor 5 over the SMB:
Notebook 100 of
Notebook 100 differs from notebook 1 in that PMD 103 of notebook 100 does not include its own auxiliary display. PMD 103 generates display data of the same type that are displayed on auxiliary display 7 of notebook 1, but sends the display data to timing controller 108 (following optional processing) with proper timing for display on all or part of the screen of main display 107. Main display 107 of notebook 100 can be identical to main display 17 of notebook 1, but is coupled to receive display data from timing controller 108 rather than display data directly from graphics chipset 15. Alternatively, main display 107 is replaced by a main display that includes timing controller 108 and an array of pixels (backlit liquid crystal cells or other light-emitting elements), and timing controller 108 asserts display data to the pixels (or column drivers or other pixel driving circuitry) of the main display.
Timing controller 108 is configured to be operable in a mode in which it generates display data from raw display data asserted thereto by microprocessor 105 (e.g., by scaling the raw display data) and asserts the scaled data with timing for display on the screen of display 107 (e.g., in a small region of the screen of display 107), and also to be operable to assert display data from graphics chipset 15 for display on the screen of display 107. Optionally, timing controller 108 is configured to be operable in a mode in which it combines (multiplexes) display data from microprocessor 105 (or a scaled version of such data) with display data from graphics chipset 15 (e.g., so that data from microprocessor 105 or a scaled version thereof can be displayed in a small region of display 107's screen, while display data from graphics chipset 15 is displayed on the rest of display 107's screen).
Preferably, display 107 is an LCD of a type whose pixels (individual backlit liquid crystal cells) can be independently lit (e.g., independently backlit by independently controllable LEDs or other light sources) or a display of another type whose pixels can be independently powered and lit (e.g., independently backlit by independently controllable LEDs or other light sources). In such preferred embodiments, microprocessor 105 generates display data and asserts the display data (e.g., as 8-bit display data over a parallel link, or as serial data over an LVDS, or “low voltage differential signaling,” serial link) for display in only a small region of the screen of display 107, and timing controller 108 asserts the display data (or a scaled version thereof) to the screen of display 107 with appropriate timing for display in the appropriate small region of display 107's screen. Microprocessor 105 is preferably configured to power only the pixels of display 107's screen in the region in which the display data from PMD 103 are to be displayed, thereby conserving power (e.g., when notebook 100 is in a sleep or other low-power state).
In the case that microprocessor 105 of PMD 103 is coupled by an SMB to EC/KBC 11, microprocessor 105 can be identical to microprocessor 5 of
In the implementation shown in
In some embodiments, multiplexer 59 can be controlled to generate combined data by multiplexing the data received at its inputs, and to assert the combined data to main display 107 with timing such that when the combined data are displayed on main display 107, display data from microprocessor 105 (or a scaled version thereof) are displayed in a region (e.g., a small region) of display 107's screen, and display data from graphics chipset 15 are displayed on the rest of display 107's screen.
In alternative embodiments, scaler 58 is omitted and timing controller 108 includes a multiplexer (e.g. multiplexer 59) that can be controlled to assert raw auxiliary display data it receives from microprocessor 105 (or another element of an auxiliary display subsystem) to main display 107 for display on display 107's screen. Preferably, such multiplexer can also be controlled (e.g., while the notebook is in a fully powered state) to assert data it receives from graphics chipset 15 (rather than data it receives from the auxiliary display subsystem) to main display 107 with timing for display on display 107's screen.
Main display 107 can be implemented as shown in
Thus, microprocessor 105 can control the consumption of power by main display 207 to prevent consumption of power by those pixels that are not needed to display scaled data from microprocessor 105 in a region (e.g., a small region) of display 107's screen. With reference to
In other embodiments of the inventive notebook, a main display (e.g., main display 107 of
In other embodiments of the inventive notebook, a main display (e.g., main display 107 of
In a class of implementations of the
In a class of embodiments of the inventive notebook, an auxiliary display subsystem (e.g., microprocessor 105 or another element of the auxiliary display subsystem that includes microprocessor 105) and a main display of the notebook are configured to power selected pixels of the main display in a region of the main display's screen in which data from the auxiliary display subsystem (or a scaled version of such data) are to be displayed, thereby conserving power (e.g., when the notebook is in a sleep or other low-power state).
We next describe embodiments of the invention with reference to
Embedded controller 403 (which also functions as a keyboard controller) includes a GPIO interface that is coupled by a serial bus (e.g., an SMB, I2C bus, or other two-wire serial bus, or a USB link) to auxiliary processor 411. Embedded controller 403 is also coupled by a conventional link to keyboard 402, and is optionally also coupled by a four-wire USB link to chipset 405.
In some implementations, auxiliary processor 411 of
Embedded controller 403 is coupled to chipset 405 by a conventional low pin count (“LPC”) bus, to touch pad 425 and keyboard 402 as described, to auxiliary processor 411 by a serial bus which is preferably a two-conductor serial bus (e.g., an SMB, I2C bus, or other two-wire serial bus), and typically also to other elements (not shown in
In some implementations of notebook 400, auxiliary processor 411 is the auxiliary processor of an auxiliary display subsystem (e.g., an auxiliary display subsystem of notebook 400 similar or identical to PMD 103 of
In some implementations of notebook 400 (and in variations on notebook 400), auxiliary processor 411 (or a similar auxiliary processor) is the auxiliary processor of an auxiliary display subsystem that includes additional elements not shown in
In implementations of notebook 400 in which auxiliary processor 411 is the auxiliary processor of an auxiliary display subsystem similar or identical to PMD 103 of
In notebook 400 of
In some embodiments of the inventive notebook, the notebook includes one or both of: a multiplexer having an input coupled to a content source (e.g., a DVD drive) and outputs coupled to an auxiliary processor and a PC chipset; and a multiplexer having an input coupled to a hard disk drive and outputs coupled to an auxiliary processor and PC chipset 405.
In
In some implementations of notebook 400, main display 413 is implemented to have an array of pixels that are selectively and individually powerable or an array of pixels of which rows and columns are selectively and individually powerable. In these implementations, notebook 400's auxiliary display subsystem or an auxiliary processor thereof (e.g., auxiliary processor 411 of
In some implementations, the auxiliary processor of the inventive notebook (e.g., processor 5 of
In any embodiment of the inventive notebook, when a first element (e.g., an auxiliary processor or other secondary processor) of the notebook is coupled by an SMB to a second element of the notebook (e.g., a keyboard controller), messages are preferably sent between the first element and second element over the SMB in the format described above with reference to Tables 1-23. In any embodiment of the inventive notebook, when a first element (e.g., an auxiliary processor or other secondary processor) of the notebook is coupled by an I2C bus to a second element of the notebook (e.g., a keyboard controller), messages of the same type described above with reference to Tables 1-23 can be sent between the first element and second element over the I2C bus in an appropriate format that will be apparent to those of ordinary skill in the art in view of the description herein.
In some embodiments, the inventive notebook comprises subsystems that are detachable from each other. For example, it is contemplated that some embodiments of the notebook will include an auxiliary display subsystem (e.g., PMD 3 of
Other aspects of the invention are methods implemented by any embodiment of the inventive notebook. For example, one such method is performed by a notebook including an auxiliary processor and a keyboard controller, and includes the step of: sending data from one of the auxiliary processor and the keyboard controller over a serial bus (e.g., an SMB, I2C bus or other two-wire serial bus), to the other of the auxiliary processor and the keyboard controller when the notebook is in a low-power state. The notebook can also include at least one other processor (e.g., a secondary processor or CPU), and the method can also include the step of sending data from one of the other processor and the keyboard controller to the other of the other processor and the keyboard controller when the notebook is in a fully powered state.
Another example of such a method is performed by a notebook including an auxiliary processor, a PC chipset, and at least one content source (e.g., a DVD drive) and includes the steps of: controlling a multiplexer to assert a signal (indicative of at least one of data, at least one address bit, and at least one control bit) from one of the content source and the auxiliary processor to the other of the content source and the auxiliary processor while the notebook is in a low-power state; and controlling the multiplexer to assert another signal (indicative of at least one of data, at least one address bit, and at least one control bit) from one of the content source and the PC chipset to the other of the content source and the PC chipset. Another example of such a method is performed by a notebook including an auxiliary processor, a PC chipset, and at least one hard disk drive, and includes the steps of: controlling a multiplexer to assert a signal (indicative of at least one of data, at least one address bit, and at least one control bit) from one of the hard disk drive and the auxiliary processor to the other of the hard disk drive and the auxiliary processor while the notebook is in a low-power state; and controlling the multiplexer to assert another signal (indicative of at least one of data, at least one address bit, and at least one control bit) from one of the hard disk drive and the PC chipset to the other of the hard disk drive and the PC chipset.
It should be understood that while some embodiments of the present invention are illustrated and described herein, the invention is defined by the claims and is not to be limited to the specific embodiments described and shown.
This application is a continuation-in-part of U.S. patent application Ser. No. 11/398,167, entitled “Method and System for Displaying Data from Auxiliary Display Subsystem of a Notebook on a Main Display of the Notebook” by Arman Toorians, filed on Apr. 5, 2006.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11398167 | Apr 2006 | US |
| Child | 11540047 | US |
