JP2013246457A - Host controller and host device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce power consumption of a USB 2.0 host device.SOLUTION: A USB 2.0 host controller 150 includes: a size storage unit 152 that stores size information indicating a predetermined certain data size; and a control execution unit 154. The control execution unit 154 generates, as a transfer request to be transmitted to a peripheral device 170, a first-type transfer request that is a transfer request including the size information that is stored in the size storage unit 152. When receiving transfer data that is output by the peripheral device 170 in response to the first-type transfer request, the control execution unit 154 reads transfer information from a system memory 132 and stores the transfer data in a storage destination indicated by the transfer information.

Description

  The present invention relates to a data transfer technique between a host device and a peripheral device in a communication system, for example, a communication system compliant with USB 2.0.

  There is known a communication system in which a host device (hereinafter also simply referred to as “host”) issues a transfer request, and the peripheral device transfers transfer data to the host in response to the transfer request from the host device. Various techniques have been proposed for controlling data transfer in such a communication system.

  For example, Patent Document 1 includes a transfer control device in a terminal that requests data transfer in a plurality of transfer information (information including a transfer data length and a transfer destination address) stored in a system memory in an IEEE 1394 communication system. Disclosed is a technique for adding a data transfer length of a plurality of pieces of transfer information to generate one transfer request and issuing it to another terminal when areas indicated by respective transfer destination addresses form continuous areas. ing. From the viewpoint of data transfer, a terminal that requests data transfer and a terminal that requests data transfer correspond to a host and a peripheral device, respectively.

  According to this technique, data transfer corresponding to a plurality of pieces of transfer information can be executed by one transfer request, so that the efficiency of data transfer can be improved.

  In a USB 2.0 communication system (USB: Universal Serial Bus), a host controller corresponds to the above-described transfer control device, and generates a transfer request based on transfer information stored in a system memory by a CPU (Central Processing Unit) to create a peripheral. Issued to the device (Non-Patent Document 1, Patent Document 2). In the USB 2.0 system, the transfer information includes a transfer size (corresponding to the transfer data length) and information indicating a storage destination of the transferred data (corresponding to the transfer destination address).

  When a USB 2.0 host controller receives a transfer start notification from a CPU (Central Processing Unit), it reads the transfer information stored in the system memory and sends a transfer request including the transfer size indicated by the transfer information to the peripheral device. Output to. Then, the transfer data transmitted from the peripheral device in response to the transfer request is stored in the storage location indicated by the transfer information.

  When a plurality of pieces of transfer information are stored in the system memory, the host controller reads transfer information and outputs a transfer request in the priority order defined by the USB 2.0 standard.

  The peripheral device that has received the transfer request makes a rejection response when there is no data to be transmitted or when the data to be transmitted is not ready. When receiving a rejection response, the host controller repeatedly reads the transfer information from the system memory and outputs the transfer request until it receives the transfer data from the peripheral device.

  Note that the USB standard has backward compatibility, and a USB 3.0 host controller is provided in a USB 3.0 host. The data transfer control for the USB 2.0 peripheral device is controlled by the USB 2.0 host controller.

  In the following, unless otherwise specified, “host device” and “host controller” mean a USB 2.0 host device and host controller, and “peripheral device” means a USB 2.0 peripheral device. Also, the USB 2.0 host device is not limited to a host device that supports only USB 2.0, but includes a function block that is included in a USB 3.0 host device and performs the functions of USB 2.0. The peripheral device of USB 2.0 is not limited to a peripheral device that supports only USB 2.0, but includes a functional block that bears a functional block of USB 2.0 included in the peripheral device of USB 3.0. Similarly, a USB 2.0 host controller is not limited to a host controller provided in a host that supports only USB 2.0, but also includes a USB 2.0 host controller provided in a USB 3.0 host. This is not repeated below.

JP 2002-222162 A JP 2011-186918 A

