Re: [PATCH 3/4] PCI: designware: remove pci_assign_unassigned_resources call

[Murali Karicheri <m-karicheri2@ti.com>]

On 08/17/2014 02:20 AM, Pratyush Anand wrote:
> On Sun, Aug 17, 2014 at 8:29 AM, Yinghai Lu<yinghai@kernel.org>  wrote:
>> On Sat, Aug 16, 2014 at 6:13 AM, Pratyush Anand
>> <pratyush.anand@gmail.com>  wrote:
>>> On Wed, Jul 23, 2014 at 11:22 PM, Lucas Stach<l.stach@pengutronix.de>  wrote:
>>>
>>> I am not sure here. IIRC, then calling  pci_assign_unassigned_resources after
>>> pci_common_init_dev was needed to handle few PCIe cards with EP behind
>>> bridge.
>>>
>>> I do not have good understanding of pci resource allocation code.
>>> @Yinghai: Can you please help(rather teach) with the description of
>>> different resource allocator
>>> available in setup-bus.c. Can try reading code, but if a documentation
>>> exists, that would
>>> be helpful.
>>
>> pci_assign_unassigned_resources() should try several times to make sure
>> assign resource to PCI bars that are not assigned by BIOS or not valid value
>> from BIOS.
>> so it will honor the setting from BIOS.
>>
>> in your arm case, pci_common_init_dev() is doing sizing and assign.
>> so you should not need that pci_assign_unassigned_resources() anymore.
>>
>> Or your setup have PCI_PROBE_ONLY ?
>
> Thanks for the clarification.
>
> I think none of the designware based platform boots with *firmware*, so none of
> the setup should have PCI_PROBE_ONLY. Then patch seems fine.
>
There are customers using Keystone platform on which u-boot sets up BAR 
and use firmware option to honor BAR assignment done by the boot loader. 
How does this change that use case? If this still works with this 
change, no issues. If not, I would suggest this shouldn't be removed. 
Any expert here who can comment on this? Keystone driver is just getting 
merged to upstream branch and is based on designware.

Murali
> ~Pratyush
>
>>
>> Yinghai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html