> >> 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot