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

[Jia Hongtao-B38951 <B38951@freescale.com>]

> -----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:
>=20
> > 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
>=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