> -----Original Message----- > From: Kumar Gala [mailto:ga...@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 > > > On Jul 31, 2012, at 2:21 AM, Li Yang wrote: > > > On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala <ga...@kernel.crashing.org> > wrote: > >> > >> 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? > > > > 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 > > 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. > > - k
I will be careful with this approach. I have already noticed 44x. Thank you all the same. -Hongtao. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
