Method, system, and apparatus for servicing PS/2 devices within an extensible firmware interface environment

Methods, systems, and computer-readable media service PS/2 devices within an extensible firmware interface (EFI) environment where the PS/2 devices provide data via a keyboard controller. The method involves receiving a request for data from an EFI driver, in response to receiving the request, determining whether data from any of the PS/2 devices is available for delivery to one or more EFI drivers via the keyboard controller. The method further involves in response to determining that the data is available for delivery, dispatching the data from the keyboard controller based on which PS/2 devices provided the data and forwarding the data to the EFI drivers associated with a PS/2 device providing at least some of the data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is related to and filed with U.S. patent application Ser. No. 11/118,257, entitled “Tracking States of Communication Between PS/2 Hardware and Hardware Drivers within an Extensible Firmware Interface Environment,” filed on Apr. 29, 2005 which is assigned to the same assignee as this application. The aforementioned patent application is expressly incorporated herein, in its entirety, by reference.

TECHNICAL FIELD

The present invention generally relates to servicing multiple PS/2 (Personal System/2) devices. More particularly, the present invention relates to improved servicing of PS/2 devices within an extensible firmware interface environment.

BACKGROUND

In most computing systems, low level instruction code is used as an intermediary between the hardware components of the computing system and the operating software and other high-level software executing on the computing system. In some computer systems, this low level instruction code is known as the Basic Input and Output System (“BIOS”). The BIOS provides a set of software routines that allow high level software to interact with the hardware components of the computing system using standard calls.

Because of limitations of the BIOS in many PC-compatible computers, a new specification for creating the firmware that is responsible for booting the computer and for intermediating the communication between the operating system and the hardware has been proposed. The new specification is called the Extensible Firmware Interface (“EFI”) specification and is available from INTEL CORPORATION.

The EFI specification describes an interface between the operating system and the system firmware. In particular, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system may use in booting. How the firmware implements the interface is left up to the manufacturer of the firmware. The EFI specification provides protocols for EFI drivers to communicate with each other, and the EFI core provides functions such as allocation of memory, creating events, setting the clock, and many others. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the operating system by the platform and the firmware.

The EFI is capable of providing services to other applications. Services are implemented by modules that may be loaded by a boot loader when the EFI is started. The services may provide memory management, domain services, driver services, protocol services, and others. The EFI specification has a specific requirement for servicing hardware devices that drivers cannot use an interrupt request line (“IRQ”) from hardware, such as from a PS/2 controller, and thus, EFI drivers must poll the hardware. Handling or servicing PS/2 devices in this manner by employing timer events causes inefficiency and data loss. Problems with one PS/2 device blocking another PS/2 device develop when an application does not access a device for some time.

Applications utilize specified protocols to observe input from hardware. Thus, there are multiple ways to implement an EFI driver and support the protocols. One way is to setup a timer and periodically poll the state of the PS/2 controller to ascertain whether any input data is present. Periodic polling is necessary to prevent one device from blocking another device's input. This blocking occurs when data from one source is in the PS/2 keyboard controller, but has not been taken away for a long time. In such a situation another device's data cannot pass through the controller to the corresponding driver.

PS/2 controllers have one common data out port that latches the data from the first device that produced it. Thus, periodic polling reads the data from a PS/2 device even if it is not requested by the application in order to give another source input a chance to pass data to the user. However, having two timers is an overhead that can slow down a computing system. Moreover, the basis for selecting the polling frequency is arbitrary at best and depends on user activity. Accordingly, there is a need for a method, system, and apparatus for servicing PS/2 devices within an EFI environment.

It is with respect to these considerations and others that the various embodiments of the invention have been made.

SUMMARY