Universal Serial Bus Specification, Revision 2.0, April 27, 2000

  As described above, the host controller continues to read the transfer information and output the transfer request until the transfer data is received from the peripheral device.

  On the other hand, in the peripheral device, in particular, a USB mouse, a USB keyboard or the like does not always have data to be transmitted to the host. Therefore, the host controller frequently receives a rejection response from these peripheral devices.

  Since the host controller reads the transfer information every time a rejection response is received, in a situation where the rejection response is continuously received, the power consumption associated with repeated accesses to the system memory is useless.

  In order to solve the above problem, for example, if the host controller holds the transfer information and receives a rejection response from the peripheral device, the transfer request is reissued based on the held transfer information. The number of accesses to the system memory can be reduced. However, in this case, it is necessary to provide a memory for holding transfer information for each peripheral device in the host controller, which increases the circuit scale of the host controller.

  Other problems and novel features will become apparent from the description of the specification and the accompanying drawings.

  One embodiment is a USB 2.0 host controller. The host controller generates a first type of transfer request, which is a transfer request including size information indicating a predetermined data size, as a transfer request to be transmitted to the peripheral device. When the host controller receives the transfer data output from the peripheral device in response to the first type transfer request, the host controller reads the transfer information stored in the system memory by the CPU from the system memory, and transfers the transfer data. The transfer data is stored in the storage location indicated by the information.

  A representation in which the host controller of the above embodiment is replaced with a method or system, a host device provided with the host controller, or the like is also effective as an embodiment.

  According to the host controller of one embodiment, power consumption can be suppressed.

It is a figure which shows the USB system concerning 1st Embodiment. It is a flowchart which shows the flow of the process by the USB controller in 1st Embodiment shown in FIG. It is a flowchart which shows the flow of a process by the USB controller in the USB system concerning 2nd Embodiment. It is a flowchart which shows the flow of a process by the USB controller in the USB system concerning 3rd Embodiment. It is a flowchart which shows the flow of a process by the USB controller in the USB system concerning 4th Embodiment.

  For clarity of explanation, the following description and drawings are omitted and simplified as appropriate. Each element described in the drawings as a functional block for performing various processes can be configured by a CPU, a memory, and other circuits in terms of hardware, and a program loaded in the memory in terms of software. Etc. Therefore, it is understood by those skilled in the art that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof, and is not limited to any one. Note that, in each drawing, the same element is denoted by the same reference numeral, and redundant description is omitted as necessary.

  Further, the above-described program can be stored using various types of non-transitory computer readable media and supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic recording media (for example, flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (for example, magneto-optical disks), CD-ROM (Read Only Memory) CD-R, CD -R / W, semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory)). The program may also be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. The temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.

<First Embodiment>
FIG. 1 shows a USB system 100 according to the first embodiment. The USB system 100 includes a USB 2.0 host device 110 and a USB 2.0 peripheral device 170. Although FIG. 1 shows only one peripheral device 170, there may be a plurality of peripheral devices 170.

  The host device 110 is a computer, for example, and includes a CPU 120, a system memory 130, a system bus 140, a host controller 150, and a peripheral bus 160. A USB driver is installed in the host device 110, and the CPU implements USB-related processing by executing the driver.

