[PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code

[Kumar Gala]

On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:

> 
> 
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>> Sent: Saturday, July 28, 2012 5:17 AM
>> To: Wood Scott-B07421
>> Cc: Jia Hongtao-B38951; linuxppc-dev at lists.ozlabs.org; Wood Scott-B07421;
>> Li Yang-R58472
>> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
>> initialization code
>> 
>> 
>> On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
>> 
>>> On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
>>>> Hi kumar,
>>>> 
>>>> I know "duplicate code from pci_process_bridge_OF_ranges()" is
>>>> hard to accept but "refactor the code to have a shared function"
>>>> is knotty. Actually this is the reason I didn't do the refactor.
>>> 
>>> Maybe we should keep doing the init early?  We could still have a
>>> platform device for the PM stuff, but some init would be done before
>> probe.
>>> 
>>> Another possibility is to try to handle swiotlb init later -- possibly
>>> by reserving memory for it if the platform indicates it's a possibility
>>> that it will be needed, then freeing the memory if it's not needed.
>>> 
>>> -Scott
>> 
>> I think the first option seems reasonable.  Can we leave fsl_pci_init()
>> as we now have it and just have the platform driver deal with PM restore
>> via calling setup_pci_atmu() [probably need to update setup_pci_atmu to
>> handle restore case, but seems like minor changes]
>> 
>> - k
>> 
> 
> 
> I think the second option is better if it's hard to decouple swiotlb
> determination from pci init. I believe the better architecture that
> PCI init in probe function of platform driver will bring us considerable
> advantage. I really like to keep the completion of pci controller
> platform driver not only for PM support but also for pci init.
> 
> -Hongtao. 
> 

Shifting of swiotlb init has a lot more issues.  Why do we need to do the PCI init in probe?

- k