In accordance with the present invention, the above and other problems are solved by methods, systems, and computer-readable mediums for servicing PS/2 devices within an EFI environment. Through the use of a novel EFI PS/2 driver in direct communication with the keyboard controller, embodiments of the invention service PS/2 devices within an EFI environment by retrieving both mouse and keyboard data and making that data available to the corresponding EFI mouse or keyboard drivers. Because a common driver distributes the mouse and keyboard data between the EFI mouse and keyboard drivers, the data distribution is more efficient, the size of the EFI mouse and the EFI keyboard drivers can be reduced, and problems with one device blocking another device's input are prevented.

According to one embodiment of the invention, a method is provided for servicing PS/2 devices within an EFI environment where the PS/2 devices provide data via a common input device controller. The method involves receiving a request for data from an EFI driver associated with the EFI environment and in response to receiving the request, determining whether data from any of the PS/2 devices is available for delivery to one or more EFI drivers via the common input device controller. The method also involves dispatching the data from the common input device controller based on which PS/2 devices provided the data in response to determining that the data is available for delivery.

Another embodiment is a computer-readable medium having control logic stored therein for causing a computer to service PS/2 devices within an EFI environment where the PS/2 devices provide data via a keyboard controller. The control logic includes computer-readable program code for causing the computer to receive a request for data from an EFI driver associated with the EFI environment, determine whether data from any of the PS/2 devices is available for delivery to one or more EFI drivers via the keyboard controller in response to receiving the request, and in response to determining that the data is available for delivery, dispatch the data from the keyboard controller based on which PS/2 devices provided the data. The control logic also includes computer-readable program code for causing the computer to forward the data to the EFI drivers associated with a PS/2 device providing at least some of the data.

Still another embodiment is a method for servicing PS/2 devices within an EFI environment where the PS/2 devices provide data via a keyboard controller. The method involves determining whether data from any of the PS/2 devices is available for delivery to one or more EFI drivers via the keyboard controller, dispatching data from the keyboard controller based on which PS/2 devices provided the data, and forwarding the data to the EFI drivers associated with a PS/2 device providing at least some of the data.

DETAILED DESCRIPTION

Embodiments of the present invention provide methods, systems, apparatuses, and computer-readable media for servicing PS/2 devices within an EFI environment. In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments or examples. Referring now to the drawings, in which like numerals represent like elements throughout the several figures, aspects of the present invention and the exemplary operating environment will be described.

FIG. 1and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. While the invention will be described in the general context of program modules that execute in conjunction with the execution of a computer firmware, those skilled in the art will recognize that the invention may also be implemented in combination with other program modules.

Turning now toFIG. 1, an illustrative computer architecture for a computer2utilized in the various embodiments of the invention will be described. The computer architecture shown inFIG. 1illustrates a conventional computer, including a CPU4, a system memory6, including a RAM18, an EEPROM20, a CMOS memory24, and a system bus12that couples the memory to the CPU4. According to an embodiment of the invention, the CPU4may comprise a general purpose microprocessor from INTEL CORPORATION. For instance, the CPU4may comprise a PENTIUM 4 or XEON microprocessor from INTEL CORPORATION. It should be appreciated that any type of CPU may be utilized including INTEL-compatible devices from AMD, MIPS processors, POWERPC devices from IBM, or other types of RISC or CISC processors.

The EEPROM20may store a firmware22for use in operating the computer2, such as a BIOS or an extensible firmware interface (“EFI”), containing the basic routines that perform basic platform initialization and prepare the computer2to launch an operating system. The CMOS memory24is a battery-backed memory device that may be used by the firmware22to store setting information for the computer2. In the case of an EFI firmware, the EEPROM20may be utilized to store configuration information. Additional details regarding the architecture and operation of the firmware22will be provided below with respect toFIGS. 2 and 3.

The computer2further includes a mass storage device8for storing an operating system26, an operating system loader image28, application programs, and other program modules. The mass storage device8is connected to the CPU4through a mass storage controller (not shown) connected to the bus12. The mass storage device8and its associated computer-readable media, provide non-volatile storage for the computer2. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed by the computer2.