The system memory 130 has a transfer information area 132 and a data area 134.
The CPU 120 generates transfer information and stores it in the transfer information area 132. This transfer information indicates the size (transfer size) of transfer data to be transferred to the peripheral device 170, for example, the number of packets, and the storage destination of transfer data from the peripheral device 170. The storage location is a pointer indicating the address in the data area 134.

  The host controller 150 includes a size storage unit 152, a control execution unit 154, and a data buffer 156.

  The size storage unit 152 stores size information indicating a predetermined data size. In the USB system 100 of the present embodiment, the size information stored in the size storage unit 152 indicates the size of one packet that is the minimum transfer unit of transfer data.

  When a conventional host controller requests data transfer to a peripheral device, it reads the transfer information from the transfer information area 132 of the system memory 130, generates a transfer request including the transfer size indicated by the transfer information, and sends it to the peripheral device. Send. When the peripheral device transmits the transfer data in response to the transfer request, the transfer data is stored in the storage destination indicated by the transfer information. When the peripheral device makes a rejection response to the transfer request, the host controller reads the transfer information, and generates and transmits the transfer request again.

  In the present embodiment, the control execution unit 154 in the host controller 150 is stored in the size storage unit 152 without reading transfer information from the transfer information area 132 when generating a transfer request to be transmitted to the peripheral device 170. Generate a transfer request that includes the size information. When the peripheral device 170 transmits transfer data in response to the transfer request, the transfer information is read from the transfer information area 132, and control is performed so that the transfer data is stored in the storage destination indicated by the transfer information. Further, even when the peripheral device 170 makes a rejection response to the transfer request, the transfer request including the size information stored in the size storage unit 152 is again read without reading the transfer information from the transfer information area 132. Generate.

  In the following description, a transfer request generated by the control execution unit 154 using the size information stored in the size storage unit 152 is referred to as a “first type transfer request”, and the control execution unit 154 receives transfer information from the transfer information area 132. A transfer request that is read and generated with a transfer size included in the transfer information is referred to as a “second type transfer request”. In the first embodiment, the control execution unit 154 of the host controller 150 generates only the first type transfer request. That is, in the present embodiment, the control execution unit 154 does not access the system memory 130 when generating the transfer request.

  The data buffer 156 temporarily stores the transfer data transmitted by the peripheral device 170 in response to the transfer request transmitted by the control execution unit 154, and the address of the data area 134 in the system memory 130 according to the control of the control execution unit 154. To store.

  When the peripheral device 170 receives the transfer request from the host device 110 (specifically, the control execution unit 154 in the host controller 150), if the transfer data is ready, the peripheral device 170 transfers the transfer data of the size indicated by the transfer request. Transfer to device 110. When there is no transfer data or when transfer data is not ready, the peripheral device 170 makes a rejection response.

  Note that the size of transfer data transferred from the peripheral device 170 to the host device 110 may be smaller than the size requested by the transfer request.

  The peripheral device 170 is the same as a normal USB 2.0 peripheral device, and further detailed description is omitted here.

  Communication between the CPU 120, the system memory 130, and the host controller 150 is performed via the system bus 140. Communication between the host controller 150 and the peripheral device 170 is performed via the peripheral bus 160.

  FIG. 2 is a flowchart showing the flow of processing by the control execution unit 154 in the host device 110 of the USB system 100 shown in FIG.

  As shown in the figure, when receiving a transfer start notification from the CPU 120 (S100), the control execution unit 154 generates a first type transfer request and transmits it to the peripheral device 170 (S102).

  Until the transfer data is received from the peripheral device 170, the control execution unit 154 repeats generation and transmission of the first type transfer request every time a rejection response is received from the peripheral device 170 (S104: Yes, S102). .

  When the transfer data is received from the peripheral device 170, the control execution unit 154 reads the transfer information from the transfer information area 132 in order to know the storage location of the transfer data, and outputs the transfer data to the storage location indicated by the transfer information. The data buffer 156 is executed (S104: No, S106, S108).

  Then, the control execution unit 154 transmits a transfer completion notification including information indicating the size of the transfer data stored in the data area 134 (here, the size information stored in the size storage unit 152 is the same) to the CPU 120. (S110).

  As described above, in the USB system 100 according to the present embodiment, the host device 110 does not access the system memory 130 when generating a transfer request to be transmitted to the peripheral device 170. Therefore, the peripheral device 170 particularly makes a rejection response. In a continuing situation, power consumption can be saved. Further, since the size storage unit 152 only needs to store size information indicating one predetermined data size regardless of the number of peripheral devices, an increase in the circuit scale of the host controller can be suppressed.

<Second Embodiment>
The second embodiment is also a USB system. The USB system of the second embodiment is the same as the USB system 100 except that the control execution unit is different from the control execution unit 154 in the host device 110 of the USB system 100 shown in FIG. Therefore, only the control execution unit will be described for the USB system of the second embodiment.

  FIG. 3 is a flowchart showing a flow of processing by the control execution unit in the second embodiment. In the flowchart of FIG. 3, the step given the step number in FIG. 2 is the same processing as the step indicated by the step number in FIG.

  In the second embodiment, when receiving a transfer start notification from the CPU 120 (S100), the control execution unit first confirms whether or not the peripheral device 170 that is the destination of the transfer request is an InterruptIN transfer type ( S120).

  When the peripheral device 170 is an InterruptIN transfer type (S120: Yes), the control execution unit performs the processes of Steps S102 to S110. These processes are the same as the processes in steps S102 to S110 in FIG.

  On the other hand, when the peripheral device 170 is not of the InterruptIN transfer type (S120: No), the control execution unit reads the transfer information from the transfer information area 132, and transfers the transfer request (second type) with the transfer size indicated by the transfer information. (Transfer request) is generated and transmitted to the peripheral device 170 (S122, S124).

  Until the transfer data is received from the peripheral device 170, the control execution unit reads the transfer information from the transfer information area 132 and generates the second type transfer request each time a rejection response is received from the peripheral device 170. The transmission is repeated (S126: Yes, S122, S124).

