Reduced the diff to internal Root Complex only.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 24 2015
Jul 22 2015
Modified revision to sync with the Linux version of this quirk.
Jul 21 2015
Just tested on two ThunderX revisions (CRB and EVB) and works great. Please commit.
Forgot to include new BAR allocation, fixing it now. It should work even if all BARs (mem+msix+pba) are the same.
Jul 20 2015
Jul 17 2015
Jul 16 2015
Jul 15 2015
Andrew, I would love to change it in other places as well, but the interaction with so many maintainers will slow down this change and I don't have any mips/powerpc hardware to run tests on.
I have a proposal. Today I will prepare another patch with separate review removing KSTACK_PAGES from param.h in other archs and ask on the fbsd list for some help with testing on more exotic hardware, This allow submitting this to arm+arm64 while waiting for approvals from mips/sparc/x86/etc Will that work for you?
Thanks! That was really helpful. However I'm still confused about the system I have. I didn't powered up the full configuration yet, but I'm afraid it has two root pics then (one per each 48-cpu partition). Nevertheless, I'm abandoning this review for a while and stick to hacking generic_timer. When I test it on actual hw I will get back to this patch. However I'm still thinking the generic mask/unmask pair might be a useful feature.
Please give any feedback. We'd like to submit it next week if no other objections are reported.
I guess treating PPIs are separate IRQs number will cause a huge mess. I'm starting to port fbsd on 96 core armv8 platform and the idea of 1536 vectors wasted for PPIs is outrageous.
Jul 14 2015
Moved arm_unmask_irq here.
Jul 13 2015
Jul 12 2015
Any comments?
Any other issues except ARM64TOFO? If not, please accept this revision, I'd like to submit it soon.
Any comments?
Jul 9 2015
Jul 8 2015
I did notice it's cleaned up (and it's got the annoying DO_AST printf changed to ktr). However, the places where I expect merge conflicts are the same. We had to change stack calculation, sequence in init_secondary, fix the KSTACK_PAGES variable (it does not correspond to the one set in kernconf here)... these are the one from the top of my head.
I'm good with this patch, please commit.
That would be great if you could commit this patch "as is". We have few fixes to mp_machdep/locore which are currently rebased against your version. Avoiding merges of post-review fixes will let us save a lot of time...
I will send all our patches once it's pushed. Thanks in advance.
How does MIPS have PCI bus then? Or should that first line be 'option acpi'?
In D3008#59529, @andrew wrote:You haven't listed any problems that can't be fixed in GENERIC. It would help if you could tell me the specific problems you are trying to solve and why you couldn't use, for example, quirks to solve them.
Added MSI-x table and PBA BAR number resolving in generic way, as per PCIe specification.
We will not be able to make it generic until the issue with PCI compilation is resolved. Maybe I didn't specified it clearly enough, but in the present FreeBSD state we need to have a separate config files. If you think we can live with fbsd without any IO interfaces working on the real hardware, then we can definitely stick to GENERIC. Keep in mind, that configuring pci in GENERIC does not cope well with an acpi option and makes the compilation fail...
I'd really like to have this change pushed as an enabler for all further ThunderX support. It is only a temporary and will be removed as soon as is no longer necessary.
Made it MD.
Regarding mb(), I was expecting a discussion rather to use stronger one, not finer-grained. Here we need to guarantee that mb is valid for every domain (inner+outter shareable) , thus use a full-system one. I was wondering, however, if the dsb() is not more appropriate. Mostly because of scenario what if we're syncing a buffer containing executable code which we jumps to. In that case mb might not be sufficient. I did not find any such place in the kernel, so decided to use less impacting mb instead.
Moved some options which will be necessary in the future from THUNDER-88XX to GENERIC. Cleaned up Thunder kenrconf and left only absolutely necessary options.
Jul 7 2015
Sure. However, I'd like to use a negative logic here. I mean, to use mb as a default and disable it for a known list of architectures (afaik only Intel/amd64 don't need a barrier here).
Yes, you're absolutely right. Fixed the logic to avoid allocation for both msix and msi.
We are trying to upstream support for ThunderX armv8 system. The producer decided to support only MSI-x for all internal interfaces, including AHCI.