According to various embodiments of the invention, the computer2may operate in a networked environment using logical connections to remote computers through a network30, such as the Internet. The computer2may connect to the network30through a local area network (“LAN”) adapter10connected to the bus12. It should be appreciated that the LAN adapter10may also be utilized to connect to other types of networks and remote computer systems. The computer2may also include a keyboard controller14for receiving input from a keyboard and a video display adapter16for providing output to a display screen.

Referring now toFIG. 2, additional details regarding the operation of the firmware22of the computer2will be described. According to embodiments of the invention, the firmware22may comprise a computer basic input output system (“BIOS”). As known to those skilled in the art, the BIOS of a PC-compatible computer provides an interface between the operating system26and the hardware36of the computer2. Alternatively, the firmware22may comprise a firmware compatible with the EFI specification ver. 1.1 from INTEL CORPORATION.

The EFI specification describes an interface between the operating system26and the system firmware22. The EFI specification defines the interface that platform firmware must implement, and the interface that the operating system26may use in booting. How the firmware22implements the interface is left up to the manufacturer of the firmware. The intent of the specification is to define a way for the operating system26and firmware22to communicate only information necessary to support the operating system boot process. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the operating system by the platform and the firmware.

According to one implementation of EFI on INTEL CORPORATION IA-32 platforms, both the EFI32and a BIOS34may be presented in the firmware22. This allows users and system integrators to support both firmware interfaces. In order to provide this functionality, an interface33may be provided for use by legacy operating systems and applications. Additional details regarding the architecture and operation of the EFI32are provided below with respect toFIG. 3. Moreover, additional details regarding the operation and architecture of EFI can be found in the EFI specification which is available from INTEL CORPORATION and is expressly incorporated herein by reference.

Turning now toFIG. 3, additional details regarding an EFI specification-compliant system utilized to provide an operating environment for the various embodiments of the invention will be described. As shown inFIG. 3, the system includes platform hardware46and an operating system26. The platform firmware42may retrieve an OS image51from the EFI system partition48using an EFI O/S loader28. The EFI system partition48may be an architecturally shareable system partition. As such, the EFI system partition48defines a partition and file system that are designed to allow safe sharing of mass storage between multiple vendors. An O/S partition50may also be utilized.

Once started, the EFI O/S loader28continues to boot the complete operating system26. In doing so, the EFI O/S loader28may use EFI boot services38and interface to other supported specifications to survey, comprehend, and initialize the various platform components and the operating system software that manages them. Thus, interfaces44from other specifications may also be present on the system. For example, the Advanced Configuration and Power Management Interface (“ACPI”) and the System Management BIOS (“SMBIOS”) specifications may be supported.

EFI boot services38provides interfaces for devices and system functionality that can be used during boot time. EFI runtime services40may also be available to the O/S loader28during the boot phase. For example, a minimal set of runtime services may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system26during its normal operation. EFI allows extension of platform firmware by loading EFI driver and EFI application images which, when loaded, have access to all EFI-defined runtime and boot services.

Various program modules provide the boot and runtime services. These program modules may be loaded by the EFI boot loader43at system boot time. The EFI boot loader43is a component in the EFI firmware that determines which program modules should be explicitly loaded and when. Once the EFI firmware is initialized, it passes control to the boot loader43. The boot loader43is then responsible for determining which of the program modules to load and in what order.

The various program modules executing within the EFI may have a need to store data in an easy to access and manage manner. Because the various program modules may utilize data of virtually any data type, there is also a need to store data of any arbitrary data type. The database engine41executes within the EFI and provides these services to other program modules executing within the EFI. The database engine41may be provided as a part of the EFI core or as a separate EFI driver. In particular, program modules executing within the EFI can utilize the database engine41to index stored data in a database. Records can be added to the database, removed from the database, and the database may be searched. Other types of database functions may also be performed on the records stored by the database engine41.

