bwlp/qemu.git/hw/i2c, branch spice_video_codecs

hw/i2c/aspeed: Fix old reg slave receive

2022-10-24T09:20:15+00:00

I think when Klaus ported his slave mode changes from the original patch series to the rewritten I2C module, he changed the behavior of the first byte that is received by the slave device. What's supposed to happen is that the AspeedI2CBus's slave device's i2c_event callback should run, and if the event is "send_async", then it should populate the byte buffer with the 8-bit I2C address that is being sent to. Since we only support "send_async", the lowest bit should always be 0 (indicating that the master is requesting to send data). This is the code Klaus had previously, for reference. [1] switch (event) { case I2C_START_SEND: bus->buf = bus->dev_addr << 1; bus->buf &= I2CD_BYTE_BUF_RX_MASK; bus->buf <<= I2CD_BYTE_BUF_RX_SHIFT; bus->intr_status |= (I2CD_INTR_SLAVE_ADDR_RX_MATCH | I2CD_INTR_RX_DONE); aspeed_i2c_set_state(bus, I2CD_STXD); break; [1]: https://lore.kernel.org/qemu-devel/20220331165737.1073520-4-its@irrelevant.dk/ Fixes: a8d48f59cd021b25 ("hw/i2c/aspeed: add slave device in old register mode") Signed-off-by: Peter Delevoryas Reviewed-by: Klaus Jensen Message-Id: <20220820225712.713209-2-peter@pjd.dev> Signed-off-by: Cédric Le Goater

hw/i2c/pmbus: Add idle state to return 0xff's

2022-07-14T14:24:38+00:00

Signed-off-by: Peter Delevoryas Reviewed-by: Titus Rwantare Message-Id: <20220701000626.77395-2-me@pjd.dev> Signed-off-by: Cédric Le Goater

hw/i2c/aspeed: Add new-registers DMA slave mode RX support

2022-06-30T07:21:14+00:00

This commit adds support for DMA RX in slave mode while using the new register set in the AST2600 and AST1030. This patch also pretty much assumes packet mode is enabled, I'm not sure if this will work in DMA step mode. This is particularly useful for testing IPMB exchanges between Zephyr and external devices, which requires multi-master I2C support and DMA in the new register mode, because the Zephyr drivers from Aspeed use DMA in the new mode by default. The Zephyr drivers are also using packet mode. The typical sequence of events for receiving data in DMA slave + packet mode is that the Zephyr firmware will configure the slave address register with an address to receive on and configure the bus's function control register to enable master mode and slave mode simultaneously at startup, before any transfers are initiated. RX DMA is enabled in the slave mode command register, and the slave RX DMA buffer address and slave RX DMA buffer length are set. TX DMA is not covered in this patch. When the Aspeed I2C controller receives data from some other I2C master, it will reset the I2CS_DMA_LEN RX_LEN value to zero, then buffer incoming data in the RX DMA buffer while incrementing the I2CC_DMA_ADDR address counter and decrementing the I2CC_DMA_LEN counter. It will also update the I2CS_DMA_LEN RX_LEN value along the way. Once all the data has been received, the bus controller will raise an interrupt indicating a packet command was completed, the slave address matched, a normal stop condition was seen, and the transfer was an RX operation. If the master sent a NACK instead of a normal stop condition, or the transfer timed out, then a slightly different set of interrupt status values would be set. Those conditions are not handled in this commit. The Zephyr firmware then collects data from the RX DMA buffer and clears the status register by writing the PKT_MODE_EN bit to the status register. In packet mode, clearing the packet mode interrupt enable bit also clears most of the other interrupt bits automatically (except for a few bits above it). Note: if the master transmit or receive functions were in use simultaneously with the slave mode receive functionality, then the master mode functions may have raised the interrupt line for the bus before the DMA slave transfer is complete. It's important to have the slave's interrupt status register clear throughout the receive operation, and if the slave attempts to raise the interrupt before the master interrupt status is cleared, then it needs to re-raise the interrupt once the master interrupt status is cleared. (And vice-versa). That's why in this commit, when the master interrupt status is cleared and the interrupt line is lowered, we call the slave interrupt _raise_ function, to see if the interrupt was pending. (And again, vice-versa). Signed-off-by: Peter Delevoryas Message-Id: <20220630045133.32251-8-me@pjd.dev> Signed-off-by: Cédric Le Goater

hw/i2c/aspeed: add slave device in old register mode

2022-06-30T07:21:14+00:00

Add slave mode functionality for the Aspeed I2C controller in old register mode. This is implemented by realizing an I2C slave device owned by the I2C controller and attached to its own bus. The I2C slave device only implements asynchronous sends on the bus, so slaves not supporting that will not be able to communicate with it. Signed-off-by: Klaus Jensen [ clg: checkpatch fixes ] Message-Id: <20220601210831.67259-6-its@irrelevant.dk> Signed-off-by: Cédric Le Goater Message-Id: <20220630045133.32251-7-me@pjd.dev> Signed-off-by: Cédric Le Goater

