HK1181515B - Method for providing asynchronous event notification in systems - Google Patents

Description

Method for providing asynchronous event notification in a system

Technical Field

Background

Computers and computer systems are ubiquitous. With the wide range of computer hardware and computer software available, it becomes important to establish a number of standards for connecting and communicating between various computer devices.

To provide standards that allow compatibility and interoperability, the computer industry has formed member corporate organizations. For example, currently, standards are available for hardware and software connections between computers and peripheral devices, internal computer equipment such as hard disk drives and input/output devices and external products such as portable devices are attached to computers through standard interface cables and use standard communication protocols. Some examples of widespread adoption include Universal Serial Bus (USB), Advanced Technology Attachment (ATA), and serial ATA (SATA or eSATA) interfaces.

In each of these systems, the host initiates operations and sends commands to the device, and the device responds to the host commands according to a predefined protocol. There is no provision in these interfaces for the device to initiate commands or operations to the host. The device can only send information to the host that is requested by commands sent by the host or that is otherwise directly caused by host behavior.

Such protocols use asymmetric interfaces where the host and device have defined roles for commands and responses (e.g., host command and device response), unlike end-to-end communication protocols where units can operate as both initiators and targets. SCSI is a standard interface that provides this end-to-end support.

Some system interfaces may allow hardware notifications between units over host-to-device cables, however the new interface favors serial communication, it does not provide dedicated signals on the cable, and it does not provide such new interfaces in systems such as serial ATA or USB.

In a system with a host and a device and where the device is not specified to notify the host of an outstanding event at any time, the device has only a disadvantageous choice. For example, upon a failure condition or an event in which a device cannot recover, some devices may take a self-reset or abort an outstanding command to force the host to be aware and hopefully recover. This can result in catastrophic data loss or render the system inoperable. System timeouts or resets are the last means to attempt recovery. Additionally, notification of the host by the device may be desirable before the situation (e.g., environmental conditions or recoverable errors) becomes critical.

FIG. 1 illustrates a system 10 that employs a host computer 11, a device 13, and an optional interconnection cable 12 that allows communication between the host computer 11 and the device 13. For example, the communications of FIG. 1 may include, for example, a universal serial bus, AT attachment, serial attached SCSI or Serial ATA, or a communications interface. Alternatively, some devices 13 plug directly into the host 11 without the need for the cable 12, and operate in the same manner. Host computer 11 may be any system that can send commands to device 13. For example, the host computer may be a desktop computer, a laptop computer, or a dedicated controller.

The interface between the host computer 11 and the device 13 may be a universal serial bus interface, commonly referred to as a USB interface. The USB interface may also be referred to as USB-1, USB-2, or USB-3, and future versions are contemplated. The device may support command queuing and contain a command queue 14. For example, the device 13 may be an input/output (I/O) device such as a keyboard, printer, or mouse; or a storage device such as a disk drive, solid state drive, CD or DVD player; or a communication device such as a modem; or a personal entertainment device such as a music or video player.

Fig. 2 illustrates a system 20 that uses a host computer 11 and a device 13, the host computer 11 connected to the host side of a hub 15 using a cable 12, and the device 13 connected to the device side of the hub 15 using an optional cable 12. Hubs provide expansion ports so that multiple devices can be connected to a single host port. In the system shown in FIG. 2, the host computer is the communication host; while the devices are physically connected to the hub 15. The hub provides a physical interface to the device and appears to the device as a host. The hub shown in fig. 2 is well known in the art and is widely used. The following references to hosts or host computers of the present invention may include a directly connected host as shown in FIG. 1 or a host connected through a hub as shown in FIG. 2.

FIG. 3 illustrates a flow diagram for a device receiving a queued command. Beginning at step 300, a device operates in a system having a host. In block 305, the device checks for command reception from the host. If no new command is received (block 310), the device proceeds to block 315 to determine if there are any outstanding commands in the command queue. If the queue is empty, the device returns to block 305 to continue checking for new commands.

If a new command is received in block 310, the device checks the validity of the command and its associated queue command tag in block 325. If the command is invalid or the tag is invalid, the device responds to the host by sending an error status in block 320. If the command and tag are valid, the device accepts the command to be executed (block 330). The device will add the command to the device command queue and any other outstanding commands will wait for completion. In block 340, the device will determine the commands that should be executed next and reorder the queue as needed for best performance, but reordering is not required. The device then executes the command in the command queue in block 345.

The flow chart shown in fig. 3 is an example of a queued command process. For example, alternative embodiments may perform command reception, queue ordering, and/or command execution as synchronous operations to provide improved performance.

Disclosure of Invention

