| d3657f9f | 12-Jun-2025 |
Joe Komlodi <komlodi@google.com> |
hw/i3c/aspeed: Add I3C bus get function
To retrieve the I3C bus object normally, the order is Aspeed I3C -> DW
I3C[n] -> bus object, so make a nice wrapper for people to use.
Signed-off-by: Joe Kom
hw/i3c/aspeed: Add I3C bus get function
To retrieve the I3C bus object normally, the order is Aspeed I3C -> DW
I3C[n] -> bus object, so make a nice wrapper for people to use.
Signed-off-by: Joe Komlodi <komlodi@google.com>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-17-komlodi@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
show more ...
|
| 43d97db9 | 12-Jun-2025 |
Joe Komlodi <komlodi@google.com> |
hw/i3c/dw-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 bu
hw/i3c/dw-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>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-14-komlodi@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
show more ...
|
| e5f455c4 | 12-Jun-2025 |
Joe Komlodi <komlodi@google.com> |
hw/i3c/dw-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
hw/i3c/dw-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>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-13-komlodi@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
show more ...
|
| 4abac3ab | 12-Jun-2025 |
Joe Komlodi <komlodi@google.com> |
hw/i3c: Split DesignWare I3C out of Aspeed I3C
The Aspeed I3C IP block is technically an Aspeed IP block that manages
6 DW I3C controllers.
To help reflect this better and to make it easier for oth
hw/i3c: Split DesignWare I3C out of Aspeed I3C
The Aspeed I3C IP block is technically an Aspeed IP block that manages
6 DW I3C controllers.
To help reflect this better and to make it easier for other SoCs to use
the DW I3C model, we'll split out the DW portion from the Aspeed
portion.
Signed-off-by: Joe Komlodi <komlodi@google.com>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-4-komlodi@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
show more ...
|
| 80ee3015 | 12-Jun-2025 |
Joe Komlodi <komlodi@google.com> |
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 send, recv, and event callbacks that are 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>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-3-komlodi@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
show more ...
|