As long as the device driver is only used for device enumeration (PCI config space access), I think we can safely use one driver as these parts seem to be identical.
If we decide to implement some more advanced features (like resource distribution, power-management, bus control,...) it would be better if we used separate drivers. MPC106 was described as implementing a superset of standard PCI features, but I did not investigate the differences. j.v. Parts of MPC106 manual, relevant to current implementation: "3.1 Address Maps The MPC106 supports three address mapping configurations designated address map A, address map B, and emulation mode map. Address map A conforms to the PowerPC reference platform specification. Address map B conforms to the PowerPC microprocessor common hardware reference platform (CHRP). The emulation mode map is provided to support software emulation of x86 hardware. The configuration signal DBG0, sampled during power-on reset, selects between address map A and address map B. Map A is selected by using a pull-up resistor (DBG0 = 1); map B is selected by using a pull-down resistor (DBG0 = 0). After reset, the address map can be changed by programming PICR1[ADDRESS_MAP]." Looks like the address map B is the default. "3.2.1 Configuration Register Access ... When using address map B or emulation mode address map, ... CONFIG_ADDR at any word-aligned address in the range 0xFEC0_0000–0xFEDF_FFFF. Every word within this range is aliased to the same location. Then, the data is accessed at CONFIG_DAT at any address in the range 0xFEE0_0000–0xFEEF_FFFF. Every word within this range is aliased to the same location." These are the hardcoded addresses. "3.2.1.2 Configuration Register Access in Big-Endian Mode In big-endian mode (both the processor and the MPC106), software must byte-swap the data of the configuration register before performing an access. That is, the data appears in the processor register in ascending significance byte order (LSB to MSB). When using either address map (A, B, or emulation mode), software loads the configuration register address and the configuration register data into the processor register in ascending significance byte order (LSB to MSB)." 3.2.2 describes configuration space in identical manner to intel pci. (I think this is required by PCI spec, did not check) On Tue, Jan 24, 2012 at 4:30 AM, Jakub Jermar <[email protected]> wrote: > On 24.1.2012 6:00, Ján Veselý wrote: >>> - making USB work on ppc32, WIP, almost there >> >> ppc32 PCI driver is available in my usb branch, it's a slightly >> modified intelpci driver (endianess, port locations), I'll add the >> OHCI bits later. > > Is the PCI bridge just similar or is it essentially the same thing? If > it is physically the same or compatible thing, we should probably > consider options for using the same driver for it. > > You mention the difference in register layout. This could be either > because the device is indeed incompatible or because of some platform > specifics. > > For example, on ia64, there is a legacy I/O space, which replaces the > ia32/amd64oe IO port space. It ds so by mapping groups of four > consecutive I/O ports to a page in the legacy I/O space. Consecutive > groups of ports will lie in consecutive pages. The original ia32 I/O > port space is thus inflated from 64KiB to 64MiB. > > If one sees the legacy I/O space as ordinary memory mapped registers, it > may happen that some registers that are adjacent in the ia32 I/O port > space will not be adjacent in the ia64 legacy I/O space. > > The problem goes away if you continue to look at the registers in the > legacy I/O space as if they were still special, much like the original > ia32 I/O ports. You can then map port numbers to respective memory > mapped registers and vice versa and, theoretically, use unmodified > driver for both. > > Just being curious :-) > > Jakub > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
