Introduce the AST1040 I2C controller model.
The AST1040 I2C controller is compatible with the AST2700 I2C controller,
including DMA support and the 64-bit DMA address registers. Set has_dma64 so
firmware can access the high address register and program it to zero, as the
CM4 CPU only supports 32-bit addressing.
AST1040 has 14 I2C buses and its HyperRAM is limited to 16 MiB,
so restrict the DMA low address mask to 0x00ffffff.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260603040027.938816-8-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Update the AST2700 I2C buffer mode configuration to match
the latest firmware definition:
- Increase buffer mode pool size from 0x20 to 0x40
- Adjust buffer mode base offset to 0x1c0
Since the buffer mode region size changes, the migration state
layout is also modified. Bump the VMState version numbers to
prevent incompatible migration between old and new machine states.
Fixes: 1809ab6a67 ("hw/i2c/aspeed: Add AST2700 support")
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260603040027.938816-3-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The Aspeed I2C controller has two register layouts.
The AST2500 uses the old mode with a single DMA address register (I2CD_DMA_ADDR)
where the address is 4-byte aligned and masked to 0x3ffffffc.
>From AST2600 onwards, the new mode provides separate master TX/RX and slave RX DMA
address registers (I2CM_DMA_TX_ADDR, I2CM_DMA_RX_ADDR, I2CS_DMA_RX_ADDR)
with different address widths per SoC:
AST2600 (new mode): 0x7fffffff - bits[30:0]
AST1030 (new mode): 0x7fffffff - bits[30:0]
AST1060 (new mode): 0x7fffffff - bits[30:0]
AST2700 (new mode): 0xffffffff - bits[31:0]
Introduce dma_addr_lo_mask as a per-class attribute and apply it
uniformly when storing DMA address register writes and when loading
the address into dma_dram_offset for both master and slave paths.
This replaces the previous FIELD_EX32 extractions (which incorrectly
stripped bit 31 on AST2700) and the hardcoded 0x3ffffffc literal in
the old-mode path.
Fixes: 1809ab6a67 ("hw/i2c/aspeed: Add AST2700 support")
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260603040027.938816-2-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Replace the legacy type_register_static()/type_init() registration
pattern with the modern DEFINE_TYPES() macro.
Inline 9 standalone TypeInfo variables (aspeed_i2c_bus_info,
aspeed_i2c_bus_slave_info, aspeed_i2c_info as abstract base,
aspeed_2400_i2c_info, aspeed_2500_i2c_info, aspeed_2600_i2c_info,
aspeed_1030_i2c_info and aspeed_2700_i2c_info) directly into the
'aspeed_i2c_types[]' array, removing the need for
separate declarations.
No functional change.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260601024959.2347639-23-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The intermediate result of (Y * 10^-R - b) / m can be negative when
the bias (b) is large and the raw register value is small (e.g. zero
on an uninitialized device). Assigning that negative double to uint32_t
is undefined behavior, caught by UBSan/clang.
Use a double intermediate and clamp negative results to zero (suggested
by Daniel Berrangé)
Fixes: 3746d5c15e ("hw/i2c: add support for PMBus")
Reviewed-by: Titus Rwantare <titusr@google.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Commit 7e82393ed0 ("hw/i2c/aspeed: fix lost interrupts on
back-to-back commands") introduced pending_intr_sts to preserve
interrupt bits that collide with already pending status bits.
That deferred interrupt state is consumed later when the guest clears
INTR_STS, but it is not reset in aspeed_i2c_bus_reset() and it is not
part of the bus migration state. A reset can therefore leave stale
deferred bits behind, and migration can silently drop them.
Clear pending_intr_sts on reset and include it in VMState while keeping
compatibility with older migration streams.
Fixes: 7e82393ed0 ("hw/i2c/aspeed: fix lost interrupts on back-to-back commands")
Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Link: https://lore.kernel.org/qemu-devel/20260325085450.126595-1-zhaoguohan@kylinos.cn
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
According to the Aspeed datasheet, the RX_BUF_LEN_W1T and
TX_BUF_LEN_W1T bits of the A_I2CS_DMA_LEN (0x2c) register allow
firmware to program the TX and RX DMA length (TX_BUF_LEN and
RX_BUF_LEN fields of the same register) separately without the need to
read/modify/write the value. If RX_BUF_LEN_W1T and TX_BUF_LEN_W1T
bits are 0, then both TX and RX DMA length will be written.
When setting the RX_BUF_LEN field, the TX_BUF_LEN field being set is
not an invalid condition. Remove the assert.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3315
Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260323125545.577653-4-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
QEMU executes I2C commands synchronously inside the CMD register write
handler. On real hardware each command takes time on the bus, so the
ISR can clear the previous interrupt status before the next completion
arrives. In QEMU, when the guest ISR handles a TX_ACK and immediately
issues the next command by writing to CMD, that command completes
instantly — before the ISR returns to W1C-clear the first TX_ACK.
Since the bit is already set, setting it again is a no-op. The ISR
then clears it, wiping both completions at once. No interrupt fires
for the second command and the driver stalls.
This affects any multi-step I2C transaction: register reads, SMBus
word reads, and PMBus device probes all fail ("Error: Read failed"
from i2cget, -ETIMEDOUT from kernel drivers).
The issue is exposed when the guest kernel includes commit "i2c:
aspeed: Acknowledge Tx done with and without ACK irq late" [1] which
defers W1C acknowledgment of TX_ACK until after the ISR has issued
the next command. This means the old TX_ACK is still set when the
next command completes synchronously, and the subsequent W1C wipes
both completions at once.
The trace below shows `i2cget -y 15 0x50 0x00` (read EEPROM register
0x00) failing without the fix. The first START+TX sets TX_ACK. The
ISR handles it and issues a second TX to send the register address.
That TX completes synchronously while TX_ACK is still set:
aspeed_i2c_bus_cmd cmd=0x3 start|tx| intr=0x0 # START+TX, clean
aspeed_i2c_bus_raise_interrupt intr=0x1 ack| # TX_ACK set
aspeed_i2c_bus_read 0x10: 0x1 # ISR reads TX_ACK
aspeed_i2c_bus_write 0x14: 0x2 # ISR issues TX cmd
aspeed_i2c_bus_cmd cmd=0x400002 tx| intr=0x1 # TX runs, TX_ACK already set!
aspeed_i2c_bus_raise_interrupt intr=0x1 ack| # re-set is no-op
aspeed_i2c_bus_write 0x10: 0x1 # ISR W1C clears TX_ACK
aspeed_i2c_bus_read 0x10: 0x0 # LOST — both ACKs wiped
The driver sees INTR_STS=0 and never proceeds to the read phase.
Fix this by tracking interrupt bits that collide with already-pending
bits. Before calling aspeed_i2c_bus_handle_cmd(), save and clear
INTR_STS so that only freshly set bits are visible after the call.
Any overlap between the old and new bits is saved in pending_intr_sts.
When the ISR later W1C-clears the old bits, re-apply the saved
pending bits so the ISR sees them on its next loop iteration.
With the fix, the same operation completes successfully:
aspeed_i2c_bus_cmd cmd=0x3 start|tx| intr=0x0 # START+TX, clean
aspeed_i2c_bus_raise_interrupt intr=0x1 ack| # TX_ACK set
aspeed_i2c_bus_read 0x10: 0x1 # ISR reads TX_ACK
aspeed_i2c_bus_write 0x14: 0x2 # ISR issues TX cmd
aspeed_i2c_bus_cmd cmd=0x400002 tx| intr=0x0 # INTR_STS cleared first
aspeed_i2c_bus_raise_interrupt intr=0x1 ack| # TX_ACK freshly set
aspeed_i2c_bus_write 0x10: 0x1 # ISR W1C clears TX_ACK
aspeed_i2c_bus_read 0x10: 0x1 # RE-DELIVERED from pending
aspeed_i2c_bus_write 0x14: 0x1b # ISR proceeds: START+RX
aspeed_i2c_bus_cmd cmd=0x40001b start|tx|rx|last| # read phase completes
i2c_recv recv(addr:0x50) data:0x00 # data received
[1] https://lore.kernel.org/all/20231211102217.2436294-3-quan@os.amperecomputing.com/
Signed-off-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com>
Fixes: 1602001195 ("i2c: add aspeed i2c controller")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260311023712.2730185-1-jithu.joseph@oss.qualcomm.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The MachineClass::smbus_no_migration_support boolean was only used
by the pc-q35-3.1 and pc-i440fx-3.1 machines, which got removed.
Remove it, along with pm_smbus_vmstate_needed().
Use the unconditional VMSTATE_BOOL() and VMSTATE_STRUCT() macros.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Corey Minyard <corey@minyard.net>
Message-Id: <20260307152635.83893-5-philmd@linaro.org>
The current code updates the upper 32 bits of dma_dram_offset only when
aic->has_dma64 is false, which is incorrect.
If aic->has_dma64 is true, the controller supports 64-bit DMA addressing
and the upper 32-bit DMA address register must be used to update the
dma_dram_offset accordingly.
Fix the condition so that the upper 32 bits are updated only when
64-bit DMA is supported.
Fixes: efea7ddb46 ("hw/i2c/aspeed_i2c: Fix DMA moving data into incorrect address")
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260224073207.985162-1-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
According to the AST2700 A1 datasheet, the register space for each I2C
device instance has been expanded from 0x80 bytes to 0xA0 bytes.
Update the AST2700 I2C controller configuration to reflect the new
register layout by increasing the per-device register size to 0xA0
and adjusting the register gap size accordingly.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Fixes: 4f53de2f10 ("hw/arm/aspeed_ast27x0: Remove ast2700-a0 SOC")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260210024331.3984696-3-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The ASPEED I2C controller exposes a per-bus MMIO window of 0x80 bytes on
AST2600/AST1030/AST2700, but the backing regs[] array was sized for only
28 dwords (0x70 bytes). This allows guest reads in the range [0x70..0x7f]
to index past the end of regs[].
Fix this by:
- Sizing ASPEED_I2C_NEW_NUM_REG to match the 0x80-byte window
(0x80 >> 2 = 32 dwords).
- Avoiding an unconditional pre-read from regs[] in the legacy/new read
handlers. Initialize the return value to -1 and only read regs[] for
offsets that are explicitly handled/valid, leaving invalid offsets to
return -1 with a guest error log.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3290
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260210024331.3984696-2-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
In the previous design, the I2C model updated dma_dram_offset only when
firmware programmed the RX/TX DMA buffer address registers. The firmware
used to rewrite these registers before issuing each DMA command.
The firmware driver behavior has changed to program the DMA address
registers only once during I2C initialization. As a result, the I2C model
no longer refreshes dma_dram_offset, causing DMA to move data into an
incorrect DRAM address.
Fix this by introducing helper functions to update dma_dram_offset from
the DMA address registers, and invoke them right before handling TX/RX
DMA operations. This guarantees DMA always uses the correct buffer
address even if the registers are programmed only once.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Fixes: c400c38854 ("hw/i2c/aspeed: Introduce a new dma_dram_offset attribute in AspeedI2Cbus")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260203020855.1642884-5-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
On some Aspeed-based machines, multiple I2C controllers may exist
across different components, such as the primary SoC and an external
IO expander or co-processor (e.g., AST1700). Using the current static
naming convention results in object name conflicts when multiple
controllers attempt to instantiate buses with the same ID.
This patch introduces a 'bus-label' property for the Aspeed I2C
controller. This allows higher-level layers, such as the SoC realize
function, to provide a unique identifier for the buses. The I2C bus
object name is then constructed using this label (e.g., "ioexp0.0"
instead of the default "aspeed.i2c.bus.0").
This enhancement ensures unique bus identifiers across the system and
resolves naming conflicts in multi-controller configurations.
Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Nabih Estefan <nabihestefan@google.com>
Reviewed-by: Nabih Estefan <nabihestefan@google.com>
Link: https://lore.kernel.org/qemu-devel/20260112083054.4151945-2-kane_chen@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of these functions in omap_i2c.c with an
open-coded call to qemu_log_mask() and RAZ/WI behaviour.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
In the previous design, the I2C model would update I2CC_DMA_LEN (0x54) based on
the value of I2CM_DMA_LEN (0x1C) when the firmware set either I2CM_DMA_TX_ADDR
(0x30) or I2CM_DMA_RX_ADDR (0x34). However, this only worked correctly if the
firmware set I2CM_DMA_LEN before setting I2CM_DMA_TX_ADDR or I2CM_DMA_RX_ADDR.
If the firmware instead set I2CM_DMA_TX_ADDR or I2CM_DMA_RX_ADDR before setting
I2CM_DMA_LEN, the value written to I2CC_DMA_LEN would be incorrect.
To fix this issue, the model should be updated to set I2CC_DMA_LEN when the
firmware writes to the I2CM_DMA_LEN register, rather than when it writes to the
I2CM_DMA_RX_ADDR and I2CM_DMA_TX_ADDR registers.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Fixes: ba2cccd64e ("aspeed: i2c: Add new mode support")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260102090746.1130033-4-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
In hw/arm and include/hw/arm, some source files for the OMAP SoC
and the sx1 boards that are our only remaining OMAP boards still
have hard-coded tabs (almost entirely used for the indent on
inline comments, not for actual code indent).
Replace the tabs with spaces using vim :retab. I used 4 spaces
except in some defines and comments where I tried to put
everything aligned in the same column for better readability.
This commit is a purely whitespace-only change.
Signed-off-by: Santiago Monserrat Campanello <santimonserr@gmail.com>
Message-id: 20250505131130.82206-1-santimonserr@gmail.com
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/373
[PMM: expanded commit message]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
According to the i.MX 8M Plus reference manual, the status flag
I2C_I2SR[IIF] continues to be set when an interrupt condition
occurs even when I2C interrupts are disabled (I2C_I2CR[IIEN] is
clear). However, the device model only sets the flag when I2C
interrupts are enabled which causes U-Boot to loop forever. Fix
the device model by always setting the flag and let I2C_I2CR[IIEN]
guard I2C interrupts only.
Also remove the comment in the code since it merely stated the
obvious and would be outdated now.
Cc: qemu-stable@nongnu.org
Fixes: 20d0f9cf6a ("i.MX: Add I2C controller emulator")
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Acked-by: Corey Minyard <cminyard@mvista.com>
Message-ID: <20250507124040.425773-1-shentey@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
These devices are only used by the ARM targets, which are
only built as little-endian. Therefore the DEVICE_NATIVE_ENDIAN
definition expand to DEVICE_LITTLE_ENDIAN (besides, the
DEVICE_BIG_ENDIAN case isn't tested). Simplify directly using
DEVICE_LITTLE_ENDIAN.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250212113938.38692-2-philmd@linaro.org>
ASPEED AST2700 SOC is a 64 bits quad core CPUs (Cortex-a35)
and the base address of dram is "0x4 00000000" which
is 64bits address.
The AST2700 support the maximum DRAM size is 8 GB.
The DRAM physical address range is from "0x4_0000_0000" to
"0x5_FFFF_FFFF".
The DRAM offset range is from "0x0_0000_0000" to
"0x1_FFFF_FFFF" and it is enough to use bits [33:0]
saving the dram offset.
Therefore, save the high part physical address bit[1:0]
of Tx/Rx buffer address as dma_dram_offset bit[33:32].
It does not need to decrease the dram physical
high part address for DMA operation.
(high part physical address bit[7:0] – 4)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
ASPEED AST2700 SOC is a 64 bits quad core CPUs (Cortex-a35)
and the base address of dram is "0x4 00000000" which
is 64bits address.
It has "Master DMA Mode Tx Buffer Base Address[39:32](0x60)"
and "Master DMA Mode Rx Buffer Base Address[39:32](0x64)"
registers to save the high part physical address of Tx/Rx
buffer address for master mode.
It has "Slave DMA Mode Tx Buffer Base Address[39:32](0x68)" and
"Slave DMA Mode Rx Buffer Base Address[39:32](0x6C)" registers
to save the high part physical address of Tx/Rx buffer address
for slave mode.
Ex: Tx buffer address for master mode [39:0]
The "Master DMA Mode Tx Buffer Base Address[39:32](0x60)"
bits [7:0] which corresponds the bits [39:32] of the 64 bits address of
the Tx buffer address.
The "Master DMA Mode Tx Buffer Base Address(0x30)" bits [31:0]
which corresponds the bits [31:0] of the 64 bits address
of the Tx buffer address.
Introduce a new has_dma64 class attribute and new registers for the
new mode to support DMA 64 bits dram address.
Update new mode register number to 28.
The aspeed_i2c_bus_vmstate is changed again and
version is not increased because it was done earlier in the same series.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Introduce a new ast2700 class to support AST2700.
The I2C bus register memory regions and
I2C bus pool buffer memory regions are discontinuous
and they do not back compatible AST2600.
Add a new ast2700 i2c class init function to match the
address of I2C bus register and pool buffer from the datasheet.
An I2C controller registers owns 8KB address space.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
The "Current DMA Operating Address Status(0x50)" register of
I2C new mode has been removed in AST2700.
This register is used for debugging and it is a read only register.
To support AST2700 DMA mode, introduce a new
dma_dram_offset class attribute in AspeedI2Cbus to save the
current DMA operating address.
ASPEED AST2700 SOC is a 64 bits quad core CPUs (Cortex-a35)
And the base address of dram is "0x4 00000000" which
is 64bits address.
Set the dma_dram_offset data type to uint64_t for
64 bits dram address DMA support.
Both "DMA Mode Buffer Address Register(I2CD24 old mode)" and
"DMA Operating Address Status (I2CC50 new mode)" are used for showing the
low part dram offset bits [31:0], so change to read/write both register bits [31:0] in
bus register read/write functions.
The aspeed_i2c_bus_vmstate is changed again and version is not increased
because it was done earlier in the same series.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
It only support continuous pool buffer memory region for all I2C bus.
However, the pool buffer address of all I2c bus are discontinuous
for AST2700.
Ex: the pool buffer address of I2C bus for ast2700 as following.
0x1A0 - 0x1BF: Device 0 buffer
0x2A0 - 0x2BF: Device 1 buffer
0x3A0 - 0x3BF: Device 2 buffer
0x4A0 - 0x4BF: Device 3 buffer
0x5A0 - 0x5BF: Device 4 buffer
0x6A0 - 0x6BF: Device 5 buffer
0x7A0 - 0x7BF: Device 6 buffer
0x8A0 - 0x8BF: Device 7 buffer
0x9A0 - 0x9BF: Device 8 buffer
0xAA0 - 0xABF: Device 9 buffer
0xBA0 - 0xBBF: Device 10 buffer
0xCA0 - 0xCBF: Device 11 buffer
0xDA0 - 0xDBF: Device 12 buffer
0xEA0 - 0xEBF: Device 13 buffer
0xFA0 – 0xFBF: Device 14 buffer
0x10A0 – 0x10BF: Device 15 buffer
Introduce a new class attribute to make user set each I2C bus
pool buffer gap size. Update formula to create all I2C bus
pool buffer memory regions.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
According to the datasheet of ASPEED SOCs,
each I2C bus has their own pool buffer since AST2500.
Only AST2400 utilized a pool buffer share to all I2C bus.
Besides, using a share pool buffer only support
pool buffer memory regions are continuous for all I2C bus.
To make this model more readable and support discontinuous
bus pool buffer memory regions, changes to introduce
a new bus pool buffer attribute in AspeedI2Cbus and
new memops. So, it does not need to calculate
the pool buffer offset for different I2C bus.
Introduce a new has_share_pool class attribute in AspeedI2CClass and
use it to create either a share pool buffer or bus pool buffers
in aspeed_i2c_realize. Update each pull buffer size to 0x10 for AST2500
and 0x20 for AST2600 and AST1030.
Incrementing the version of aspeed_i2c_bus_vmstate to 6.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
It only support continuous register memory region for all I2C bus.
However, the register address of all I2c bus are discontinuous
for AST2700.
Ex: the register address of I2C bus for ast2700 as following.
0x100 - 0x17F: Device 0
0x200 - 0x27F: Device 1
0x300 - 0x37F: Device 2
0x400 - 0x47F: Device 3
0x500 - 0x57F: Device 4
0x600 - 0x67F: Device 5
0x700 - 0x77F: Device 6
0x800 - 0x87F: Device 7
0x900 - 0x97F: Device 8
0xA00 - 0xA7F: Device 9
0xB00 - 0xB7F: Device 10
0xC00 - 0xC7F: Device 11
0xD00 - 0xD7F: Device 12
0xE00 - 0xE7F: Device 13
0xF00 – 0xF7F: Device 14
0x1000 – 0x107F: Device 15
Introduce a new class attribute to make user set each I2C bus gap size.
Update formula to create all I2C bus register memory regions.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Use device_class_set_legacy_reset() instead of opencoding an
assignment to DeviceClass::reset. This change was produced
with:
spatch --macro-file scripts/cocci-macro-file.h \
--sp-file scripts/coccinelle/device-reset.cocci \
--keep-comments --smpl-spacing --in-place --dir hw
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20240830145812.1967042-8-peter.maydell@linaro.org
The last register of this device is at offset 0x14 occupying 8 bits so
to cover it the mmio region needs to be 0x15 bytes long. Also correct
the name of the field storing this register value to match the
register name.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Fixes: 7abb479c7a ("PPC: E500: Add FSL I2C controller")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240721225506.B32704E6039@zero.eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
According to the datasheet of ASPEED SOCs,
each I2C bus has their own pool buffer since AST2500.
Only AST2400 utilized a pool buffer share to all I2C bus.
And firmware required to set the offset of pool buffer
by writing "Function Control Register(I2CD 00)"
To make this model more readable, will change to introduce
a new bus pool buffer attribute in AspeedI2Cbus.
So, it does not need to calculate the pool buffer offset
for different I2C bus.
This patch rename the I2C class pool attribute to share_pool.
It make user more understand share pool and bus pool
are different.
Incrementing the version of aspeed_i2c_vmstate to 3.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