A major feature of the EFI environment is modularity. Thus, every piece of hardware, such as a keyboard and a mouse, may be represented by a driver. EFI drivers45are a set of independent drivers that are capable of communicating with each other. The EFI drivers45are designed to access boot devices in a pre-boot environment. These drivers may manage or control hardware buses or devices on a platform or they may provide some software derived platform specific service. An EFI driver installs itself as a protocol handler for a particular device. Additional details regarding some of the EFI drivers45will be described below with respect toFIGS. 4 and 5.

FIG. 4is a block diagram that illustrates various components of a layered operating environment utilized in servicing PS/2 devices, such as a PS/2 keyboard432and a PS/2 mouse434, according to an embodiment of the invention. As illustrated, the EFI drivers45within a software layer401include an EFI keyboard driver404, an EFI mouse driver407, and a PS/2 EFI driver418. The EFI keyboard driver404and the EFI mouse driver407are in communication with an application layer403including applications, such as a text editor application402. The PS/2 EFI driver418is in communication with the PS/2 keyboard controller14on a firmware layer405and the EFI keyboard driver404and the EFI mouse driver407on the software layer401. The PS/2 keyboard controller14receives data from the keyboard432and the mouse434on a device layer408. Moreover, additional details regarding the operation and architecture of PS/2 keyboard controllers and other PS/2 devices can be found in the IBM Personal System/2 and Personal Computer BIOS Interface Technical Reference. Second edition. IBM Corporation, IBM No. S68X-2341-00, 1988.

The EFI specification specifies SimpleInput and SimplePointer protocols that are implemented by the EFI keyboard driver404and the EFI mouse driver407respectfully. Applications, such as the text editor application402, use these protocols to observe input data from hardware, such as the keyboard432and the mouse434, as the EFI drivers45service the hardware. The PS/2 EFI driver418communicates directly with firmware, the keyboard controller14, of the hardware. The keyboard controller14services at least two different devices, the keyboard432and the mouse434. It should be appreciated that the mouse434may also be a touchpad or other pointer device.

The keyboard controller14includes two independent ports421and423that allow the keyboard and the mouse to connect to the same controller. The keyboard controller14includes a common data-in register430in communication with the keyboard port421and the mouse port423. Firmware427is also within the keyboard controller14. The firmware427allows the keyboard controller14to differentiate between data coming from the mouse434and data coming from the keyboard432. The firmware427communicates with the data-in register430and analyzes the data coming from the two ports421and423to determine an origin of the data.

The keyboard controller14also includes a common output or data-out register422, which is also the only output register for both devices. The data-out register422is accessible by the EFI drivers45. The PS/2 EFI driver418is able to distinguish whether the data has come from the mouse434or from the keyboard432by checking a keyboard status register420and/or a mouse status register424within the keyboard controller14. The PS2 EFI driver418, which includes the same required polling mechanism as the other drivers, serves as a single point for accessing the data-out register422of the keyboard controller14. A data distributor mechanism417is included in the PS/2 EFI driver418to dispatch the data from the keyboard432to a memory destination, such as a keyboard data buffer412, within the PS/2 EFI driver418for keyboard data. Similarly, when data is coming from the mouse434, this data will be dispatched or sorted to a memory destination, such as mouse data buffer419for the mouse data. Thus, there are at least two internal destinations for data prepared by the PS/2 EFI driver418from which the EFI keyboard driver404and the EFI mouse driver407receive data.

It should be appreciated that although polling of the keyboard controller14still occurs within the PS/2 EFI driver418, the status concerning data availability is not directly provided to the keyboard driver and mouse driver by the keyboard controller14. The status concerning data availability is provided to these drivers by the PS/2 EFI driver418. Because the PS/2 EFI driver418dispatches data from both devices, data is instantly available to the EFI mouse and keyboard drivers407and404whenever the data arrives at the keyboard controller14from the mouse434or the keyboard432.

