[U-Boot] [PATCH v2] pci/fsl_pci_init: Enable inbound PCI config cycles

[Peter Tyser <ptyser@xes-inc.com>]

> >> Shouldn't we only be doing this for an agent?  Also is the right  
> >> place to enable it?  Just wondering if board code should have more  
> >> flexibility here.
> >
> > I was under the impression that if a PCIe interface was configured  
> > as root complex its CFG_READY bit would still need to be set in  
> > order for an endpoint device to perform config cycles to it (eg to  
> > see if the root complex device was sharing its memory, or if the  
> > root complex's shared memory was prefetchable, etc).  So I thought  
> > it made sense to unconditionally set the CFG_READY bit for PCIe  
> > interfaces.  Let me know if I'm missing something here (I thought  
> > some non-fsl chips could generate config cycles in endpoint mode)...
> 
> No Freescale part that I'm aware of (ppc based) has ever allowed  
> inbound config cycles if the device is in host mode/root complex.

Alright.

> > Looking at section 4.4.3.6 of the MPC8548 manual I thought that the  
> > ACL bit could be set on a host interface based on the value of the  
> > cfg_cpu_boot reset configuration bit.  Looking over the manual a bit  
> > more closely, it looks like if a PCI interface is configured as host  
> > it can't respond to inbound config cycles period (Table 16-65 of the  
> > 8548 manual).  So for PCI hosts, ACL does not need to be cleared as  
> > you suggested.
> >
> > As far as having more flexibility, I couldn't think of a reason that  
> > boards would want to have more fine grained control of this.  Is  
> > there an example you can think of where a board would want to do it  
> > differently?
> 
> Its a timing issue if we are talking about using this for "agent"  
> support.  The idea is once any cpu local software has run and setup  
> things than it sets the ACL bit to allow an external master access.   
> Its not clear when that point might be as we can't predicate what the  
> local CPU SW wants setup before allowing access.

It seems like 99% of the users could do any custom configuration of
inbound windows between the calls to fsl_pci_setup_inbound_windows() and
fsl_pci_init() in pci_init_board().  If its a concern I can pull the
configuration unlocking into a separate function to to allow for odd
situations.  That would allow a board to call it at any point in the
boot process (eg last_stage_init()).

> If you are only running your devices/boards in host mode this patch is  
> not needed.

Most of our Freescale boards require this change as they are PMCs, XMCs,
cPCI, etc boards which can be configured as host/agent/root
complex/endpoint dynamically depending on a carrier card, chassis, etc.
We also have a card with 2 Freescale CPUs connected via PCIe which
requires the change.

How about I pull the changes into a separate function and add checks to
ensure the the interface is host before allowing inbound config cycles?
I'd only add a call to the new function to the two boards I recently
added support for (assuming they are accepted:) and leave it to other
boards to add a call to it if they need it. 

Thanks,
Peter