Below is how I understand it as of now, I could be wrong on any number of things.
RayeR wrote on 2025-04-24, 20:51:
That's what I'm talking about. You will have 2 separate DMA controllers (one in PCH, second in ITE) and they needs to expose IO config ports that gets in conflict. You still need that your DMA in ITE use legacy IO ports addresses for compatability with existing SW.
When you have both a motherboard DMA controller and the IT8888 trying to use the same I/O addresses (like 0x00-0x0F, 0xC0-0xDF for DMA controllers), the IT8888 uses Positive I/O Space Decoding feature to claim these addresses first:
From section 6.4 of the datasheet: "The six positively decode I/O spaces can be programmed to claim PCI I/O cycle with Fast / Medium / Slow / Subtractive DEVSEL# timing speed."
By configuring the IT8888 via EEPROM to use "Fast" decoding timing for these legacy I/O ports, it will respond to I/O accesses before the motherboard chipset can claim them. In PCI architecture, if more than one device could respond to an I/O address, the device that asserts DEVSEL# first wins the cycle and becomes the responder.
When software tries to access a DMA register:
- The IT8888 responds quickly with the DEVSEL# signal (Device Select)
- This tells the system "I own this address"
- The motherboard's chipset backs off and lets the IT8888 handle the request
- Any DMA controller in the chipset becomes effectively invisible
As the manual states on page 13: "The PCI Slave interface provides some decode spaces for internal registers and ISA accesses. The IT8888 will claim the cycle by asserting DEVSEL#." This is why the EEPROM configuration is important; it sets up the IT8888 to claim these I/O ports at boot time before any software tries to access them. Essentially, the IT8888 becomes a complete replacement for the motherboard's legacy DMA controller, making the motherboard's DMA hardware irrelevant even if it physically exists.
RayeR wrote on 2025-04-24, 20:51:
What exactly can be configured in the serial EEPROM?
The EEPROM can preprogram almost the entire PCI configuration space of the IT8888, including: I/O and memory space decoding, DMA channel enable/disable and base address remapping, DEVSEL# timing (fast/medium/slow), ROM decoding control, Interrupt configuration and routing, Arbitration preferences and timing optimizations. This allows the bridge to fully boot into a legacy compatible mode without requiring outside intervention.
RayeR wrote on 2025-04-24, 20:51:
I think that for success mission you need to
1) disable DMA (or its leftover) in PCH to free the legacy IO ports addresses or use PCH completly without legacy DMA controller (do they exist? how about e.g. current Z690? anybody scanned that ports are really free?, how about AMD?)
2) you need to be able to route IO transactions to legacy IO ports addresses to be directed to the ITE chip - it needs to pass through PCIe to PCI bridge between on the path. In older chipsets that has LPC controller this IO transactions are usually routed there instead to external PCI device. It's similar like you need to configure saphisa tool to pass soundcard IO...
There's probably no need to disable motherboard DMA controller since the IT8888 takes care of this automatically through its positive decoding feature as described above. This means you shouldn't need to worry about whether or not any platform still has DMA controllers or DMA leftovers; the IT8888 should theoretically claim the I/O addresses first. I believe this is similar to how PCI expansion cards can override built-in devices by claiming the same resources, which is a standard capability of the PCI bus architecture.
RayeR wrote on 2025-04-24, 20:51:
Also there's one question about latency and timing. Let's assume your idea with DDMA would work in basic functionality as expected. Then there may be some extra delays between soundcard IRQ is triggered, processed and new busmaster transaction will start. PCIe is known to use something like packeted transfer, optimized for larger layloads, bridges can add also some delays so it may happed DMA will not start fast enoug and sound buffer underrund - cause stuttering. I don't know, just thinking...
This is probably the most worrying aspect. However the IT8888 has specific features designed to handle the timing requirements of ISA DMA:
- Type-F DMA Timing: Section 6.8 states: "The IT8888F also supports Type F DMA timing. Each DMA channel can be programmed to operate in normal DMA timing or Type-F timing... Since the system memory is located on Host bridge chip (or PCI North Bridge), thus DMA cycles can be operated faster to achieve better ISA DMA performance." This shows the IT8888 was specifically designed to optimize DMA timing for modern systems where memory is accessed through the PCI bus rather than directly on the ISA bus.
- Delayed Transaction Support: From Section 6.1: "The IT8888F supports PCI 2.1 Delayed Transaction feature which can be enabled/disabled by programming Cfg_50h<1>. The benefit of Delayed Transaction is that the PCI bus is still available and can be used by other PCI master, even when there is an ISA PIO cycle in progress behind IT8888F." This ensures efficient bus utilization even during DMA operations.
- DDMA-Concurrent Mode: Section 6.10 explains: "To achieve PCI/ISA concurrency, there are some technologies to improve system performance: Delayed Transaction, Passive Release and the 'DDMA-Concurrent' in the IT8888F design... When enabled, the IT8888F will request PCI bus only when DDMA controller or ISA master issued a transaction to be forwarded to PCI bus, and the IT8888F will release PCI bus after it finished PCI bus cycle, even when the DDMA / ISA master still occupies ISA bus." This prevents the PCI bus from being held unnecessarily during DMA operations.
- ISA Bus Arbiter: Section 6.10 states: "The IT8888F internal ISA arbiter will handle and exclude DDMA cycle, Refresh cycle and PIO cycle from PCI bus to optimize the ISA bus utilization." This ensures efficient coordination between DMA requests, ISA bus usage, and PCI operations.
As for PCIe latency concerns, PCIe adds some packetization latency, but modern PCIe-to-PCI bridges (like PEX811x) are designed with timing-sensitive legacy compatibility in mind. The IT8888's Type-F DMA mode, delayed transactions, and DDMA-concurrent cycle handling help ensure timing remains acceptable even across a bridged PCIe connection. The IT8888 itself has safeguards to prevent issues too:
- Retry/Discard Timers: The documentation describes timeout mechanisms to prevent hanging when DMA operations can't complete in time.
- Built-in recovery mechanisms: The IT8888 can detect and handle situations where transactions are taking too long.
You've raised a bunch of good points and I'm glad someone is double checking!
RayeR wrote on 2025-04-24, 20:51:
BTW I wouldn't mess with QFN/PGA adapter and protoboard, I think that making a PCB in JLCPCB would cost you less... Just put enough testpoints and selection jumpers for signals you're not sure about...
The price for IT8888F is quite acceptable so it would worth to try...
I'll be honest, I'm a sucker for prototype cards. There's just something about prototype cards that is lost if it's just a PCB revision. This is the most complex electronics project I've ever considered and having a janky looking prototype card next to a pristine PCB in a frame would be a very nice physical representation of all the time and effort in. Something I can put on the wall and say, dang we actually did it or in the worst case, dang at least we tried.