The present invention discloses a method of providing asynchronous notifications from a device to a host in a system where no hardware is required to provide asynchronous operations.

In one embodiment of the present invention, a method of providing asynchronous event notification from a device in a system supporting command queuing is provided. The method includes receiving a queued command and a queue tag from a host; accepting queued commands from the host without scheduling the commands for completion; the monitoring device operates to monitor for asynchronous events; detecting an asynchronous event; and providing notification of the asynchronous event by scheduling and sending a response to the host including the tag.

In another embodiment of the present invention, a method is provided for providing asynchronous event notifications from a device in a system that supports command queuing and the sending of commands from a host to the device. The device receives the command and the associated queue tag and determines that the tag is not a valid tag. The device then determines whether the command is an asynchronous event notification request type command and, if so, accepts the command as a valid command. Upon accepting the command, the device begins monitoring for asynchronous events. If an asynchronous event is detected, the device provides notification of the event by sending a response and associated tag to the host.

In another embodiment of the present invention, a method is provided for providing asynchronous event notification from a device in a system that supports command queuing and sends commands from a host to the device to enable unsolicited queued command responses. The device receives the command and assigns or associates a queue tag to the command and enables the unsolicited queue command response. The device begins monitoring for asynchronous events. If an asynchronous event is detected, the device provides notification of the event by sending a response and associated tag to the host.

Drawings

FIG. 1 illustrates a block diagram of a host and device system.

Fig. 2 illustrates a block diagram of a host and a system of devices with a hub.

FIG. 3 is a flow diagram illustrating a device receiving a queued command.

FIG. 4 is a flow diagram illustrating an embodiment of the present invention using asynchronous event commands.

FIG. 5 is a flow diagram illustrating an embodiment of the present invention using either a valid queue command tag or an invalid queue command tag.

FIG. 6 is a flow chart illustrating an embodiment of the present invention using host enabled operation.

FIG. 7 illustrates a block diagram of an apparatus according to an embodiment of the invention.

FIG. 8 illustrates a split queue store according to an embodiment of the present invention.

FIG. 9 illustrates a partitioned queue store according to an embodiment of the present invention.

Detailed Description

FIG. 4 illustrates an embodiment of the present invention with asynchronous event commands.

Beginning in block 400, a device operates in a system having a host. In block 405, the device checks for command reception from the host. If no new command is received (block 410), the device proceeds to block 415 to determine if there are any outstanding commands in the command queue. If the queue is empty, the device returns to block 405 to continue checking for new commands. If the queue is not empty, the device continues executing outstanding commands in block 445.

If a new command is received in block 410, the device checks the validity of the command and its associated queue command tag in block 412. If the command is invalid or the tag is invalid, the device responds to the host by sending an error status in block 420. If the command and tag are valid, the device accepts the command (block 425). In block 430 the device checks to determine if the command is an asynchronous event notification command (AEN command). If the command is not an AEN command, the device will add the command to the device command queue (block 435), while any other outstanding commands will wait for completion. In block 440, the device will decide which command to execute next, and the device may reorder the queue as needed for best performance. Thereafter, in block 445, the device executes the command in the command queue.

Returning to block 430, if the command is an AEN command, the device will start a new process (path 432), which includes blocks 455 through 465. The process begins at block 455 by initiating monitoring for asynchronous events by the device. If no event is detected in block 460, the device continues monitoring. If an event is detected in block 460, the device will generate an end state and communicate an asynchronous event state to the host. Returning again to block 430, if the command is an AEN command, the process continues processing queued commands by returning to block 405 via path 450 in addition to the new process that started at block 455.

The embodiment shown in FIG. 4 is one embodiment of a queued command process. For example, alternative embodiments may perform command reception, queue ordering, and/or command execution as synchronous operations to provide improved performance.

FIG. 5 illustrates an embodiment of the inventive process of handling valid or invalid queue command tags. Beginning in block 500, a device operates in a system having a host. In block 505, the device checks for command reception from the host. If a new command is received (block 510), the process proceeds to block 515 to check the validity of the command and its associated queue command tag. If the command and tag are valid, the process proceeds to block 550 and checks the new command received in block 510 to determine if the command is an asynchronous event notification command (AEN command). If the command is not an AEN command, the device enqueues the command to the device command queue (block 555) while any other outstanding commands wait for completion. In block 560, the device will determine the commands that should be executed next and reorder the queue as needed for best performance. The device then executes the command in the command queue at block 565 and returns to 505 to resume operation.

Returning to block 550, if the command is an AEN command, the device begins a new process (path 551), including blocks 530 through 540. The process begins at block 530 with the device receiving an AEN command to be processed. In block 530, the device will initiate monitoring for asynchronous events. If no event is detected in block 535, the device continues monitoring. If an event is detected in block 535, the device will generate an end state and communicate an asynchronous event state to the host in block 540, and then return to block 505 again to continue operation.

