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

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

quoted

On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala <galak@kernel.crashing.org=

wrote:

quoted

quoted

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

quoted

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

quoted

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:

quoted

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

quoted

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

quoted

quoted

quoted

quoted

probe.

quoted

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

possibly

quoted

quoted

quoted

quoted

quoted

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

possibility

quoted

quoted

quoted

quoted

quoted

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()

quoted

quoted

quoted

quoted

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

restore

quoted

quoted

quoted

quoted

via calling setup_pci_atmu() [probably need to update setup_pci_atmu

to

quoted

quoted

quoted

quoted

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

quoted

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.

-Hongtao.

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

the PCI init in probe?

quoted

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.