Re: very minor 405GP and 405GPr PCI difference
From: Matt Porter <hidden>
Date: 2002-10-03 15:14:39
On Thu, Oct 03, 2002 at 11:10:44AM +1000, David Gibson wrote:
On Wed, Oct 02, 2002 at 10:03:12AM -0700, Matt Porter wrote:quoted
That's exactly the problem. If your world is filled with the standard IBM reference platforms then a simple single host PCI bridge in "CHRP-style" mapping probably seems reasonable. In reality, it's necessary to design PCI host bridge library code such that it can be called in a board-specific way to allow for window mappings in "wacky" systems with 2 or more PCI connected processors. This is very common.Ok, I can see why you'd want a different PCI mapping for that. For boards like this, would it be sufficient for the generic code to set up PMM0 and PTM1 with the standard mapping, then let the board code use the remaining PMMs and PTMs for additional mappings?
In my book, that removes flexibility which is something I'm a big believer in when it comes to embedded stuffs. I'd prefer to have something like: ibm_pci_init(<default_or_custom_map_flag>, <window_struct_ptr>) If you want the default CHRP map you call like this: ibm_pci_init(IBM_PCI_DEFAULT_MAP, NULL); If you want a custom map you fill out a window reg struct and do: ibm_pci_init(IBM_PCI_CUSTOM_MAP, &my_win_struct); The implementation of the init function can be as simple as just taking the values of the custom win struct and programming verbatim into the PMMs and PTMs, or eventually one can get fancy and provide a little more abstraction where one could pass window start/end values and the code would do some range checking a la pplus_common.c. Since there's such an incredible amount of cleanup work to do for 4xx, I think a bare bones back end implementation is more than sufficient. I should provide an example of this for the 440gp/gx pcix logic, but having 440 stable seemed a bit more important first. :)
quoted
This is where the current flow of having a common thread of excecution falls apart (ppc4xx_setup). 40x really should be following the model of the embedded 7xx/74xx system where each <board>.c would call to a PCI library with some parameters to set up a desired set of window mappings. It's possible to have a default common case to set up a CHRP-like mapping.I agree absolutely. The current flow of control of the board stuff is a ghastly horrible mess.
Aha! Good.
quoted
We've had some threads in the past about the limitations of using this "common flow" design in 4xx. I believe there was some agreement that it is a limiting way to do things. I do recall that Dan said it was only this way because he copied the 826x flow and it probably didn't make sense anymore for 4xx. If there's no serious objections I'm suggesting that this is where we go in the 2.5 4xx reorg.Quite. In fact I recall suggesting a re-org along these lines some time ago, but then I got busy and didn't have time to actually send patches. I seem to recall there was some resistance to such a re-org at the time.
Hrm, I will have to reread some of threads I saved. I only recalled some agreement from Dan that it probably didn't make sense any longer and a tangential issue regarding the desire to build a single image with multiple 4xx targets. Something that I, incidentally, believe is a waste of time since kernels can be built so quickly. Regards, -- Matt Porter porter@cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/