Specifications

214 AMD Geode™ GeodeROM Functional Specification
System Management Mode Software
32087C
15.6 System Calls
One of the design goals of GeodeROM VSA2 technology is to hide the implementation details. System calls and macros
provide control mechanisms and access to sensitive system values and structures. Although VSMs could directly perform
certain tasks, they should call the System Manager to perform these functions. This allows hardware bug fixes as well as
Geode South Bridge details to be abstracted from the VSM. Because most chipset programming is performed at initializa-
tion, where performance is not critical, the slight loss in performance due to system overhead is more than made up by
readability, portability, and the handling of shared resources. The available system calls are discussed in detail in Section
15.10 “System Calls and Macros” on page 220.
Another “tool” that supports source code maintainability is the use of a set of pre-defined macros. These macros perform
their specified functionality using the best possible method, and again, abstracting the implementation details. The use of
these macros facilitates portability when system call interfaces are changed or when better system call implementations are
developed. The available macros are discussed in detail in Section 15.13 “Macros” on page 232.
15.7 Resource Management
The System Manager owns the top level SMI source registers. A VSM owns its second level source registers and all
resources related to the functional component that it controls. For example, the XpressAUDIO™ subsystem VSM does not
poll the top level SMI source register directly. It receives an EVENT_AUDIO message from the System Manager when there
is an audio-related event, and then reads the audio SMI source register(s) to determine the specific audio event.
When resources are accessed through index/data pairs, the code that uses the resources saves and restores the index/
data within a critical section. The PCI configuration address register is an exception because it is part of the VSM state.
When a VSM uses floating-point instructions, the VSM is responsible for saving and restoring the floating-point state. A
VSM must not write to global resources (e.g., CPU configuration registers).
15.7.1 Reentrancy
VSM code is not required to be reentrant. While it is possible for a VSM to be executing when another registered event
occurs, the System Manager's scheduler does not preempt the executing VSM to allow processing of a more recent SMI
event. Rather, the System Manager services the SMI, and records the event by entering the appropriate message into the
message queue of the VSM(s) registered to handle that event. It then returns control to the interrupted VSM.
15.7.2 Event Registration
A VSM can register as a handler of SMI event(s). This occurs at VSM initialization, but dynamic registration is also allowed.
Multiple VSMs can register for the same event. In the Geode GX1 processor, the order that VSMs are invoked is deter-
mined by the priority specified at the time of event registration. If a VSM chooses to handle the event, nothing extra is done.
If a VSM chooses not to handle the event, it must pass the event back to the System Manager via the SYS_PASS_EVENT
macro. The System Manager then sends a message to the next highest priority VSM that registered for the event, and so
on, until a VSM handles the event. In the Geode GX processor and later processors, each VSM gets the message no mat-
ter the priority, so the SYS_PASS_EVENT macro is not needed.
The architecture supports the assignment of a 16-bit priority to each registered event. These priorities are used to control
the order that an event is serviced. Bits [16:8] specify the order an SMI is processed relative to other VSMs. Bits [7:0] spec-
ify the order an SMI event message is inserted relative to other messages within the VSM's message queue. Higher num-
bers indicate a more important priority. For example, assume VSM X registers an event with priority 0x10000, and VSM Y
registers an event with priority 0x20000. If VSM X's event is being processed and VSM Y's event occurs, then VSM Y pre-
empts VSM X. VSM X is not given control until the next message in VSM Y's queue is of lower priority than the priority of
the message being handled by VSM X.
A value of 00h in bits [7:0] means the event message will be inserted at the end of a VSM’s queue. If an event message is
already in the queue with the same priority as a new event, the original event message is inserted first. The event queue is
sorted with the first key being priority and the second key being time of event.
Note: Some combinations of events may not be supported by the underlying hardware, but may be simulated by the Sys-
tem Manager. For example, a VSM may register as a handler of a GPIO falling and rising edge events. The hard-
ware only supports generation of an SMI on one or the other GPIO edge. The System Manager detects such
situations and dynamically reprograms the hardware in order to simulate the desired effect. A list of events is found
in Table 15-7 "Events" on page 228.