Patent Publication Number: US-6907521-B2

Title: Enabling video BIOS and display drivers to leverage system BIOS platform abstract

Description:
BACKGROUND 
   The present invention relates to Basic Input/Output System (BIOS). More particularly, the invention relates to enabling video BIOS and display drivers to leverage system BIOS platform abstract. 
   Many of the Graphics Memory Controller Hub (GMCH) configuration control registers, affecting graphics and graphics memory, are in the system dynamic random-access memory (DRAM) controller device. Moreover, the graphics interface is assigned as Device# 2  while the system memory controller is assigned as Device# 0 , which is owned by system Basic Input/Output System (BIOS) and system bus drivers. However, in Plug-n-Play (PnP) operating systems, such as Windows 2000, graphics drivers are not permitted to access registers or resources not in the drivers&#39; scope of ownership or declared PnP configuration space. Accordingly, in integrated and/or embedded graphics platforms, the platform-specific information is often accessed via the video BIOS communicating with the system BIOS. This communication utilizes private Int 15 h calls (i.e. interrupts). 
   However, the Windows display drivers cannot invoke the Int 15 h real-mode handler from within the operating system. Moreover, the display drivers cannot use the video BIOS when internal graphics is configured as a non-Video Graphics Array (non-VGA) display adapter. Thus, the legacy VGA video BIOS is not available when the adapter is secondary to either a Peripheral Component Interconnect (PCI) or Accelerated Graphics Port (AGP) VGA adapter. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  illustrates a configuration of a local memory/SMM interface register in accordance with and embodiment of the present invention. 
       FIG. 2  illustrates a process for enabling communication and handoff between graphics device and system BIOS in a video BIOS and display driver context (client). 
       FIG. 3  illustrates a process for enabling communication and handoff between graphics device and system BIOS in a system BIOS or SMM context (server). 
       FIG. 4  is a system level SMI flow block diagram according to an embodiment of the present invention. 
       FIG. 5  is a block diagram of a processor-based system which may execute codes residing on a computer readable medium. 
   

   DETAILED DESCRIPTION 
   In recognition of the above-stated difficulties with an existing integrated graphics chipset design, such as Graphics Memory Controller Hub (GMCH) design, the present invention describes embodiments for enhanced chipset design that enables communication and handoff between the graphics device and the system Basic Input/Output System (BIOS). Moreover, the enhanced design includes the graphics chipset system management interrupt (SMI) interfaces that enable communication with the system BIOS through a single persistent or consistent mechanism that is available and is operating system (OS) independent. In one embodiment, the graphics chipset (i.e. GMCH), which is sometimes referred to as North-Bridge, provides the capability to generate an SMI under software control by writing to the Peripheral Component Interconnect (PCI) configuration-space register  0 E 0 h through  0 E 1 h in Device# 2 . 
   Accordingly, the present embodiments include hardware SMI trigger, a software interface, and an interface means. The hardware SMI trigger is within the BIOS and drivers&#39; addressable space, which enables the hardware to be visible to both the video BIOS and display drivers. The software interface uses a hardware scratch register that may be written and read by video BIOS, display drivers and system BIOS. The system BIOS is signaled using SMI trigger. The interface means includes a means for passing commands and returning status. Consequently, for purposes of illustration and not for purposes of limitation, the exemplary embodiments of the invention are described in a manner consistent with such use, though clearly the invention is not so limited. 
   In order to properly configure a system, the video BIOS and display drivers need certain information about the platform and user configuration. As stated above, although the information may be available to the system BIOS, this information is often not available to the video BIOS and display drivers. Furthermore, the directive of the Intel driver and BIOS software architecture is to keep the platform specifics in the platform, and to avoid propagating the platform specifics into the video BIOS and/or display drivers. This directive is meant to avoid creating a combinatorial compatibility problem and to ensure correct versioning, given the wide versatility of integrated graphics chipset (i.e. GMCH) configurations. 
   Accordingly, the embodiments of the present invention define a mechanism in which the video BIOS and display drivers in the graphics chipset (i.e. GMCH) may work as clients of the System BIOS. The mechanism enables the system to notify the software of events. The mechanism also uses the firmware to perform platform-specific functions, which could not otherwise be performed directly by the video BIOS and/or display drivers without detailed knowledge of the platform-specifics. Hence, the present embodiments avoid replicating the platform-specific interfaces by providing for a single common method that the video BIOS and display drivers may use on both desktop and mobile systems. 
   The enhanced integrated graphics chipset design provides a bimodal interface for detecting, sizing, and initializing or re-initializing a local video memory from the video BIOS or display drivers using common code. This code resides in the system BIOS. Local video memory is a memory that is connected on a separate bus, which is “local” to the graphics controller, as opposed to being connected to the system-wide processor-memory bus. Thus, when present and enabled the local video memory may be initialized by the System BIOS. This allows the system BIOS to be responsible for ensuring the correct setup for the platform and component specific implementation of the local video memory. The system BIOS may also ensure the correct setup of the type of memory used for the local memory. However, the local video memory is associated with, owned, and controlled by, the graphics device. Therefore, from the operating system&#39;s perspective, the display driver is expected to manage local video memory. For example, when performing power-management, graphics power management calls are routed through the display driver, and not the system BIOS. 
   In one mode, an Int 15 h call is used. However, the Int 15 h call is typically used only by the video BIOS to call system BIOS during power-up self-test (POST). Hence, this method is typically unavailable to the display drivers that run within the protected mode of the operating system, and therefore, are prohibited from calling software interrupts. In another mode, System Management Interrupt (SMI) is used to trigger entry into System Management Mode (SMM) context. This SMM context is a special operating system independent context supplied by the system BIOS. Thus, both the video BIOS and display drivers may use this context. 
   In one embodiment, if the video BIOS is called during POST, a new Int 15 h function (i.e. Function  5 F 65 ) may be called. This function is a local memory function starting with the function to return local memory characteristics (i.e. size and speed) and local memory state under various power management conditions. Thus, the video BIOS may not utilize the SMI interface during POST because SMM is often not initialized until just prior to boot. But, the video BIOS may detect that there is no local memory when the new Int 15 h function is not supported, an error is returned, or zero local memory is returned by the system BIOS in the field for the local memory. However, if a non-zero, non-error value is returned, this value represents the amount of local memory that may be initialized to a returned speed. This information is essential in mode setting. Thus, this embodiment provides faster speed but is more expensive. 
   In an alternative embodiment, if the video BIOS is not called in POST but a display driver initializes the chipset, the driver cannot reliably count on Int 15 h interface. Some operating systems do not support the Int 15 h interface at all, while others may trap the Int 15 h call in a configuration that interferes with this interface. Therefore, the alternative embodiment provides a register in PCI configuration space for Device# 2 . The register may be used to trigger an SMI handled by the system BIOS. This register also has read/write configuration bits. SMI interrupts cannot convey CPU register or structure information without this hardware support. Thus, drivers preset the read/write bits that are in turn readable by the system BIOS in SMI. The bits stored in PCI configuration space for Device# 2  are equally accessible in all states. Furthermore, unlike the Int 15 h interface, the SMI/PCI interface allows software to specify the basic parameters used to initialize the local memory (i.e. in terms of size, latency, and speed) or leave these parameters to the system BIOS. Hence, this embodiment provides cheaper solution but slower speed. 
     FIG. 1  illustrates a configuration of a local memory/SMM interface register  100  in accordance with an embodiment of the present invention. A software driver configures the interface register  100  into two registers within the integrated graphics chipset. These registers that are defined in Device# 2  provide the capability to generate an SMI from the graphics chipset under control of the software driver. The registers may also serve as scratch pads for passing parameters to and from the SMI handler. Thus, the client may set up the scratch pad registers in the interface register  100  and may request for a particular service to be performed by the system BIOS. The SMI handler in the system BIOS may then check the fields in the interface register  100  to determine the type of service being requested. In one embodiment, the register appears in PCI configuration space and/or memory-mapped I/O (MMIO) space, which is accessible by drivers and/or BIOS. 
   In the illustrated embodiment, a bit  102  in the first register triggers an SMI and causes the processor to leave the current context and enter SMM. Other bits  104 ,  106 ,  108  in the first register carry function  104 , sub-functions  108 , and flags  106 . The second register provides exchange space  110  for the supplied or returned data. 
   There are a number of functions supported including local memory initialize, local memory report, and local memory power-down. Both modes of the interface support a call to the system BIOS to power down local memory. Moreover, there must be a method to re-initialize memory on resume after a previous power down. For example, in exiting the S 1  power state of an Advance Configuration and Power Interface (ACPI) machine, the system BIOS is not involved since this state is managed under operating system control, which only calls the driver software. Therefore, only the display drivers have the ability and responsibility to perform re-initialization when exiting D 1  or D 3 . This capability provides a means by which the drivers may call system BIOS to perform the platform-specific re-initialization. 
   A process for enabling communication and handoff between graphics devices and the system BIOS in accordance with an embodiment of the present invention is illustrated as flowcharts in  FIGS. 2 and 3 . The flowchart of  FIG. 2  illustrates video BIOS and display driver context (client), while the flowchart of  FIG. 3  illustrates system BIOS or SMM context (server). 
   In the illustrated embodiment of  FIG. 2 , the local memory is initialized at  200 . Command and sub-function are built in  202 . An SMI bit in the local memory/SMM interface register is then set, at  204 . In a particular embodiment, the client software may examine the interface register before dispatch, and check the SMI bit (i.e. bit  0 ) to determine if a client is already using this bit. After setting up the parameters in the interface, the client triggers the SMI by using the register. Hence, in this embodiment, the SMI bit of the register is set to trigger the entry into the system BIOS SMI handler in the server. 
   Once the system BIOS SMI handler is called (at  206 ), the client continuously polls for SMI bit clear (at  208 ) or timeout of the server (at  210 ). Thus, operations  206  and  208 / 210  may be performed concurrently. Once the SMI bit clear is detected at  208 , the result flags are read (at  212 ) and returned (at  214 ). If the server times out at  210 , the error is unsupported (at  216 ) and a failure flag is returned (at  218 ). 
   In the illustrated embodiment of  FIG. 3 , the System BIOS SMI handler is called at  300 . The SMI handler then determines the source of the SMI, at  302 . In one embodiment, the SMI handler checks the Error Status (ERRSTS) register to determine the caller/function. Once the caller/function has been determined, the SMI handler dispatches (at  304 ) to various processors to process the function. The SMI handler then processes the function (at  306 ) as indicated in the interface register after determining that the source is a software-triggered SMI. In one embodiment, the processing of the function utilizes the data supplied in the Parameter register. 
   After completing the function processing, the SMI handler clears the SMI bit (at  308 ) before exiting. This indicates that the SMI handler it has been serviced. As stated above, the client software continues to poll for a change from a “1” to “0” in the SMI bit in order to determine that the call has been handled and the data registers contain valid values. 
   A system level SMI flow block diagram  400  is illustrated in  FIG. 4  according to an embodiment of the present invention. From the system perspective, setting SMI trigger bit in the above-described interface register in the graphics chipset (i.e. GMCH)  408  may be detected by a software running within the context of the operating system. For example, the video BIOS or device drivers may detect the trigger bit. The detection of the bit may be made in real mode or virtual DOS environment to trigger generation of a message (DO_SMI) to I/O Controller Hub (ICH)  410 . The ICH  410  is sometimes referred to as South-Bridge. Additionally, the graphics chipset  408  may flag certain register bits indicating that the SMI was initiated by the graphics chipset  408 . The South-Bridge  410  processes this message to generate an SMI to the processor  402 . This interrupt causes the processor  402  to save the current context and enter SMM. The system BIOS includes the software executed within the SMM context  104 . When complete, the SMM code executes an “RSM” (resume) processor instruction causing the CPU to restore the processor context  406 . The code then leaves SMM and continues execution in the previous context. This process may be substantially transparent to the operating system. Therefore, the SMM code may clear the interface register bit described above prior to exit. This enables the driver context  406 , which triggered the entry into SMI, to perceive that a transition has occurred and that the function is completed. 
     FIG. 5  is a block diagram of a processor-based system  500  which may execute codes residing on the computer readable medium  502 . The codes are related to communication and handoff method between the graphics device and the system BIOS described in  FIGS. 2 through 4 . In one embodiment, the computer readable medium  502  may be a fixed medium such as read-only memory (ROM) or a hard disk. In the case of ROM, the code may reside in BIOS. In the case of hard disk, the code may reside in operating system. In another embodiment, the medium  502  may be a removable medium such a floppy disk or a compact disk (CD). A read/write drive  506  in the computer  504  reads the code on the computer readable medium  502 . The code is then executed in the processor  508 . The processor  508  may access the computer main memory  510  to store or retrieve data. 
   Advantages of the present embodiments include platform abstraction regardless of characteristics, implementation, and operating systems. Examples of characteristics may include size and speed, while examples of implementation may include local memory configuration through memory module connector or soldered-down. Other advantages include isolation of drivers and video BIOS from platform specifics. This allows generic drivers and BIOS releases that are independent of platform local memory configuration. 
   The present embodiments also provide reduction in the development cost, support burden, and validation-effort on software. For example, the enhanced integrated graphics chipset design described above leaves much of the complexity of managing memory such as the Rambus dynamic random access memory (RDRAM) timings and levelization to the vendor or original-equipment-manufacturer (OEM). This also allows improved time-to-market for the majority of the market that may not need or use local memory, and avoid unpleasant alternatives that would otherwise require spinning the driver/BIOS to make special version for any special memory types/issues. 
   Although, previous products have leveraged system BIOS to support local memory management, those products have overlooked many problems of re-initialization. Moreover, these previous products have relied on the memory being continuously in a useable state. However, as described above, the memory may not always be in a useable state but require continuous adaptation of the drivers to perform tasks (especially in the S 1 /S 3  resume scenario) and accommodate platform specifics. 
   There has been disclosed herein embodiments for for enhanced chipset design that enables communication and handoff between the graphics device and the system BIOS. The enhanced design includes the graphics chipset system management interrupt (SMI) interfaces that enable communication with the system BIOS through a single persistent or consistent mechanism that is available and is operating system (OS) independent. 
   While specific embodiments of the invention have been illustrated and described, such descriptions have been for purposes of illustration only and not by way of limitation. Accordingly, throughout this detailed description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the system and method may be practiced without some of these specific details. In other instances, well-known structures and functions were not described in elaborate detail in order to avoid obscuring the subject matter of the present invention. Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.