Thanks this was interesting learning. On Sun, Jun 27, 2021 at 9:41 AM Maciej W. Rozycki via cctalk < cctalk@classiccmp.org> wrote:
> On Sun, 27 Jun 2021, Paul Koning wrote: > > > > However both serial and parallel ports remain reasonably available as > > > PCIe option devices. Though parallel ports seem to be made as legacy > PCIe > > > devices only, that is accessed with I/O rather than memory read/write > bus > > > cycles, which are not, as I have learnt the hard way recently, > supported > > > by all computer systems nowadays. I guess x86 systems will continue > to > > > support them however as x86 CPUs have native I/O access instructions. > > > > I/O cycles on PCI have no direct connection to I/O instructions. I've > > routinely used I/O operations in PCI on a MIPS platform, which of course > > has no such concept; all that was needed is to send the memory cycles to > > the address block that the PCI bridge maps onto I/O cycles rather than > > memory cycles. > > That's not my point. The host bridge has to implement them and some do > not (e.g. the POWER9 PHB4). For CPU architectures that do not have native > I/O cycle support an MMIO window has to be defined by the host bridge for > memory cycles decoded within that window to be forwarded downstream as > PCIe I/O Read/Write TLPs (likewise with legacy PCI I/O Read/Write > cycles). > If you don't define such a window along with associated circuitry (like > with the PHB4), then there's simply no way to produce I/O TLPs on PCIe. > > When you have a CPU architecture such as x86 that does do I/O cycles > natively, then they're just forwarded by the host bridge as PCIe I/O > Read/Write TLPs. Of course one can envisage an x86 host bridge that won't > forward I/O cycles produced by the CPU to PCIe and will either terminate > them with a bus error or let them time out, but I find it highly > unlikely. > For one I suspect the circuitry required to terminate unclaimed host bus > I/O cycles is no less expensive than one to just forward them downstream; > after all a PCIe I/O TLP is told apart from a memory TLP merely by a > difference in a bit pattern sent downstream that encodes the cycle type, > one of several (likewise with PCI cycles). > > NB PCIe I/O Read/Write TLPs have been deprecated ever since the first > revision of the PCIe specification and PCIe devices that do require I/O > TLPs for operation have always been referred to as legacy PCIe devices. > I guess support for such devices has been added to the specification so as > to aid the industry with switching entirely to the MMIO operating model, > with initial PCIe devices expected to be implemented by placing the > original PCI/PCI-X ASIC behind a PCIe-to-PCI bridge, until new PCIe ASICs > have been made. For some option cards it seems the only way to date, e.g. > PCIe ATM network adapters. > > As it has turned out actual PCIe ASICs have been manufactured that do > require I/O Read/Write TLPs for their operation such as said IEEE 1284 > parallel ports. It's not actually clear to me why, but a plausible > explanation is they have been considered too niche at that point for the > effort required for the OS drivers to be updated. > > Maciej >