When the transfer data is received from the peripheral device 170, the control execution unit causes the data buffer 156 to output the transfer data to the storage location indicated by the transfer information read from the transfer information area 132 in step S122 (S126: No, S108).
Thereafter, the control execution unit outputs a transfer completion notification to the CPU 120 (S110).

  In the flowchart shown in FIG. 3, the processing from step S102 to step S110 is the same as the processing of the control execution unit 154 of the USB system 100 according to the first embodiment. The processing from step S122 to step S110 is the conventional processing. This is the same as the processing of the host controller.

  That is, in the second embodiment, the host controller generates the transfer request only in the case of an InterruptIN transfer type peripheral device that is likely to frequently generate rejection responses continuously. One type of transfer request is generated, and transfer information is read from the system memory 130 after the transfer is successful. As a result, the power consumption of the host controller is reduced as in the USB system 100 according to the first embodiment.

  In the case of other types of peripheral devices, the transfer information is read from the system memory 130 when generating the transfer request, and the second type transfer request is generated based on the transfer information, as in the conventional host controller. As a result, it is possible to prevent a decrease in transfer efficiency in the case of other types of peripheral devices that are unlikely to frequently generate rejection responses.

<Third Embodiment>
The third embodiment is also a USB system. The USB system of the third embodiment is the same as the USB system 100 except that the control execution unit is different from the control execution unit 154 in the host device 110 of the USB system 100 shown in FIG. Therefore, only the control execution unit will be described for the USB system of the third embodiment.

  FIG. 4 is a flowchart showing the flow of processing by the control execution unit in the third embodiment. In the flowchart of FIG. 4, the step given the step number in FIG. 2 is the same processing as the step indicated by the step number in FIG.

  In the third embodiment, when receiving a transfer start notification from the CPU 120 (S100), the control execution unit reads transfer information from the transfer information area 132 to generate a first transfer request (S130). . Then, a transfer request (second type transfer request) is generated with the transfer size indicated by the transfer information and transmitted to the peripheral device 170 (S132).

  When the peripheral device 170 transmits transfer data in response to the first transfer request (second type transfer request) (S134: No), the control execution unit reads from the transfer information area 132 in step S130. The data buffer 156 is made to output the transfer data to the storage location indicated by the transfer information, and a transfer completion notification is output to the CPU 120 (S108, S110).

  The “first transfer request” refers to a transfer request transmitted to the peripheral device 170 for the first time after system startup or a transfer transmitted to the peripheral device 170 for the first time after successful data transfer from the peripheral device 170. Means a request.

  The processing performed so far by the control execution unit is the same as the processing performed by the conventional host controller.

  In step S134, when the peripheral device 170 makes a rejection response to the first transfer request (second type transfer request) (S134: Yes), the control execution unit performs the processes of steps S102 to S110. Do. These processes are the same as the processes in steps S102 to S110 in FIG.

  That is, in the third embodiment, when the first transfer request is transmitted, the control execution unit reads transfer information from the system memory 130 when generating the transfer request, similar to the conventional host controller, A second type transfer request is generated based on the transfer information.

  On the other hand, after the peripheral device 170 makes a rejection response to the first transfer request, the control execution unit generates the first type transfer without accessing the system memory 130 when generating the transfer request. A request is generated, and the transfer information is read from the system memory 130 after the transfer is successful.

  A peripheral device that has made a rejection response to the first transfer request is highly likely to make a rejection response to a subsequent transfer request. Therefore, according to the host controller of the USB system according to the third embodiment, the first type transfer request is generated without accessing the system memory 130 only when the possibility of a rejection response is high. By transmitting to the peripheral device, power consumption can be reduced. In the case of the first transfer request, the transfer data of the transfer size requested by the CPU 120 can be transmitted to the peripheral device already prepared for transfer by generating and transmitting the second type transfer request. , Transfer efficiency can be increased.

