Hi Marcel,
Thanks a lot for your feedback.
> I don't think we should try to place the MMCFGs before 4G even if there
> is enough room. Is better to place them always after 4G.
>
> "above_4g_mem" PCI hole it is reserved for PCI devices hotplug. We
cannot use if for
> MMCFGs. What I think we can do is to "move" the 64 bit PCI hole
after the MMCFGs.
> So the layout of over 4G space will be:
>
> [RAM hotplug][MMCFGs][PCI hotplug]...
OK, I will reorganize the memory layout. Should the number of MMCFG be
limited,
as there might be insufficient memory above 4G?
> Do you need the number of existing expander hosts? We have a
pxbdev_list, just query it.
Great, I think I missed that list.
> The above will need to change. We move the pci hole, not resize it.
> I am not sure this is the right place to handle it, maybe we add a
new property
> right beside pci_hole ones (extra-mmcfg?) and default it to 0.
That sounds good, so that we just need to check this range when setting
mcfg table instead of traversing the host bridge list.
> You cannot use the MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT as it is in use
> by the "main" root complex MMCFG. Actually I don't think we can come up
> with a valid default.
I see, I'll replcae it with unmapped then.
> Be aware this is used by both pxb and pxb-pcie devices, I think you
should split the type
>for each one and let the pxb's one as before.
OK, I had thought it would make codes simpler, as TYPE_PCIE_HOST_BRIDGE
is also the child of TYPE_PCI_HOST_BRIDGE, but I did forget about the pxb
devices. I'll split it in v2.