hw/i3c: remote_i3c: Add model

Adds a model to communicate to remote I3C devices over chardev. This
allows QEMU to communicate to I3C targets that exist outside of QEMU.

The remote I3C protocol is a

hw/i3c: remote_i3c: Add model

Adds a model to communicate to remote I3C devices over chardev. This
allows QEMU to communicate to I3C targets that exist outside of QEMU.

The remote I3C protocol is as follows:
On an I3C private and CCC TX (controller -> target)
- 1-byte opcode
- 4-byte number of bytes in the packet as a LE uint32
- n-byte payload

On an I3C private and CCC RX (target -> controller)
Controller to target:
- 1-byte opcode
- 4-byte number of bytes to read as a LE uint32
Remote target response:
- 4-byte number of bytes in the packet as a LE uint32
- n-byte payload

IBI (target -> controller, initiated by target)
- 1-byte opcode
- 1-byte IBI address
- 1-byte RnW boolean
- 4-byte length of IBI payload from target as a LE uint32 (can be 0)
- n-byte IBI payload

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>

show more ...

hw/i3c: Add Mock target

Adds a simple i3c device to be used for testing in lieu of a real
device.

The mock target supports the following features:
- A buffer that users can read and write to.
- CCC

hw/i3c: Add Mock target

Adds a simple i3c device to be used for testing in lieu of a real
device.

The mock target supports the following features:
- A buffer that users can read and write to.
- CCC support for commonly used CCCs when probing devices on an I3C bus.
- IBI sending upon receiving a user-defined byte.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Titus Rwantare <titusr@google.com>
Reviewed-by: Patrick Venture <venture@google.com>

show more ...

hw/i3c/aspeed_i3c: Add controller resets

Adds behavior to the device reset register.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by:

hw/i3c/aspeed_i3c: Add controller resets

Adds behavior to the device reset register.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>

show more ...

hw/i3c/aspeed_i3c: Add IBI handling

Adds handling for different IBI events that the controller can receive.
This includes:
- Handling a hot-join from a target
- Handling a secondary controller on th

hw/i3c/aspeed_i3c: Add IBI handling

Adds handling for different IBI events that the controller can receive.
This includes:
- Handling a hot-join from a target
- Handling a secondary controller on the bus requesting to be the
primary bus controller
- Handling an interrupt request from a target.

When receiving an IBI, the controller sets an interrupt to notify
software about what happened.
When the IBI is finished being serviced, the controller pushes the
result of the IBI and any data received from the target into the IBI
queue.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>

show more ...

hw/i3c/aspeed_i3c: Add data TX and RX

This adds data and CCC transmission, reception, and the associated
queues required for data transmission and reception to happen.

The I3C controller transmits

hw/i3c/aspeed_i3c: Add data TX and RX

This adds data and CCC transmission, reception, and the associated
queues required for data transmission and reception to happen.

The I3C controller transmits data by the user writing into a command
queue. When the queue has a command and an argument in it, the
controller starts executing the command.

The controller can execute 1 of 3 ways:
1. A larger data transfer that involves using the TX and RX queues. This
is the most common way the controller does transactions.

2. A small data transfer that involves sending a couple bytes passed
into the command queue argument.

3. An address assignment command. This is how the controller does
ENTDAA. When ENTDAA succeeds in assigning an address to a target, it
updates the controller's char table with the target's PID, BCR, and
DCR.

The controller determines what addresses to send by looking at the index
in the device address table specified by the argument in the command
queue. ENTDAA also uses these addresses to assign to targets on the bus.

When the controller is done executing a command, it puts a response in
the response queue indicating how command execution went.

In order for the user to send and receive data to/from the controller,
the user reads/writes to a bidirectional TX/RX port.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Stephen Longfield <slongfield@google.com>
Reviewed-by: Patrick Venture <venture@google.com>

show more ...

hw/i3c: Add bus support

Adds an I3C bus and a target class.
The bus supports:
- I3C data transmission and reception
- CCCs (including ENTDAA)
- IBIs
- legacy I2C transactions

General usage of the b

hw/i3c: Add bus support

Adds an I3C bus and a target class.
The bus supports:
- I3C data transmission and reception
- CCCs (including ENTDAA)
- IBIs
- legacy I2C transactions

General usage of the bus is similar to I2C. Users are expected to
initialize a bus via i3c_init_bus, and use the bus returned from the
init function to do transactions on the bus.

In order to handle IBIs, the controller provides callbacks to handle
receiving an IBI from a target, receiving (optional) additional IBI
bytes from a target, and handling when a target is done with its IBI.

Similarly, target creation is done via i3c_target_create_simple and
users use the provided I3CTarget to handle transactions.
The target has functions provided that it can use to invoke an IBI and
send additional bytes.