<Fourth embodiment>
The fourth embodiment is also a USB system. The USB system according to the fourth embodiment is the same as the USB system according to the third embodiment except that the control execution unit is different from the control execution unit in the USB system according to the third embodiment. is there. Therefore, only the control execution unit will be described for the USB system of the fourth embodiment.

  FIG. 5 is a flowchart showing a flow of processing by the control execution unit in the fourth embodiment. In the flowchart of FIG. 5, the step given the step number in FIG. 4 is the same process as the step indicated by the step number in FIG.

  In the fourth embodiment, when receiving a transfer start notification from the CPU 120 (S100), the control execution unit reads transfer information from the transfer information area 132 to generate a first transfer request (S130). . Then, a transfer request (second type transfer request) is generated with the transfer size indicated by the transfer information and transmitted to the peripheral device 170 (S132).

  When the peripheral device 170 transmits transfer data in response to the first transfer request (second type transfer request) (S134: No), the control execution unit reads from the transfer information area 132 in step S130. The data buffer 156 is made to output the transfer data to the storage location indicated by the transfer information, and a transfer completion notification is output to the CPU 120 (S108, S110).

  The processing performed by the control execution unit so far is the same as the processing performed by the host controller in the USB system according to the third embodiment and the conventional host controller.

  In step S134, when the peripheral device 170 makes a rejection response to the first transfer request (second type transfer request) (S134: Yes), the control execution unit controls the transfer request. It is confirmed whether or not the destination peripheral device 170 is an InterruptIN transfer type (S140).

  When the peripheral device 170 is an InterruptIN transfer type (S140: Yes), the control execution unit performs the processes of Steps S102 to S110. These processes are the same as the processes in steps S102 to S110 in FIGS.

  On the other hand, when the peripheral device 170 is not of the InterruptIN transfer type (S140: No), the control execution unit reads the transfer information from the transfer information area 132, and transfers the transfer request (second type) with the transfer size indicated by the transfer information. (Transfer request) is generated and transmitted to the peripheral device 170 (S142, S144).

  Until the transfer data is received from the peripheral device 170, the control execution unit reads the transfer information from the transfer information area 132 and generates the second type transfer request each time a rejection response is received from the peripheral device 170. The transmission is repeated (S146: Yes, S142, S144).

When the transfer data is received from the peripheral device 170, the control execution unit causes the data buffer 156 to output the transfer data to the storage location indicated by the transfer information read from the transfer information area 132 in step S142 (S146: No, S108).
Thereafter, the control execution unit outputs a transfer completion notification to the CPU 120 (S110).

  The USB system according to the fourth embodiment is a combination of the first to third embodiments, and the effects of the USB systems according to the first to third embodiments can be obtained.

  In the second embodiment and the fourth embodiment, the host controller determines whether the target peripheral device is an interrupt IN transfer type or not, depending on whether or not the target peripheral device is an interrupt IN transfer type. Which of these is to be generated is determined. This determination is not necessarily made based on whether or not it is an InterruptIN transfer type, and may be made based on whether or not it is a predetermined transfer type, for example.

  For example, the specific transfer type may be a specific type (for example, a mouse) belonging to the InterruptIN transfer type instead of all types belonging to the InterruptIN transfer type.

  Of course, the specific transfer type may be a BulkIN transfer type or a specific type (for example, a hard disk) belonging to the BulkIN transfer type depending on the use of the system.

  Further, the number of the specific transfer types is not limited to one and may be plural. Further, in this case, among a plurality of specific transfer types, a type belonging to the InterruptIN transfer type and a type belonging to the BulkIN transfer type may be mixed.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiments. However, the present invention is not limited to the embodiments already described, and various modifications can be made without departing from the scope of the invention. It goes without saying that it is possible.

