mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-23 04:34:11 +08:00
22329b511a
This series of patches reworks the configuration and internal structure of the SGI IOC4 I/O controller device drivers. These changes are motivated by several factors: - The IOC4 chip PCI resources are of mixed use between functions (i.e. multiple functions are handled in the same address range, sometimes within the same register), muddling resource ownership and initialization issues. Centralizing this ownership in a core driver is desirable. - The IOC4 chip implements multiple functions (serial, IDE, others not yet implemented in the mainline kernel) but is not a multifunction PCI device. In order to properly handle device addition and removal as well as module insertion and deletion, an intermediary IOC4-specific driver layer is needed to handle these operations cleanly. - All IOC4 drivers are currently enabled by a single CONFIG value. As not all systems need all IOC4 functions, it is desireable to enable these drivers independently. - The current IOC4 core driver will trigger loading of all function-level drivers, as it makes direct calls to them. This situation should be reversed (i.e. function-level drivers cause loading of core driver) in order to maintain a clear and least-surprise driver loading model. - IOC4 hardware design necessitates some driver-level dependency on the PCI bus clock speed. Current code assumes a 66MHz bus, but the speed should be autodetected and appropriate compensation taken. This patch series effects the above changes by a newly and better designed IOC4 core driver with which the function-level drivers can register and deregister themselves upon module insertion/removal. By tracking these modules, device addition/removal is also handled properly. PCI resource management and ownership issues are centralized in this core driver, and IOC4-wide configuration actions such as bus speed detection are also handled in this core driver. This patch: The SGI IOC4 I/O controller chip implements multiple functions, though it is not a multi-function PCI device. Additionally, various PCI resources of the IOC4 are shared by multiple hardware functions, and thus resource ownership by driver is not clearly delineated. Due to the current driver design, all core and subordinate drivers must be loaded, or none, which is undesirable if not all IOC4 hardware features are being used. This patch reorganizes the IOC4 drivers so that the core driver provides a subdriver registration service. Through appropriate callbacks the subdrivers can now handle device addition and removal, as well as module insertion and deletion (though the IOC4 IDE driver requires further work before module deletion will work). The core driver now takes care of allocating PCI resources and data which must be shared between subdrivers, to clearly delineate module ownership of these items. Signed-off-by: Brent Casavant <bcasavan@sgi.com> Acked-by: Pat Gefre <pfg@sgi.com Acked-by: Jeremy Higdon <jeremy@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
46 lines
2.0 KiB
Plaintext
46 lines
2.0 KiB
Plaintext
The SGI IOC4 PCI device is a bit of a strange beast, so some notes on
|
|
it are in order.
|
|
|
|
First, even though the IOC4 performs multiple functions, such as an
|
|
IDE controller, a serial controller, a PS/2 keyboard/mouse controller,
|
|
and an external interrupt mechanism, it's not implemented as a
|
|
multifunction device. The consequence of this from a software
|
|
standpoint is that all these functions share a single IRQ, and
|
|
they can't all register to own the same PCI device ID. To make
|
|
matters a bit worse, some of the register blocks (and even registers
|
|
themselves) present in IOC4 are mixed-purpose between these several
|
|
functions, meaning that there's no clear "owning" device driver.
|
|
|
|
The solution is to organize the IOC4 driver into several independent
|
|
drivers, "ioc4", "sgiioc4", and "ioc4_serial". Note that there is no
|
|
PS/2 controller driver as this functionality has never been wired up
|
|
on a shipping IO card.
|
|
|
|
ioc4
|
|
====
|
|
This is the core (or shim) driver for IOC4. It is responsible for
|
|
initializing the basic functionality of the chip, and allocating
|
|
the PCI resources that are shared between the IOC4 functions.
|
|
|
|
This driver also provides registration functions that the other
|
|
IOC4 drivers can call to make their presence known. Each driver
|
|
needs to provide a probe and remove function, which are invoked
|
|
by the core driver at appropriate times. The interface of these
|
|
IOC4 function probe and remove operations isn't precisely the same
|
|
as PCI device probe and remove operations, but is logically the
|
|
same operation.
|
|
|
|
sgiioc4
|
|
=======
|
|
This is the IDE driver for IOC4. Its name isn't very descriptive
|
|
simply for historical reasons (it used to be the only IOC4 driver
|
|
component). There's not much to say about it other than it hooks
|
|
up to the ioc4 driver via the appropriate registration, probe, and
|
|
remove functions.
|
|
|
|
ioc4_serial
|
|
===========
|
|
This is the serial driver for IOC4. There's not much to say about it
|
|
other than it hooks up to the ioc4 driver via the appropriate registration,
|
|
probe, and remove functions.
|