Returning again to block 550, if the command is an AEN command, the process continues processing queued commands by returning to block 505 via path 552, in addition to the new process started at block 530 via path 551.

Returning to block 515, if the command and tag are invalid, the process proceeds to block 520. If the command is an AEN type command, the device will initiate monitoring for asynchronous events in block 530. If no event is detected in block 535, the device continues monitoring. If an event is detected in block 535, the device will generate an end state and pass the asynchronous event state to the host in block 540 and then return to block 505 again to continue the queue command operation.

Returning again to block 520, the device continues processing queue commands by returning to block 505 via path 522, in addition to turning to the new process starting at block 530. In block 520, if the command is not an AEN command, the device sends an error status to the host and returns to block 505 to continue the queue command operation.

In the embodiment illustrated in FIG. 5, if the command is an AEN command, the invalid tag is processed. For example, an invalid tag may be a duplicate tag assignment, an out-of-range value, a reserved tag, or any tag that is not normally accepted and would result in an error status being returned to the host. The method of FIG. 5 solves the problem in that if a command with an invalid tag is received, the device may abort all outstanding commands and may cause catastrophic failure to the system. In the embodiment shown in FIG. 5, if the command is an AEN command, the invalid tag will be accepted.

In another embodiment of the invention, the device may be enabled by command or default operation to begin monitoring and reporting asynchronous events. If the host learns of the feature through device queries, the host may use the agreed-upon command tags to enable the device to initiate asynchronous event notifications. The tag may be a valid or invalid tag value. The host may provide the preferred tag while enabling this feature. The device may also provide a default label.

In another embodiment of the invention, any queued command may include an option bit to enable asynchronous event notification. By utilizing embodiments of the present invention, the host does not have to send any commands to the drive, thereby simplifying operation and expense. The enabled features in the device may be persistent or non-persistent after being reset or powered down. This reduces the configuration time after a start or reset operation.

In embodiments of the present invention, it may be an option to continue enabling asynchronous event notifications after a reset of the device occurs.

In embodiments of the present invention, it may be an option to continue enabling asynchronous event notifications after a device is powered down.

FIG. 6 illustrates an embodiment of the present invention having host enabled operation.

Beginning at block 610, a power on or device reset is performed on the device. After the reset is complete, the device will check its configuration information to determine if the asynchronous event notification feature is enabled in block 615. If the feature is not enabled, the process terminates at block 620. If the feature is enabled, the device will assign a tag for reporting the AEN command status. The assigned tag may be a tag previously provided by the host or a device assigned tag.

The device will initiate monitoring for asynchronous events in block 630. If no event is detected in block 635, the device continues monitoring. If an event is detected in block 635, the device will generate an end state and communicate an asynchronous event state to the host in block 640, and then optionally return to block 630 to continue monitoring.

In the embodiments of fig. 4, 5, and 6, the AEN command is not scheduled to complete the command and may persist in an indefinite outstanding state without affecting ongoing queued command operations or queue order. After an asynchronous event occurs, the AEN command will be scheduled to complete the command. The device may choose to complete immediately or defer notifications according to event severity.

Fig. 7 illustrates a block diagram of an apparatus 700 according to an embodiment of the invention. The device 700 includes a processor 710 and a command queue 14. The command queue may be a portion of memory allocated by processor 710, or dedicated hardware such as registers or data stores accessible by processor 710. The queue contains information about each outstanding tag queued command. The tag may be a number, which is illustrated as individual items 1, 2, 3, etc. in the queue.

Asynchronous monitoring unit 720 may be software running on processor 710 or a different hardware unit.

In one embodiment, asynchronous monitoring unit 720 will monitor asynchronous events through hardware functions or through polling.

In one embodiment, the asynchronous monitor unit 720 may provide information to the processor 710 through an interrupt handler or a polling routine executed by the processor.

Asynchronous queue store 730 may be any typical memory/data store distinct from the command queue, may be a completely separate unit, compartment, distinct memory location, or the like.

FIG. 8 illustrates queue store 14 and asynchronous queue store 730 according to an embodiment of the present invention. In this embodiment, command queue 14 is distinct from asynchronous storage 730. Queue store 14 may operate independently of asynchronous store 730 and be independently scheduled and ordered for command execution and completion by processor 710. In embodiments of the present invention, operations in asynchronous monitor unit 720 and asynchronous storage 730 will not affect operations in command queue 14.