For instance, a multi-byte sequence of data produced by someone pressing a keyboard key, for example a functional key such as F1, and clicking a mouse button is instantly made available to the EFI keyboard driver404and the EFI mouse driver407by the PS/2 EFI driver418when the data is forwarded to the keyboard controller14. Pressing a functional key can produce three scan codes KB1435, KB2437, and KB3438. Similarly, clicking a mouse button produces two scan codes M1440and M2442. In previous systems, scan codes M1and/or M2could possibly block scan codes KB1, KB2, and/or KB3from being available to a driver due to the common data-out port422and polling methodologies. In the present invention, the data will come to the data-in register430and will automatically be stored in a queue for the data that is recognized inside the firmware. Only KB1435will appear in the output register422at first. KB1435will remain in the output register waiting for a read command.

As briefly described above, when the mouse434is clicked or moved at the same time, the sequence of scan codes in the data-out register can stagger between keyboard data and mouse data. The PS/2 EFI driver418sorts the data to avoid irretrievability, because the F1key will only be retrievable if all three bytes of data KB1+KB2+KB3are read and the mouse-click on the mouse434can be retrieved only when both bytes M1+M2of data from the mouse are read. The PS/2 EFI driver418treats all the data from the output register422one-by-one. When the PS/2 EFI driver418recognizes keyboard data, it will distribute the keyboard data to the keyboard data buffer412. Similarly, when the PS/2 EFI driver418recognizes mouse data, it distributes the mouse data to the mouse data buffer419.

As illustrated, the data arrives at the data buffers412and419in the order it was sent, KB1, KB2, KB3at the keyboard data buffer412and M1and M2at the mouse data buffer419. Thus, the data becomes available in the data buffers412and419for consumption. In this illustrative embodiment, the consumer of the data is the EFI keyboard driver404and the EFI mouse driver407. These drivers will know about the availability of the data just by reading a corresponding keyboard or mouse data buffer empty indicator (BEI)406or406′ at a memory destination. Thus, when data has been dispatched from the keyboard controller14, the keyboard controller14is available for other keystrokes or the mouse movements while the PS/2 EFI driver418processes the data in the order it was sent.

Use of the PS/2 EFI driver418may begin when the text editor application402starts requesting the keys or requesting the mouse coordinates for display. The text editor application402produces a screen display and it needs user input. The text editor application402sends a loop asking the EFI keyboard driver404and/or the EFI mouse driver407for input and pointer data respectfully. Next, in response to the request from the text editor application402, the EFI keyboard driver404and/or the EFI mouse driver407requests data from the PS/2 EFI driver418. For instance, the EFI drivers404and407can verify whether data is present in the keyboard data buffer412or the mouse data buffer407by respectively checking the BEI406or406′. When the BEI406or406′ indicates that the buffer is not empty, the EFI drivers404and/or407read the memory destination that contains an indication of the presence of keyboard and/or mouse data.

The PS/2 EFI driver418then determines whether any data is available in the keyboard controller14by detecting a status of the keyboard status register420and the mouse status register424. If either status register indicates a presence of data, the PS/2 EFI driver418dispatches the data from the data-out register to the data distributor417and then distributes the data between the mouse and keyboard data destinations for delivery to the EFI keyboard and/or mouse drivers. When the data is dispatched the corresponding status register is cleared until more data arrives in the keyboard controller14. If no data is available the PS/2 EFI driver returns no data. Thus, the PS/2 EFI driver418may be initiated in response to a request from the mouse and/or keyboard driver for data. When the text editor application402request data a second time from the keyboard driver, the data will be waiting in the queue of the keyboard driver404ready to be passed to the text editor application402thereby improving efficiency. Additional details regarding servicing PS/2 devices will be described below with respect toFIG. 5.

Referring now toFIGS. 4 and 5, an illustrative routine500will be described in detail for servicing PS/2 devices within an EFI environment according to an embodiment of the invention. The logical operations of the various embodiments of the present invention are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, the logical operations making up the embodiments of the present invention described herein are referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims attached hereto.

