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: Tuesday, July 31, 2012 9:38 PM
> To: Li Yang-R58472
> Cc: Jia Hongtao-B38951; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> Li Yang-R58472
> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> initialization code
>=20
>=20
> On Jul 31, 2012, at 2:21 AM, Li Yang wrote:
>=20
> > On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala <galak@kernel.crashing.org=
>
> wrote:
> >>
> >> On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
> >>
> >>>
> >>>
> >>>> -----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
> >>>>
> >>>>
> >>>> 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?
> >
> > The ordering issues are introduced by swiotlb.  And the ideal way is
> > to solve the problem within swiotlb instead of changing PCI to
> > workaround it.  Take the implementation of x86 as reference it's
> > possible to be addressed bu allocating first and free later approach.
> >
> > It is common sense that the initialization of a device is in the probe
> > function of the driver of the device.  And the change will provide
> > better unification of PCI controller code.  The PCI controller is
> > generic enough not to be taken care of at the platform area.
> >
> > Leo
>=20
> Than lets look at going with that approach.. Be careful with impact on
> other users of swiotlb on PPC, I believe one 44x board uses swiotlb.
>=20
> - k

I will be careful with this approach.
I have already noticed 44x. Thank you all the same.

-Hongtao.