On 2018-01-25 23:52, Gustavo Lima Chaves wrote: > * Jan Kiszka <[email protected]> [2018-01-24 07:12:37 +0100]: > > [...] > >>>> >>>> - use FLR where available >>>> - warn if it's not >>>> - unconditionally clear the command register and try to set INTx-off >>> >>> OK. Naming them 1, 2 and 3, I just can't do 3 when FLR is not >>> available: it is an unsupported request. >>> >> >> The command register is present in every PCI device. Therefore, 3 is >> independent of FLR or PCIe support. > > OK, back to (more) testing mode on this front, hold on and I'll come > back with something, I hope. > > [...] > >>> Do you mean PIO instructions? We're looking at accesses to >>> PCI_CAP_PCIE | JAILHOUSE_PCI_EXT_CAP cap, that can only live on the >>> mmio space, no? So we got pristine loads and stores, thus the "normal" >>> cycle count. I'll assume that cycle amount and use current CPU freq. >>> as an estimate, I guess. >> >> Memory mapped I/O can delay the triggering instruction if the device is >> not confirming the transaction / delivering the data requested on read. >> You will not measure cache speed here when you try define the loop delay >> - believe me, or better try it out. > > OK, my bad ignoring stalls on those MMIO-mapped accesses, you're > right. I just don't buy the "find some constants that get near 100ms > for *some CPU/chipset/PCI device* you judge modern enough" and make > that the default cycle count. How is that any better than my approach > of guaranteeing *at least* 100ms on modern IA CPUs (any extra coming > from PCI access delays), being that the spec allows for > 100ms waits > and that would work for a lot more people without even having to tune? > My next commit would derive the CPU frequency from /sys and we'd have > sane values for everyone automatically.
I'm pretty sure the loop delay will be dominated by the PCI access, not some CPU clock speed. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
