On 2018-01-23 22:24, Gustavo Lima Chaves wrote: > * Jan Kiszka <[email protected]> [2018-01-23 08:52:39 +0100]: > > [...] > >>> >>> OK. But now that you mention support for non-pcie devices, below, I >>> guess we'll have to do something in the lines Linux does >>> (__pci_reset_function_locked())? It checks for a (ancient?) >>> conventional PCI capability for non-pcie devices and acts on it: >>> Advanced Features >>> (https://pcisig.com/sites/default/files/specification_documents/ECN_Conventional_Adv_Caps_27Jul06.pdf). >>> I guess this might be a more correc way of acting on conventional >>> ones, since pci_disable_device() (writing zeros to the command >>> register, like we did in JH previously) seems unrelated to FLR (and >>> the conventional PCI specs are not dictating any form of FLR receipt >>> on the base text as well, just on that addendum). What do we do, ugh? >> >> Simply what I suggested: >> >> - 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. > [...] > >>> loop we get roughly 100 cycles, maximum. >>> >>> So what do we do for a default? This is hard enough to estimate >>> already considering caching times, parallel execution, etc. Do we >>> take, say, 1.2GHz as a reasonable average CPU clock and make the >>> constant 1200000 to make that take 100ms (quick math here, there could >>> be mistakes)? >> >> Doesn't the PCI config access give us some more or less stable delay >> that is much longer that the individual instruction cycles? Try to >> measure that across some recent platforms, then derive from the fastest, >> I would say. > > 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. 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.