hw/i2c: add asynchronous send

2022-06-30T07:21:14+00:00

Add an asynchronous version of i2c_send() that requires the slave to explicitly acknowledge on the bus with i2c_ack(). The current master must use the new i2c_start_send_async() to indicate that it wants to do an asynchronous transfer. This allows the i2c core to check if the target slave supports this or not. This approach relies on adding a new enum i2c_event member, which is why a bunch of other devices needs changes in their event handling switches. Signed-off-by: Klaus Jensen Message-Id: <20220601210831.67259-5-its@irrelevant.dk> Signed-off-by: Cédric Le Goater Message-Id: <20220630045133.32251-6-me@pjd.dev> Signed-off-by: Cédric Le Goater

hw/i2c: support multiple masters

2022-06-30T07:21:14+00:00

Allow slaves to master the bus by registering a bottom halve. If the bus is busy, the bottom half is queued up. When a slave has succesfully mastered the bus, the bottom half is scheduled. Signed-off-by: Klaus Jensen [ clg : - fixed typos in commit log ] Message-Id: <20220601210831.67259-4-its@irrelevant.dk> Signed-off-by: Cédric Le Goater Message-Id: <20220630045133.32251-5-me@pjd.dev> Signed-off-by: Cédric Le Goater

hw/i2c/aspeed: Fix MASTER_EN missing error message

2022-06-30T07:21:14+00:00

aspeed_i2c_bus_is_master is checking if master mode is enabled in the I2C bus controller's function-control register, not that slave mode is enabled or something. The error here is that the guest is trying to trigger an I2C master mode command while master mode is not enabled. Fixes: ba2cccd64e90f342 ("aspeed: i2c: Add new mode support") Signed-off-by: Peter Delevoryas Message-Id: <20220630045133.32251-4-me@pjd.dev> Reviewed-by: Cédric Le Goater Signed-off-by: Cédric Le Goater

hw/i2c/aspeed: Fix DMA len write-enable bit handling

2022-06-30T07:21:13+00:00

I noticed i2c rx transfers were getting shortened to "1" on Zephyr. It seems to be because the Zephyr i2c driver sets the RX DMA len with the RX field write-enable bit set (bit 31) to avoid a read-modify-write. [1] /* 0x1C : I2CM Master DMA Transfer Length Register */ I think we should be checking the write-enable bits on the incoming value, not checking the register array. I'm not sure we're even writing the write-enable bits to the register array, actually. [1] https://github.com/AspeedTech-BMC/zephyr/blob/db3dbcc9c52e67a47180890ac938ed380b33f91c/drivers/i2c/i2c_aspeed.c#L145-L148 Fixes: ba2cccd64e90f34 ("aspeed: i2c: Add new mode support") Signed-off-by: Peter Delevoryas Message-Id: <20220630045133.32251-3-me@pjd.dev> Reviewed-by: Cédric Le Goater Signed-off-by: Cédric Le Goater

hw/i2c/aspeed: Fix R_I2CD_FUN_CTRL reference

2022-06-30T07:21:13+00:00

Very minor, doesn't effect functionality, but this is supposed to be R_I2CC_FUN_CTRL (new-mode, not old-mode). Fixes: ba2cccd64e9 ("aspeed: i2c: Add new mode support") Signed-off-by: Peter Delevoryas Message-Id: <20220630045133.32251-2-me@pjd.dev> Reviewed-by: Cédric Le Goater Signed-off-by: Cédric Le Goater

hw/i2c: pmbus: Page #255 is valid page for read requests.

2022-06-30T07:21:13+00:00

Current implementation of the pmbus core driver treats the read request for page 255 as invalid request and sets the invalid command bit (bit 7) in the STATUS_CML register. As per the PMBus specification it is a valid request. Refer to the PMBus specification, revision 1.3.1, section 11.10 PAGE, on the page 58: "Setting the PAGE to FFh means that all subsequent comands are to be applied to all outputs. Some commands, such as READ_TEMPERATURE, may use a common sensor but be available on all pages of a device. Such implementations are the decision of each device manufacturer or are specified in a PMBus Application Profile. Consult the manufacturer's documents or the Application Profile Specification as needed." For e.g., The VOUT_MODE is a valid command for page 255 for maxim 31785 device. refer to Table 1. PMBus Command Codes on page 14 in the datasheet. https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf Fixes: 38870253f1d1 ("hw/i2c: pmbus: fix error returns and guard against out of range accesses") Signed-off-by: Maheswara Kurapati Signed-off-by: Jae Hyun Yoo Reviewed-by: Titus Rwantare Reviewed-by: Cédric Le Goater Message-Id: <20220627154703.148943-4-quic_jaehyoo@quicinc.com> Signed-off-by: Cédric Le Goater