On Tue, Oct 31, 2023, at 22:41, Jiaxun Yang wrote: > Hi all, > > I'm trying to improve Kernel's support of devices that have ioports > mapped into MMIO, that involves converting existing driver which is > using {in,out}{l,w,b} to use io{read,write}{8,16,32,64}, so they can > benefit from ioport_map and pci_iomap. > > However, the problem is io{read,write}{8,16,32,64} will incur penalty > on x86 by introducing extra function calls (they are not inlined) and > having extra condition judgment on MMIO vs PIO. > > x86 folks, do you think this kind of overhead is acceptable? I do think > most of PCI/ISA drivers will need to be converted. > > linux-arch folks, do you think it will be better if we introduce a > variant of io{read,write}{8,16,32,64} that direct to PIO on x86 but > remains the same functionality on other architectures? I think in general there is not much of a problem here since the inb()/outb() operations themselves are extremely slow already, in particular the outb() writes are non-posted unlike writeb(). My feeling is that converting to ioread/iowrite is generally a win for any driver that already needs to support both cases (e.g. serial-8250) since this can unify the two code paths. However, for drivers that only support inb()/outb() today, I don't see a real benefit in converting them from the traditional methods. Another question is whether we actually want to keep the ISA-only drivers around. Usually once you look closely, any particular ISA driver tends to be entirely unused already and can be removed, aside from a few known devices that are either soldered-down on motherboards or that have an LPC variant using the same ISA driver. Arnd