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 =

[off-list ref] wrote:

quoted

=20
On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
=20

quoted

=20
=20

quoted

-----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;

quoted

quoted

quoted

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

quoted

On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:

quoted

Hi kumar,
=20
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.

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

quoted

quoted

quoted

probe.

quoted

=20
Another possibility is to try to handle swiotlb init later -- =

possibly

quoted

quoted

quoted

quoted

by reserving memory for it if the platform indicates it's a =

possibility

quoted

quoted

quoted

quoted

that it will be needed, then freeing the memory if it's not =

needed.

quoted

quoted

quoted

quoted

=20
-Scott

=20
I think the first option seems reasonable.  Can we leave =

fsl_pci_init()

quoted

quoted

quoted

as we now have it and just have the platform driver deal with PM =

restore

quoted

quoted

quoted

via calling setup_pci_atmu() [probably need to update =

setup_pci_atmu to

quoted

quoted

quoted

handle restore case, but seems like minor changes]
=20
- k
=20

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

quoted

quoted

advantage. I really like to keep the completion of pci controller
platform driver not only for PM support but also for pci init.
=20
-Hongtao.
=20

=20
Shifting of swiotlb init has a lot more issues.  Why do we need to do =

the PCI init in probe?

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