Along with the expected, send, recv, and event callbacks that is
expected of an I3C target, which are similar to I2C, there is a separate
callback for CCC handling.
This is to help encapsulate CCC handling and keep it separate from
target-specific read/write functionality.

To avoid repition for required CCCs among I3C targets, there is some
class-level CCC handling added. The CCC is then passed to the target in
case it needs to handle it in some way.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Titus Rwantare <titusr@google.com>

show more ...

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and create I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and create I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Titus Rwantare <titusr@google.com>
[ clg: - replaced softmmu_ss with system_ss in meson.build files
- local variable renames in aspeed_i3c_realize() ]

show more ...

hw/i3c: remote_i3c: Add model

Adds a model to communicate to remote I3C devices over chardev. This
allows QEMU to communicate to I3C targets that exist outside of QEMU.

The remote I3C protocol is a

hw/i3c: remote_i3c: Add model

Adds a model to communicate to remote I3C devices over chardev. This
allows QEMU to communicate to I3C targets that exist outside of QEMU.

The remote I3C protocol is as follows:
On an I3C private and CCC TX (controller -> target)
- 1-byte opcode
- 4-byte number of bytes in the packet as a LE uint32
- n-byte payload

On an I3C private and CCC RX (target -> controller)
Controller to target:
- 1-byte opcode
- 4-byte number of bytes to read as a LE uint32
Remote target response:
- 4-byte number of bytes in the packet as a LE uint32
- n-byte payload

IBI (target -> controller, initiated by target)
- 1-byte opcode
- 1-byte IBI address
- 1-byte RnW boolean
- 4-byte length of IBI payload from target as a LE uint32 (can be 0)
- n-byte IBI payload

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>

show more ...

hw/i3c: Add Mock target

Adds a simple i3c device to be used for testing in lieu of a real
device.

The mock target supports the following features:
- A buffer that users can read and write to.
- CCC

hw/i3c: Add Mock target

Adds a simple i3c device to be used for testing in lieu of a real
device.

The mock target supports the following features:
- A buffer that users can read and write to.
- CCC support for commonly used CCCs when probing devices on an I3C bus.
- IBI sending upon receiving a user-defined byte.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Titus Rwantare <titusr@google.com>
Reviewed-by: Patrick Venture <venture@google.com>

show more ...

hw/i3c/aspeed_i3c: Add controller resets

Adds behavior to the device reset register.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by:

hw/i3c/aspeed_i3c: Add controller resets

Adds behavior to the device reset register.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>

show more ...

hw/i3c/aspeed_i3c: Add IBI handling

Adds handling for different IBI events that the controller can receive.
This includes:
- Handling a hot-join from a target
- Handling a secondary controller on th

hw/i3c/aspeed_i3c: Add IBI handling

Adds handling for different IBI events that the controller can receive.
This includes:
- Handling a hot-join from a target
- Handling a secondary controller on the bus requesting to be the
primary bus controller
- Handling an interrupt request from a target.

When receiving an IBI, the controller sets an interrupt to notify
software about what happened.
When the IBI is finished being serviced, the controller pushes the
result of the IBI and any data received from the target into the IBI
queue.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>

show more ...

hw/i3c/aspeed_i3c: Add data TX and RX

This adds data and CCC transmission, reception, and the associated
queues required for data transmission and reception to happen.

The I3C controller transmits

hw/i3c/aspeed_i3c: Add data TX and RX

This adds data and CCC transmission, reception, and the associated
queues required for data transmission and reception to happen.

The I3C controller transmits data by the user writing into a command
queue. When the queue has a command and an argument in it, the
controller starts executing the command.

The controller can execute 1 of 3 ways:
1. A larger data transfer that involves using the TX and RX queues. This
is the most common way the controller does transactions.

2. A small data transfer that involves sending a couple bytes passed
into the command queue argument.

3. An address assignment command. This is how the controller does
ENTDAA. When ENTDAA succeeds in assigning an address to a target, it
updates the controller's char table with the target's PID, BCR, and
DCR.

The controller determines what addresses to send by looking at the index
in the device address table specified by the argument in the command
queue. ENTDAA also uses these addresses to assign to targets on the bus.

When the controller is done executing a command, it puts a response in
the response queue indicating how command execution went.

In order for the user to send and receive data to/from the controller,
the user reads/writes to a bidirectional TX/RX port.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Stephen Longfield <slongfield@google.com>
Reviewed-by: Patrick Venture <venture@google.com>

show more ...

hw/i3c: Add bus support