100 USB system 110 Host device 120 CPU
130 System Memory 132 Transfer Information Area 134 Data Area 140 System Bus 150 Host Controller 152 Size Storage Unit 154 Control Execution Unit 156 Data Buffer 160 Peripheral Bus 170 Peripheral Device

Claims (12)

A host controller for USB 2.0 (USB: Universal Serial Bus),
A size storage unit for storing size information indicating a predetermined data size determined in advance;
Transfer information indicating a transfer size, which is the size of transfer data, and a storage destination, and controls data transfer from a peripheral device to a host device based on the transfer information stored in a system memory by a CPU (Central Processing Unit) A control execution unit,
The control execution unit
As a transfer request to be transmitted to the peripheral device, generate a first type transfer request that is a transfer request including the size information stored in the size storage unit,
When the transfer data output by the peripheral device in response to the first type transfer request is received, the transfer information is read from the system memory, and the transfer data is stored in the storage destination indicated by the transfer information.
Host controller. The control execution unit
Only when the peripheral device is of a predetermined type, generates the transfer request of the first type,
When the peripheral device is a type other than the specific type, the transfer information is read from the system memory, and a second type transfer request that is a transfer request including the transfer size indicated by the transfer information is generated.
When the transfer data output by the peripheral device in response to the second type transfer request is received, the transfer data is stored in the storage location indicated by the transfer information.
The host controller according to claim 1. The specific type is an InterruptIN transfer type.
The host controller according to claim 2. The control execution unit
When transmitting the first transfer request to the peripheral device, the transfer information is read from the system memory, and a second type transfer request that is a transfer request including the transfer size indicated by the transfer information is generated.
When the transfer data output by the peripheral device in response to the second type transfer request is received, the transfer data is stored in the storage destination indicated by the transfer information;
When the peripheral device makes a rejection response to the second type transfer request, the first type transfer request is generated.
The host controller according to claim 1. The control execution unit
Only when the peripheral device that has made a rejection response to the second type of transfer request is a predetermined specific type, generates the first type of transfer request,
When the peripheral device that made a rejection response to the second type transfer request is a type other than the specific type, the second type transfer request is generated.
The host controller according to claim 4. The specific type is an InterruptIN transfer type.
The host controller according to claim 5. A host device of USB 2.0 (USB: Universal Serial Bus),
CPU (Central Processing Unit),
System memory,
With a host controller,
The host controller
A size storage unit for storing size information indicating a predetermined data size determined in advance;
A control execution unit that controls transfer of data from a peripheral device to a host device based on the transfer information stored in the system memory by the CPU, the transfer information indicating a transfer size that is the size of transfer data and a storage destination And
The control execution unit
As a transfer request to be transmitted to the peripheral device, generate a first type transfer request that is a transfer request including the size information stored in the size storage unit,
When the transfer data output by the peripheral device in response to the first type transfer request is received, the transfer information is read from the system memory, and the transfer data is stored in the storage destination indicated by the transfer information.
Host device. The control execution unit
Only when the peripheral device is of a predetermined type, generates the transfer request of the first type,
When the peripheral device is a type other than the specific type, the transfer information is read from the system memory, and a second type transfer request that is a transfer request including the transfer size indicated by the transfer information is generated.
When the transfer data output by the peripheral device in response to the second type transfer request is received, the transfer data is stored in the storage location indicated by the transfer information.
The host device according to claim 7. The specific type is an InterruptIN transfer type.
The host device according to claim 8. The control execution unit
When transmitting the first transfer request to the peripheral device, the transfer information is read from the system memory, and a second type transfer request that is a transfer request including the transfer size indicated by the transfer information is generated.
When the transfer data output by the peripheral device in response to the second type transfer request is received, the transfer data is stored in the storage destination indicated by the transfer information;
When the peripheral device makes a rejection response to the second type transfer request, the first type transfer request is generated.
The host device according to claim 7. The control execution unit
Only when the peripheral device that has made a rejection response to the second type of transfer request is a predetermined specific type, generates the first type of transfer request,
When the peripheral device that made a rejection response to the second type transfer request is a type other than the specific type, the second type transfer request is generated.
The host device according to claim 10. The specific type is an InterruptIN transfer type.
The host device according to claim 11.

Images