mirror of
https://github.com/projectacrn/acrn-hypervisor.git
synced 2025-09-11 13:49:39 +00:00
doc: clean up utf8 characters
Stray non-ASCII characters can creep in when pasting from Word or Google Docs, particularly for "smart" single and double quotes and non-breaking spaces. Change these to their ASCII equivalents. Also fixed some very long lines of text to wrap at 80-ish characters. Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
David B. Kinder
committed by
David Kinder
David Kinder
parent
138c3aeadd
commit
f5f16f4e64
@@ -2916,12 +2916,12 @@ Compliant example::
|
||||
Non-compliant example::
|
||||
|
||||
/*
|
||||
* The example here uses the char ␣ to stand for the space at the end of the line
|
||||
* The example here uses the char ~ to stand for the space at the end of the line
|
||||
* in order to highlight the non-compliant part.
|
||||
*/
|
||||
uint32_t a;␣␣␣␣
|
||||
uint32_t b;␣␣␣␣
|
||||
uint32_t c;␣␣␣␣
|
||||
uint32_t a;~~~~
|
||||
uint32_t b;~~~~
|
||||
uint32_t c;~~~~
|
||||
|
||||
|
||||
C-CS-06: A single space shall exist between non-function-like keywords and opening brackets
|
||||
|
||||
@@ -32,12 +32,12 @@ Usage:
|
||||
|
||||
***-s <slot>,ahci,<type:><filepath>***
|
||||
|
||||
Type: ‘hd’ and ‘cd’ are available.
|
||||
Type: 'hd' and 'cd' are available.
|
||||
|
||||
Filepath: the path for the backend file, could be a partition or a
|
||||
Filepath: the path for the backend file, could be a partition or a
|
||||
regular file.
|
||||
|
||||
E.g．
|
||||
For example,
|
||||
|
||||
SOS: -s 20,ahci,\ `hd:/dev/mmcblk0p1 <http://hd/dev/mmcblk0p1>`__
|
||||
|
||||
|
||||
@@ -3,7 +3,12 @@
|
||||
Virtio-gpio
|
||||
###########
|
||||
|
||||
virtio-gpio provides a virtual GPIO controller, which will map part of native GPIOs to UOS, UOS can perform GPIO operations through it, including setting values, including set/get value, set/get direction and set configuration (only Open Source and Open Drain types are currently supported). GPIOs quite often be used as IRQs, typically for wakeup events, virtio-gpio supports level and edge interrupt trigger modes.
|
||||
virtio-gpio provides a virtual GPIO controller, which will map part of
|
||||
native GPIOs to UOS, UOS can perform GPIO operations through it,
|
||||
including setting values, including set/get value, set/get direction and
|
||||
set configuration (only Open Source and Open Drain types are currently
|
||||
supported). GPIOs quite often be used as IRQs, typically for wakeup
|
||||
events, virtio-gpio supports level and edge interrupt trigger modes.
|
||||
|
||||
The virtio-gpio architecture is shown below
|
||||
|
||||
@@ -13,11 +18,20 @@ The virtio-gpio architecture is shown below
|
||||
|
||||
Virtio-gpio Architecture
|
||||
|
||||
Virtio-gpio is implemented as a virtio legacy device in the ACRN device model (DM), and is registered as a PCI virtio device to the guest OS. No changes are required in the frontend Linux virtio-gpio except that the guest (UOS) kernel should be built with ``CONFIG_VIRTIO_GPIO=y``.
|
||||
Virtio-gpio is implemented as a virtio legacy device in the ACRN device
|
||||
model (DM), and is registered as a PCI virtio device to the guest OS. No
|
||||
changes are required in the frontend Linux virtio-gpio except that the
|
||||
guest (UOS) kernel should be built with ``CONFIG_VIRTIO_GPIO=y``.
|
||||
|
||||
There are three virtqueues used between FE and BE, one for gpio operations, one for irq request and one for irq event notification.
|
||||
There are three virtqueues used between FE and BE, one for gpio
|
||||
operations, one for irq request and one for irq event notification.
|
||||
|
||||
Virtio-gpio FE driver will register a gpiochip and irqchip when it is probed, the base and number of gpio are generated by the BE. Each gpiochip or irqchip operation(e.g. get_direction of gpiochip or irq_set_type of irqchip) will trigger a virtqueue_kick on its own virtqueue. If some gpio has been set to interrupt mode, the interrupt events will be handled within the irq virtqueue callback.
|
||||
Virtio-gpio FE driver will register a gpiochip and irqchip when it is
|
||||
probed, the base and number of gpio are generated by the BE. Each
|
||||
gpiochip or irqchip operation(e.g. get_direction of gpiochip or
|
||||
irq_set_type of irqchip) will trigger a virtqueue_kick on its own
|
||||
virtqueue. If some gpio has been set to interrupt mode, the interrupt
|
||||
events will be handled within the irq virtqueue callback.
|
||||
|
||||
GPIO mapping
|
||||
************
|
||||
@@ -28,9 +42,10 @@ GPIO mapping
|
||||
|
||||
GPIO mapping
|
||||
|
||||
- Each UOS has only one GPIO chip instance, its number of GPIO is based on acrn-dm command line and GPIO base always start from 0.
|
||||
- Each UOS has only one GPIO chip instance, its number of GPIO is based
|
||||
on acrn-dm command line and GPIO base always start from 0.
|
||||
|
||||
- Each GPIO is exclusive, uos can’t map the same native gpio.
|
||||
- Each GPIO is exclusive, uos can't map the same native gpio.
|
||||
|
||||
- Each acrn-dm maximum number of GPIO is 64.
|
||||
|
||||
@@ -39,22 +54,36 @@ Usage
|
||||
|
||||
add the following parameters into command line::
|
||||
|
||||
-s <slot>,virtio-gpio,<@controller_name{offset|name[=mapping_name]:offset|name[=mapping_name]:…}@controller_name{…}…]>
|
||||
-s <slot>,virtio-gpio,<@controller_name{offset|name[=mapping_name]:offset|name[=mapping_name]:...}@controller_name{...}...]>
|
||||
|
||||
- **controller_name**: Input “ls /sys/bus/gpio/devices” to check native gpio controller information.Usually, the devices represent the controller_name, you can use it as controller_name directly. You can also input “cat /sys/bus/gpio/device/XXX/dev” to get device id that can be used to match /dev/XXX, then use XXX as the controller_name. On MRB and NUC platforms, the controller_name are gpiochip0, gpiochip1, gpiochip2.gpiochip3.
|
||||
- **controller_name**: Input ``ls /sys/bus/gpio/devices`` to check
|
||||
native gpio controller information.Usually, the devices represent the
|
||||
controller_name, you can use it as controller_name directly. You can
|
||||
also input "cat /sys/bus/gpio/device/XXX/dev" to get device id that can
|
||||
be used to match /dev/XXX, then use XXX as the controller_name. On MRB
|
||||
and NUC platforms, the controller_name are gpiochip0, gpiochip1,
|
||||
gpiochip2.gpiochip3.
|
||||
|
||||
- **offset|name**: you can use gpio offset or its name to locate one native gpio within the gpio controller.
|
||||
- **offset|name**: you can use gpio offset or its name to locate one
|
||||
native gpio within the gpio controller.
|
||||
|
||||
- **mapping_name**: This is optional, if you want to use a customized name for a FE gpio, you can set a new name for a FE virtual gpio.
|
||||
- **mapping_name**: This is optional, if you want to use a customized
|
||||
name for a FE gpio, you can set a new name for a FE virtual gpio.
|
||||
|
||||
Example
|
||||
*******
|
||||
|
||||
- Map three native gpio to UOS, they are native gpiochip0 with offset of 1 and 6, and with the name “reset”. In UOS, the three gpio has no name, and base from 0.::
|
||||
- Map three native gpio to UOS, they are native gpiochip0 with offset
|
||||
of 1 and 6, and with the name ``reset``. In UOS, the three gpio has
|
||||
no name, and base from 0 ::
|
||||
|
||||
-s 10,virtio-gpio,@gpiochip0{1:6:reset}
|
||||
|
||||
- Map four native gpio to UOS, native gpiochip0’s gpio with offset 1 and offset 6 map to FE virtual gpio with offset 0 and offset 1 without names, native gpiochip0’s gpio with name “reset” maps to FE virtual gpio with offset 2 and its name is “shutdown”, native gpiochip1’s gpio with offset 0 maps to FE virtual gpio with offset 3 and its name is “reset”.::
|
||||
|
||||
-s 10,virtio-gpio,@gpiochip0{1:6:reset=shutdown}@gpiochip1{0=reset}
|
||||
- Map four native gpio to UOS, native gpiochip0's gpio with offset 1
|
||||
and offset 6 map to FE virtual gpio with offset 0 and offset 1
|
||||
without names, native gpiochip0's gpio with name ``reset`` maps to FE
|
||||
virtual gpio with offset 2 and its name is ``shutdown``, native
|
||||
gpiochip1's gpio with offset 0 maps to FE virtual gpio with offset 3 and
|
||||
its name is ``reset`` ::
|
||||
|
||||
-s 10,virtio-gpio,@gpiochip0{1:6:reset=shutdown}@gpiochip1{0=reset}
|
||||
|
||||
@@ -3,7 +3,11 @@
|
||||
Virtio-i2c
|
||||
##########
|
||||
|
||||
Virtio-i2c provides a virtual I2C adapter that supports mapping multiple slave devices under multiple native I2C adapters to one virtio I2C adapter. The address for the slave device is not changed. Virtio-i2c also provides an interface to add an acpi node for slave devices so that the slave device driver in the guest OS does not need to change.
|
||||
Virtio-i2c provides a virtual I2C adapter that supports mapping multiple
|
||||
slave devices under multiple native I2C adapters to one virtio I2C
|
||||
adapter. The address for the slave device is not changed. Virtio-i2c
|
||||
also provides an interface to add an acpi node for slave devices so that
|
||||
the slave device driver in the guest OS does not need to change.
|
||||
|
||||
:numref:`virtio-i2c-1` below shows the virtio-i2c architecture.
|
||||
|
||||
@@ -13,17 +17,27 @@ Virtio-i2c provides a virtual I2C adapter that supports mapping multiple slave d
|
||||
|
||||
Virtio-i2c Architecture
|
||||
|
||||
Virtio-i2c is implemented as a virtio legacy device in the ACRN device model (DM) and is registered as a PCI virtio device to the guest OS. The Device ID of virtio-i2c is 0x860A and the Sub Device ID is 0xFFF6.
|
||||
Virtio-i2c is implemented as a virtio legacy device in the ACRN device
|
||||
model (DM) and is registered as a PCI virtio device to the guest OS. The
|
||||
Device ID of virtio-i2c is 0x860A and the Sub Device ID is 0xFFF6.
|
||||
|
||||
Virtio-i2c uses one **virtqueue** to transfer the I2C msg that is received from the I2C core layer. Each I2C msg is translated into three parts:
|
||||
Virtio-i2c uses one **virtqueue** to transfer the I2C msg that is
|
||||
received from the I2C core layer. Each I2C msg is translated into three
|
||||
parts:
|
||||
|
||||
- Header: includes addr, flags, and len.
|
||||
- Data buffer: includes the pointer to msg data.
|
||||
- Status: includes the process results at the backend.
|
||||
|
||||
In the backend kick handler, data is obtained from the virtqueue, which reformats the data to a standard I2C message and then sends it to a message queue that is maintained in the backend. A worker thread is created during the initiate phase; it receives the I2C message from the queue and then calls the I2C APIs to send to the native I2C adapter.
|
||||
In the backend kick handler, data is obtained from the virtqueue, which
|
||||
reformats the data to a standard I2C message and then sends it to a
|
||||
message queue that is maintained in the backend. A worker thread is
|
||||
created during the initiate phase; it receives the I2C message from the
|
||||
queue and then calls the I2C APIs to send to the native I2C adapter.
|
||||
|
||||
When the request is done, the backend driver updates the results and notifies the frontend. The msg process flow is shown in :numref:`virtio-process-flow` below.
|
||||
When the request is done, the backend driver updates the results and
|
||||
notifies the frontend. The msg process flow is shown in
|
||||
:numref:`virtio-process-flow` below.
|
||||
|
||||
.. figure:: images/virtio-i2c-1a.png
|
||||
:align: center
|
||||
@@ -35,23 +49,29 @@ When the request is done, the backend driver updates the results and notifies th
|
||||
-s <slot>,virtio-i2c,<bus>[:<slave_addr>[@<node>]][:<slave_addr>[@<node>]][,<bus>[:<slave_addr>[@<node>]][:<slave_addr>][@<node>]]
|
||||
|
||||
bus:
|
||||
The bus number for the native I2C adapter; “2” means “/dev/i2c-2”.
|
||||
The bus number for the native I2C adapter; ``2`` means ``/dev/i2c-2``.
|
||||
|
||||
slave_addr:
|
||||
he address for the native slave devices such as “1C”, “2F”...
|
||||
he address for the native slave devices such as ``1C``, ``2F``...
|
||||
|
||||
@:
|
||||
The prefix for the acpi node.
|
||||
|
||||
node:
|
||||
The acpi node name supported in the current code. You can find the supported name in the acpi_node_table[] from the source code. Currently, only ‘cam1’, ‘cam2’, and ‘hdac’ are supported for MRB. These nodes are platform-specific.
|
||||
The acpi node name supported in the current code. You can find the
|
||||
supported name in the ``acpi_node_table[]`` from the source code. Currently,
|
||||
only ``cam1``, ``cam2``, and ``hdac`` are supported for MRB. These nodes are
|
||||
platform-specific.
|
||||
|
||||
|
||||
**Example:**
|
||||
|
||||
-s 19,virtio-i2c,0:70@cam1:2F,4:1C
|
||||
|
||||
This adds slave devices 0x70 and 0x2F under the native adapter /dev/i2c-0, and 0x1C under /dev/i2c-6 to the virtio-i2c adapter. Since 0x70 includes '@cam1', acpi info is also added to it. Since 0x2F and 0x1C have '@<node>', no acpi info is added to them.
|
||||
This adds slave devices 0x70 and 0x2F under the native adapter
|
||||
/dev/i2c-0, and 0x1C under /dev/i2c-6 to the virtio-i2c adapter. Since
|
||||
0x70 includes '@cam1', acpi info is also added to it. Since 0x2F and
|
||||
0x1C have '@<node>', no acpi info is added to them.
|
||||
|
||||
|
||||
**Simple use case:**
|
||||
@@ -111,8 +131,5 @@ You can dump the i2c device if it is supported:
|
||||
e0: 00 ff 06 00 03 fa 00 ff ff ff ff ff ff ff ff ff ..?.??..........
|
||||
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
|
||||
|
||||
Note that the virtual I2C bus number has no relationship with the native I2C bus number; it is auto-generated by the guest OS.
|
||||
|
||||
|
||||
|
||||
|
||||
Note that the virtual I2C bus number has no relationship with the native
|
||||
I2C bus number; it is auto-generated by the guest OS.
|
||||
|
||||
Reference in New Issue
Block a user