RE: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code
flat view
From: Jia Hongtao-B38951 <hidden>
Date: 2012-07-30 08:26:51
-----Original Message----- From: Kumar Gala [mailto:galak@kernel.crashing.org] Sent: Saturday, July 28, 2012 5:17 AM To: Wood Scott-B07421 Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472 Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code =20 =20 On Jul 27, 2012, at 3:24 PM, Scott Wood wrote: =20quoted
On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:quoted
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 beforeprobe.quoted
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=20 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] =20 - k =20
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.=20