* Jan Kiszka <jan.kis...@siemens.com> [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. [...] > > 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. > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux -- Gustavo Lima Chaves Intel - Open Source Technology Center -- 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 jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