Adds an I3C bus and a target class.
The bus supports:
- I3C data transmission and reception
- CCCs (including ENTDAA)
- IBIs
- legacy I2C transactions

General usage of the b

hw/i3c: Add bus support

Adds an I3C bus and a target class.
The bus supports:
- I3C data transmission and reception
- CCCs (including ENTDAA)
- IBIs
- legacy I2C transactions

General usage of the bus is similar to I2C. Users are expected to
initialize a bus via i3c_init_bus, and use the bus returned from the
init function to do transactions on the bus.

In order to handle IBIs, the controller provides callbacks to handle
receiving an IBI from a target, receiving (optional) additional IBI
bytes from a target, and handling when a target is done with its IBI.

Similarly, target creation is done via i3c_target_create_simple and
users use the provided I3CTarget to handle transactions.
The target has functions provided that it can use to invoke an IBI and
send additional bytes.

Along with the expected, send, recv, and event callbacks that is
expected of an I3C target, which are similar to I2C, there is a separate
callback for CCC handling.
This is to help encapsulate CCC handling and keep it separate from
target-specific read/write functionality.

To avoid repition for required CCCs among I3C targets, there is some
class-level CCC handling added. The CCC is then passed to the target in
case it needs to handle it in some way.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Titus Rwantare <titusr@google.com>

show more ...

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and create I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and create I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Titus Rwantare <titusr@google.com>
[ clg: - replaced softmmu_ss with system_ss in meson.build files
- local variable renames in aspeed_i3c_realize() ]

show more ...

hw/i3c: remote_i3c: Add model

Adds a model to communicate to remote I3C devices over chardev. This
allows QEMU to communicate to I3C targets that exist outside of QEMU.

The remote I3C protocol is a

hw/i3c: remote_i3c: Add model

Adds a model to communicate to remote I3C devices over chardev. This
allows QEMU to communicate to I3C targets that exist outside of QEMU.

The remote I3C protocol is as follows:
On an I3C private and CCC TX (controller -> target)
- 1-byte opcode
- 4-byte number of bytes in the packet as a LE uint32
- n-byte payload

On an I3C private and CCC RX (target -> controller)
Controller to target:
- 1-byte opcode
- 4-byte number of bytes to read as a LE uint32
Remote target response:
- 4-byte number of bytes in the packet as a LE uint32
- n-byte payload

IBI (target -> controller, initiated by target)
- 1-byte opcode
- 1-byte IBI address
- 1-byte RnW boolean
- 4-byte length of IBI payload from target as a LE uint32 (can be 0)
- n-byte IBI payload

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>

show more ...

hw/i3c: Add Mock target

Adds a simple i3c device to be used for testing in lieu of a real
device.

The mock target supports the following features:
- A buffer that users can read and write to.
- CCC

hw/i3c: Add Mock target

Adds a simple i3c device to be used for testing in lieu of a real
device.

The mock target supports the following features:
- A buffer that users can read and write to.
- CCC support for commonly used CCCs when probing devices on an I3C bus.
- IBI sending upon receiving a user-defined byte.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Titus Rwantare <titusr@google.com>
Reviewed-by: Patrick Venture <venture@google.com>

show more ...

hw/i3c/aspeed_i3c: Add controller resets

Adds behavior to the device reset register.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by:

hw/i3c/aspeed_i3c: Add controller resets

Adds behavior to the device reset register.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>

show more ...

hw/i3c/aspeed_i3c: Add IBI handling

Adds handling for different IBI events that the controller can receive.
This includes:
- Handling a hot-join from a target
- Handling a secondary controller on th

hw/i3c/aspeed_i3c: Add IBI handling

Adds handling for different IBI events that the controller can receive.
This includes:
- Handling a hot-join from a target
- Handling a secondary controller on the bus requesting to be the
primary bus controller
- Handling an interrupt request from a target.

When receiving an IBI, the controller sets an interrupt to notify
software about what happened.
When the IBI is finished being serviced, the controller pushes the
result of the IBI and any data received from the target into the IBI
queue.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>

show more ...

hw/i3c/aspeed_i3c: Add data TX and RX

This adds data and CCC transmission, reception, and the associated
queues required for data transmission and reception to happen.

The I3C controller transmits

hw/i3c/aspeed_i3c: Add data TX and RX

This adds data and CCC transmission, reception, and the associated
queues required for data transmission and reception to happen.

The I3C controller transmits data by the user writing into a command
queue. When the queue has a command and an argument in it, the
controller starts executing the command.

The controller can execute 1 of 3 ways:
1. A larger data transfer that involves using the TX and RX queues. This
is the most common way the controller does transactions.

2. A small data transfer that involves sending a couple bytes passed
into the command queue argument.

