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