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

[Kumar Gala]

On Oct 29, 2008, at 10:05 AM, Peter Tyser wrote:

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

perfect.

- k