The routine500begins at operation502, where the PS/2 EFI driver418receives a request for data from the EFI keyboard driver404and/or the EFI mouse driver407. For instance, the request for data may be in response to the text editor application402requesting data from the EFI keyboard driver404and/or the EFI mouse driver407for a screen display. From operation502, the routine500continues to operation504.

At operation504, in response to receiving the request for data, the PS/2 EFI driver418determines whether a keyboard status is set in the PS/2 keyboard controller14. The PS/2 EFI driver418determines the keyboard status by detecting whether the keyboard status register420indicates that keyboard data is available for dispatch in the keyboard controller14. When keys are pressed at the keyboard432, data, such as the scan codes435,437and438, is forwarded to the data-in register430. The firmware427examines the data and determines the origin of the data. When the data is from the keyboard432, the firmware427updates the keyboard status register420to indicate that keyboard data is present in the keyboard controller14. Similarly, when data is sent from the mouse434, the firmware427updates the mouse status register424to indicate mouse data, such as the scan codes440and442, is present in the keyboard controller14. From operation504, the routine500continues to operation507.

At operation507, in response to determining that the keyboard status is set, the PS/2 EFI driver reads the data-out register422for keyboard data. Next, from operation507, the routine500continues to operation510, where the PS/2 EFI driver418dispatches the data read from the data-out register422to the keyboard data buffer412via the data distributor417. From operation510, the routine500continues to operation512.

At operation512, the PS/2 EFI driver418determines whether the EFI keyboard driver404is available to receive data. If the EFI keyboard driver404is not available, the routine500returns to operation504described above. When the EFI keyboard driver404is available, the routine500continues from operation512to operation514.

At operation514the PS/2 EFI driver418calls the EFI keyboard driver404to deliver the data to the EFI keyboard driver404. Next, at operation515, the PS/2 EFI driver418clears the keyboard data buffer412. The routine500then returns to operation504described above. It should be appreciated that the PS/2 EFI driver418will still poll the keyboard controller14as required by the EFI specification. This polling also enables the PS/2 EFI driver to detect data entry without being prompted by a request for data, such as in the case of receiving a CTRL-ALT-DEL command or other registered hot-key.

If at operation504, the PS/2 EFI driver418determines that the keyboard status is not set, the routine500continues from operation504to operation517. At operation517, the PS/2 EFI driver418determines whether the mouse status is set. If the mouse status register424does not indicate that mouse data is present, the routine500continues to exit operation532where it ends. When at operation517, the mouse status register424indicates that mouse data is present in the keyboard controller14, the routine500continues from operation517to operation520. It should be appreciated that the PS/2 EFI driver418processes mouse data in response to an EFI keyboard driver request, if mouse data is available at this time. Similarly, keyboard data is processed by the PS/2 EFI driver418in response to an EFI mouse driver request, if keyboard data is available during such request. This doubles the responsiveness of the PS/2 EFI driver418.

At operation520, in response to determining that the mouse status is set, the PS/2 EFI driver418reads the data-out register422for mouse data. Next, from operation520, the routine500continues to operation522, where the PS/2 EFI driver418dispatches the data read from the data-out-register422to the mouse data buffer419via the data distributor417. From operation522, the routine500continues to operation524.

At operation524, the PS/2 EFI driver418determines whether the EFI mouse driver407is available to receive data. If the EFI mouse driver407is not available, the routine500returns to operation504described above. When the EFI mouse driver407is available, the routine500continues from operation524to operation527.

At operation527the PS/2 EFI driver418calls the EFI mouse driver407to deliver the data to the EFI mouse driver407. Next, at operation530, the PS/2 EFI driver418clears the mouse data buffer419. The routine500then returns to operation504described above.

It should be appreciated that embodiments of the present invention provide methods, systems, apparatuses, and computer-readable media for servicing PS/2 devices within an EFI environment. Although the invention has been described in language specific to computer structural features, methodological acts and by computer readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific structures, acts or media described. Therefore, the specific structural features, acts and mediums are disclosed as exemplary embodiments implementing the claimed invention.