FIG. 9 illustrates a partitioned queue store 740 according to an embodiment of the invention. In one embodiment, partitioned queue store 740 is a general purpose memory or data store allocated by processor 740. Partitioned storage 740 includes two partitions, a common queue partition 14 and an asynchronous storage partition 730. According to embodiments of the present invention, two partitions are handled separately, although they may be in a common memory or data location.

In an embodiment of the invention, the monitored asynchronous events comprise exceeding at least one threshold value related to one or more of the following parameters:

(ii) temperature;

impacting;

vibrating;

power;

humidity;

a height;

air pressure;

an error rate;

abrasion; and

a delayed completion threshold.

In another embodiment of the invention, the asynchronous event comprises an encryption, license, or usage right condition.

While the above is described in terms of particular embodiments, other embodiments will be apparent to those of ordinary skill in the art in light of the disclosure herein. For example, in an alternative embodiment, operations may be performed concurrently, rather than in order, to improve performance. In another embodiment, asynchronous event monitoring and automatic reporting may be performed in a hardware implementation without processor involvement. Alternative ways of implementing the invention in combination with hardware and/or software running on a processor or as a hardware implementation configurable to run in multiple modes will be obvious to one of ordinary skill in the art. Thus, the system and method of the present invention can be implemented as software that provides the following programming: such as a set of instructions and/or metadata embodied within a computer-readable medium. The described embodiments are presented by way of example only and are not intended to limit the scope of the present disclosure. Indeed, the novel methods and systems described in this specification may be embodied in other various forms without departing from the spirit of the invention. The invention is therefore not limited to any preferred embodiment, but is defined by reference to the appended claims.

Claims (16)

1. A method for asynchronous event notification with a device in a system supporting command queuing, comprising the steps of:

receiving a command and a tag from a host;

accepting the command without scheduling the command to be completed;

the monitoring device operates to monitor for asynchronous events including encryption conditions, license conditions

Or a usage right condition;

detecting an asynchronous event; and

providing notification of the asynchronous event by scheduling the command to be completed and sending a response to the host including the tag.

2. The method of claim 1, wherein the command comprises an asynchronous event notification request.

3. The method of claim 2, wherein the asynchronous event notification request comprises a command code or command option bit.

4. The method of claim 1, wherein the tag comprises one of an invalid tag, an out-of-range tag, and a duplicate tag.

5. The method of claim 1, wherein the asynchronous event comprises exceeding at least one threshold related to at least one of the following parameters:

(ii) temperature;

impacting;

vibrating;

power;

humidity;

a height;

air pressure;

an error rate;

abrasion; and

a delayed completion threshold.

6. The method of claim 1, wherein receiving and providing comprises utilizing at least one of a universal serial bus, serial attached SCSI, advanced technology attachment, and serial advanced technology attachment communication.

7. A method for asynchronous event notification with a device in a system that supports command queuing, comprising:

receiving a command and a tag from a host;

determining that the command comprises an asynchronous event notification request;

accepting the command without scheduling the command to be completed;

the monitoring device is operative to monitor at least one asynchronous event, the asynchronous event comprising an encryption condition, a license condition, or a usage right condition;

detecting said at least one asynchronous event, and

providing notification of the at least one asynchronous event by scheduling the command to be completed and sending a response to the host including the tag.

8. The method of claim 7, wherein the asynchronous event notification request comprises one of a command code and a command option bit.

9. The method of claim 7, wherein determining that the command comprises an asynchronous event notification request comprises determining that the command from the host comprises an invalid tag.

10. The method of claim 9, wherein the invalid tag comprises an over-range tag or a duplicate tag.

11. The method of claim 7, wherein the asynchronous event comprises exceeding at least one threshold related to at least one of the following parameters:

(ii) temperature;

impacting;

vibrating;

power;

humidity;

a height;

air pressure;

an error rate;

abrasion; and

a delayed completion threshold.

12. The method of claim 7, wherein accepting and providing comprises using a communication protocol comprising at least one of universal serial bus, advanced technology attachment, serial attached SCSI, and serial advanced technology attachment communication.

13. In a system supporting command queuing, a method for asynchronous notifications from a device, comprising:

a command is received from the host to enable an unsolicited queued command response,

tags are assigned for unsolicited queue command responses,

enabling an unsolicited queued command response in response to the command from the host,

the monitoring device operates to monitor for asynchronous events;

detecting an asynchronous event; and

providing notification of the asynchronous event by sending a response to the host including the assigned tag,

wherein the unsolicited queue command response is continuously enabled during a reset operation or a power down.

14. The method of claim 13, wherein the tag is received using the command.

15. The method of claim 13, wherein the label is assigned with the device.

16. The method of claim 13, wherein the tag comprises at least one of an invalid tag, an out-of-range tag, and a duplicate tag.