3. An address assignment command. This is how the controller does
ENTDAA. When ENTDAA succeeds in assigning an address to a target, it
updates the controller's char table with the target's PID, BCR, and
DCR.

The controller determines what addresses to send by looking at the index
in the device address table specified by the argument in the command
queue. ENTDAA also uses these addresses to assign to targets on the bus.

When the controller is done executing a command, it puts a response in
the response queue indicating how command execution went.

In order for the user to send and receive data to/from the controller,
the user reads/writes to a bidirectional TX/RX port.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Stephen Longfield <slongfield@google.com>
Reviewed-by: Patrick Venture <venture@google.com>

show more ...

hw/i3c: Add bus support

Adds an I3C bus and a target class.
The bus supports:
- I3C data transmission and reception
- CCCs (including ENTDAA)
- IBIs
- legacy I2C transactions

General usage of the b

hw/i3c: Add bus support

Adds an I3C bus and a target class.
The bus supports:
- I3C data transmission and reception
- CCCs (including ENTDAA)
- IBIs
- legacy I2C transactions

General usage of the bus is similar to I2C. Users are expected to
initialize a bus via i3c_init_bus, and use the bus returned from the
init function to do transactions on the bus.

In order to handle IBIs, the controller provides callbacks to handle
receiving an IBI from a target, receiving (optional) additional IBI
bytes from a target, and handling when a target is done with its IBI.

Similarly, target creation is done via i3c_target_create_simple and
users use the provided I3CTarget to handle transactions.
The target has functions provided that it can use to invoke an IBI and
send additional bytes.

Along with the expected, send, recv, and event callbacks that is
expected of an I3C target, which are similar to I2C, there is a separate
callback for CCC handling.
This is to help encapsulate CCC handling and keep it separate from
target-specific read/write functionality.

To avoid repition for required CCCs among I3C targets, there is some
class-level CCC handling added. The CCC is then passed to the target in
case it needs to handle it in some way.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Titus Rwantare <titusr@google.com>

show more ...

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and create I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and create I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Titus Rwantare <titusr@google.com>
[ clg: - replaced softmmu_ss with system_ss in meson.build files
- local variable renames in aspeed_i3c_realize() ]

show more ...

hw/i3c: remote_i3c: Add model

Adds a model to communicate to remote I3C devices over chardev. This
allows QEMU to communicate to I3C targets that exist outside of QEMU.

The remote I3C protocol is a

hw/i3c: remote_i3c: Add model

Adds a model to communicate to remote I3C devices over chardev. This
allows QEMU to communicate to I3C targets that exist outside of QEMU.

The remote I3C protocol is as follows:
On an I3C private and CCC TX (controller -> target)
- 1-byte opcode
- 4-byte number of bytes in the packet as a LE uint32
- n-byte payload

On an I3C private and CCC RX (target -> controller)
Controller to target:
- 1-byte opcode
- 4-byte number of bytes to read as a LE uint32
Remote target response:
- 4-byte number of bytes in the packet as a LE uint32
- n-byte payload

IBI (target -> controller, initiated by target)
- 1-byte opcode
- 1-byte IBI address
- 1-byte RnW boolean
- 4-byte length of IBI payload from target as a LE uint32 (can be 0)
- n-byte IBI payload

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

hw/i3c: Add Mock target

Adds a simple i3c device to be used for testing in lieu of a real
device.

The mock target supports the following features:
- A buffer that users can read and write to.
- CCC

hw/i3c: Add Mock target

Adds a simple i3c device to be used for testing in lieu of a real
device.

The mock target supports the following features:
- A buffer that users can read and write to.
- CCC support for commonly used CCCs when probing devices on an I3C bus.
- IBI sending upon receiving a user-defined byte.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Titus Rwantare <titusr@google.com>
Reviewed-by: Patrick Venture <venture@google.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

hw/i3c/aspeed_i3c: Add controller resets

Adds behavior to the device reset register.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by:

hw/i3c/aspeed_i3c: Add controller resets

Adds behavior to the device reset register.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

hw/i3c/aspeed_i3c: Add IBI handling

Adds handling for different IBI events that the controller can receive.
This includes:
- Handling a hot-join from a target
- Handling a secondary controller on th

hw/i3c/aspeed_i3c: Add IBI handling

Adds handling for different IBI events that the controller can receive.
This includes:
- Handling a hot-join from a target
- Handling a secondary controller on the bus requesting to be the
primary bus controller
- Handling an interrupt request from a target.

When receiving an IBI, the controller sets an interrupt to notify
software about what happened.
When the IBI is finished being serviced, the controller pushes the
result of the IBI and any data received from the target into the IBI
queue.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Stephen Longfield <slongfield@google.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...