Felix Radensky wrote:
Hello, Kenji-san
Kenji Kaneshige wrote:
I misunderstood the problem.
My understanding was memory resource was not enabled even though Linux
set
the Memory Space bit in the command register. But it was not correct. The
bridge memory window was marked unused and Linux didn't try to set Memory
Space bit in the command register. Current my understanding is as
follows.
Please correct me if I'm still misunderstanding something.
1) Your BIOS doesn't assign any resource to the bridge if its child PCI
hot-plug slot is not occupied.
2) At the boot time, pci_assign_unassigned_resources() try to assign
memory resouces to the bridge using pci_bus_assign_resource(), but
it was disabled because there are no devices require memory resource.
3) And then pci_assign_unassigned_resouces() calls pci_enable_bridge(),
but Memory Space bit in the command register was not set because no
memory resource are assigned to the bridge. At the same time,
pci_dev->enable_cnt was incremented.
4) At the rescan time, pci_setup_bridge() and pci_enable_bridge() doesn't
work because the bridge is already marked "enabled" (i.e.
pci_dev->enable_cnt is not zero).
I don't have any concrete idea how to fix that so far, but I can say
my idea
(pcibios_enable_device() should return an error) was wrong.
I was wandering if setting is_hotplug_bridge property for this bridge
(e.g. via
header quirk) can be an acceptable solution. This will allow passing
hpmemsize
kernel parameter, to specify the amount of memory to assign to the bridge.
I've tested this approach and it seems to work.
Looks good to me.
By the way, I think Yinghai's bridge resource reallocation patch series
might help you. It is in Jesse's PCI tree. Please take a look.
Thanks,
Kenji Kaneshige
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
