> The hard coding is done in i86pc/io/consplat.c, which > is worse. > > The new code does not do physical path hard coding. > > Wes
Does this mean that (Open)Solaris will no longer require an 8042-based keyboard & mouse when ACPI is switched off? Thanks Andrew. > > Garrett D'Amore wrote: > > In general, I like this project and would give it a > +1. I have only > > one concern: > > > > o Remove hard coded device path of legacy > input/output devices > > from consconfig_dacf module. For example, > replace the hard coded > > device path of legacy keyboard > "/isa/i8042 at 1,60/keyboard at 0" with > > the actual one > "/pci at 0,0/isa at 1f/i8042 at 1,60/keyboard at 0". > > > > > > I'm confused, where does this path exist? On my > particular system, > > the only references I see to i8042 devices in > /etc/dacf.conf are: > > > > # Devices directly supporting the keyboard API need > no device-specific > > module, > > # but do need to be linked to the console stream. > > # > > driver-minorname="mouse8042:internal_mouse" > consconfig_dacf:ms_config > > post-attach - pushmod="vuid3ps2" > > driver-minorname="mouse8042:internal_mouse" > consconfig_dacf:ms_config > > pre-detach - pushmod="vuid3ps2" > > > > > > If I'm reading this properly, it triggers based on > minor node name, > > and not on physical path. > > I would be cautious about hardcoding any physical > paths anywhere -- > > you'd have to be 100% certain that the physical > path was guaranteed to > > always be the same. > > > > If you don't hard code the physical path, then I'll > grant a +1. > > > > -- Garrett > > > > Jerry Gilliam wrote: > >> I am sponsoring the following case on behalf of > Judy Chen and > >> Wesley Shao as a fast-track, with timeout February > 5, 2009. > >> The project desires micro/patch binding. > >> > >> > >> > >> 1. Introduction > >> 1.1. Project/Component Working Name: > >> Remove /isa pseudo node for x86 > >> 1.2. Name of Document Author/Supplier: > >> Judy Chen > >> 1.3. Date of This Document: > >> 13 November, 2008 > >> > >> 4. Technical Description > >> > >> 4.1. Background > >> > >> The current Solaris x86 OS hard codes all ISA > (non-self identi- > >> fying) devices under /isa pseudo node. It has > the following > >> deficiencies: > >> > >> o It does not reflect the actual hardware > topology. > >> > >> o It does not allow ISA devices that are > capable of bus mastering > >> (including 1st-party and 3rd-party DMA) to > work correctly on > >> virtualization platforms. To be exact, the > Intel VT-d technology > >> provides DMA remapping hardware that > requires ISA DMA devices' > >> PCI ID (bus, device, and function numbers) > to be provided at > >> DMA mapping request time. Since ISA device's > parent is directly > >> under root, such PCI ID cannot be determined > by the DMA > >> implementation code. The previous Intel > IOMMU project > >> (PSARC/2008/560) worked around this by doing > handshakes via > >> global > >> variables. 3rd parties, in this case Intel, > won't be able to > >> provide a DDI compliant device driver. The > bus mastering capable > >> ISA devices that are supported by Solaris > include: > >> ecpp(7D): parallel port > >> fdc(7D) : floppy disk controller > >> pcn(7D) : AMD PCnet-ISA ethernet > controller > >> > >> o The Resource Allocator (RA), part of the > current DDI Hotplug > >> Framework project (PSARC/2008/181), needs to > maintain certain > >> PCI/ISA resources (memory/IO address space) > consistently. While > >> ISA devices are not under pci/isa hardware > node, RA project > >> would have to provide a separate set of code > and interface to > >> manage this disparity. > >> > >> 4.2. Proposal > >> > >> This project proposes to remove /isa > pseudo node and move ISA > >> devices under LPC/ISA bridge on x86 > platforms. The detailed changes > >> are listed as below. > >> > >> o Remove /isa pseudo node. Attach isa > driver with LPC/ISA > >> bridge > >> and as a result, move ISA devices' nodes > under pci/isa hardware > >> node. > >> > >> o Add below properties to pci/isa node > according to IEEE1275 > >> standard. > >> "device_type", "ranges" > >> > >> o Remove hard coded device path of legacy > input/output devices > >> from consconfig_dacf module. For example, > replace the hard coded > >> device path of legacy keyboard > "/isa/i8042 at 1,60/keyboard at 0" with > >> the actual one > "/pci at 0,0/isa at 1f/i8042 at 1,60/keyboard at 0". > >> o Remove the dependency to > /used-resources from > >> pci_autoconfig > >> module. > >> > >> Currently, the pseudo node > /used-resources is used to represent > >> ISA resources. The ISA resources include > memory/IO address spaces, > >> interrupts and DMA channels. /used-resouces > is created by ACPI > >> when ACPI enumerates ISA devices. It is used > by two modules: > >> > >> - pci_autoconfig: to setup memory/io > address spaces > >> available for > >> PCI bus. > >> > >> - busra: to setup resource map for > memory/io address spaces and > >> interrupts available for ISA bus. > >> > >> This project will represent the ISA memory/IO > address space with > >> standard "ranges" property of pci/isa > hardware node. And leave > >> busra the consumer of /used-resources. Once > the dependency between > >> busra and /used-resources is addressed by the > DDI Hotplug Framework > >> project, /used-resources can then be removed > for good. > >> > >> 4.3 Benefits > >> > >> o A proper parent-child relationship permits > allocation of the > >> ISA resources such as DMA and interrupts in > the context of > >> the system's PCI resources. > >> > >> o The current iommu implementation can be > simplified. > >> > >> o The ioapic interrupts can get a cleaner > implementation > >> as it evolves to support more complex > platforms. > >> > >> o The hotplug framework can manage a > hierarchical resource map. > >> > >> > >> 6. Resources and Schedule > >> > >> 6.4. Steering Committee requested information > >> 6.4.1. Consolidation C-team Name: ON > >> 6.5. ARC review type: FastTrack > >> 6.6. ARC Exposure: Open > >> > >> > > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org -- This message posted from opensolaris.org
