On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote: > > >> -----Original Message----- >> From: Kumar Gala [mailto:ga...@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 >> >> >> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
