in the various pci specifications as readonly. vendor, subvendor,
device and subdevice are required to be loaded in hardware by some
means that isn't the system BIOS or other system software (although
some devices do have ways of accomplishing this). class and subclass
are defined to be read-only in section 6.2.1 (v2.2). Apart from the
status register, which we weren't touching, these are the only
read-only registers I could find in the 2.2 spec.
progif is also defined as being read-only in section 6.2.1. However,
the PCI IDE programming document specifically states that some of the
bits are read/write. Since we may have to restore registers before we
have a driver attached, go ahead and restore this one byte when
transitioning between D3 and D0.
The PCI spec also says that writes to reserved and unimplemented
registers must be completed normally. It makes no statements about
writes to read-only registers, so be as conservative as possible,
while covering the exception to the rule that is documented in a
subpart of the standard.
Requested by: socttl
Split the baby. For idepci devices, now both legacy mode bits need
not be set. We can run an idepci in a split mode. However, it only
works better than before, not works. It works better in that when one
device is legacy and the other isn't and disabled, we now operate
correctly.
sos submitted a version of this patch.
subclass, progif and revid. While these are typically read
only fields, they aren't always read-only. progif is writable
for ata devices, for example. It does no harm when they are
read only, and helps when they aren't.
chattiness was left in for debugging, but now that nearly all of the
problems relating to the changes have been fixed, it is only annoying. It
is still available via bootverbose.
Prodded by: jhb
1) In pci.c, we need to check the child device's state, not the parent
device's state.
2) In acpi_pci.c, we have to run the power state change after the acpi
method when the old_state is > new state, not the other way around.
Submitted by: Dmitry Remesov
PR: 65694
resource pre-allocation. The problem is that the BARs of the EBus bridges
contain the ranges for the resources for the EBus devices beyond the bridge.
So when the EBus code tries to allocate the resource for an EBus device
it's already allocated by the PCI code.
To be removed again as soon as we have a proper solution in the EBus Code.
Reviewed by: tmm
Approved by: marcel (mentor)
While I would have prefered to have a solution that didn't move
knowledge of this into the pci layer. However, this is literally the
only exception that's listed in the PCI standard to the usual way of
decoding BARs. atapci devices in legacy mode now ignore the first 4
bars and hard code the values to the legacy ide values (well, for each
of the controllers that are in legacy mode). The 5th bar is handled
normally.
Remove the zero bar handling. zero bars should be ignored at all
other times, and since we handle that specially, we don't need the
older workaround.
the sense that any write to them reads back as a 0. This presents a
problem to our resource allocation scheme. If we encounter such vars,
the code now treats them as special, allowing any allocation against
them to succeed. I've not seen anything in the standard to clearify
what host software should do when it encounters these sorts of BARs.
Also cleaned up some output while I'm here and add commmented out
bootverbose lines until I'm ready to reduce the verbosity of boot
messages.
This gets a number of south bridges and ata controllers made mostly by
VIA, AMD and nVidia working again. Thanks to Soren Schmidt for his
help in coming up with this patch.
we get the resource allocation stuff hammered out.
Fix and off by one error that caused unnecessary filtering of valid
BARs for only 4 bytes than ICH3 and other PCI IDE controllers have.
Andrew Gallatin submitted this, although it doesn't solve the problems
ICH3 controllers have with the new code, it does restore the former
resource list on the probe line.
device in D0 to D0, that's a no-op, however the messages seem to be
confusing some people. Eventually, these messages will be parked
behind a if (bootverbose).
# I don't think this will fix any real bugs...
o Save and restore bars for suspend/resume as well as for D3->D0
transitions.
o preallocate resources that the PCI devices use to avoid resource
conflicts
o lazy allocation of resources not allocated by the BIOS.
o set unattached drivers to state D3. Set power state to D0
before probe/attach. Right now there's two special cases
for this (display and memory devices) that need work in other
areas of the tree.
Please report any bugs to me.
- This is heavily derived from John Baldwin's apic/pci cleanup on i386.
- I have completely rewritten or drastically cleaned up some other parts.
(in particular, bootstrap)
- This is still a WIP. It seems that there are some highly bogus bioses
on nVidia nForce3-150 boards. I can't stress how broken these boards
are. I have a workaround in mind, but right now the Asus SK8N is broken.
The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed.
- Most of my testing has been with SCHED_ULE. SCHED_4BSD works.
- the apic and acpi components are 'standard'.
- If you have an nVidia nForce3-150 board, you are stuck with 'device
atpic' in addition, because they somehow managed to forget to connect the
8254 timer to the apic, even though its in the same silicon! ARGH!
This directly violates the ACPI spec.
- Add a new PCIM_HDRTYPE constant for the field in PCIR_HDRTYPE that holds
the header type.
- Replace several magic numbers with appropriate constants for the header
type register and a couple of PCI_FUNCMAX.
- Merge to amd64 the fix to the i386 bridge code to skip devices with
unknown header types.
Requested by: imp (1, 2)
interrupt to be used for a device. This is intended solely for internal
use of PCI bus implementations, and exists so that PCI bus drivers
implementing special interrupt assignment methods which require
additional work at the bus level to work right can be easily derived
from the generic driver (or any other one) without resorting to hacks.
It will be used in the sparc64 ofw_pcibus driver, which will be
committed shortly.
Make use of this method in the generic implementation, and add it to
the method table of bus drivers derived from the PCI one.
Reviewed by: imp, -hackers
are some Sun PCI devices around which bogusly set intpin to 0, although
they use the intline mechanism; this allows the device driver to correct
that.
Reviewed by: imp
Reorder how the pci probing in handled. before adding devices, check to
see if the slot is a multi-function device to see if we should probe all
the functions.
Original idea by: imp
ia64-specific.
- When trying to re-route interrupts, don't change cfg->intline if the
re-route fails by returning an invalid vector. This fixes machines
without any way of routing interrupts such as older PC's without a
$PIR table.
We do not currently write the new intline value back to the hardware, but
we should. That will likely be added in a later commit.
Always route PCI interrupts on i386 UP machines. I was planning to enable
this for i386 anyways once SMP support is done. Having this enabled fixes
problems on many people's laptops.
Requested by: imp
command config register. At the present, this represents a nop
because these bits should have been set earlier in the process. In
the future, we'll only set these bits when the driver requests the
resource, not when the bus code detects the resource.
Reviewed by: mdodd
pci busses implement this.
Also minor comment smithing in cardbus. Fix copyright to this year
with my name on it since I've been doing a lot to this file.
Reviewed by: jhb
buses support querying the MAC address in a standard-for-that-bus way.
The base pci bus returns NULL for this IVAR always.
Submitted by: sam
Approved by: re (blanket for NEWCARD)
supported option and it disabled a whole 2 lines of bootverbose messages.
I wanted to see 1 of the messages (about the latency timers). This
is a wrong place to decode pci configurations, but the code is already
here and handles more details than pciconf(8).
when the first PCI bus attaches.
- Create /dev/pci during MOD_LOAD as well.
- Destroy /dev/pci during MOD_UNLOAD (not that you can kldunload pci, but
might as well get the code right)
- Add an ACPI PCI-PCI bridge driver (the previous driver just handled
Host-PCI bridges) that is a PCI driver that is a subclass of the generic
PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and
pci_route_interrupt.
- The probe routine only succeeds if our parent is an ACPI PCI bus which
we test for by seeing if we can read our ACPI_HANDLE as an ivar.
- The attach routine saves a copy of our handle and calls the new
acpi_pcib_attach_common() function described below.
- The read_ivar routine handles normal PCI-PCI bridge ivars and adds an
ivar to return the ACPI_HANDLE of the bus this bridge represents.
- The route_interrupt routine fetches the _PRT (PCI Interrupt Routing
Table) from the bridge device's softc and passes it off to
acpi_pcib_route_interrupt() to route the interrupt.
- Split the old ACPI Host-PCI bridge driver into two pieces. Part of
the attach routine and most of the route_interrupt routine remain in
acpi_pcib.c and are shared by both ACPI PCI bridge drivers.
- The attach routine verifies the PCI bridge is present, reads in
the _PRT for the bridge, and attaches the child PCI bus.
- The route_interrupt routine uses the passed in _PRT to route a PCI
interrupt.
The rest of the driver is the ACPI Host-PCI bridge specific bits that
live in acpi_pcib_acpi.c.
- We no longer duplicate pcib_maxslots but use it directly.
- The driver now uses the pcib devclass instead of its own devclass.
This means that PCI busses are now only children of pcib devices.
- Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar
of the child bus.
- Fetch the _PRT for routing PCI interrupts directly from our softc
instead of walking the devclass to find ourself and then fetch our
own softc.
With this change and the new ACPI PCI bus driver, ACPI can now properly
route interrupts for devices behind PCI-PCI bridges. That is, the
Itanium2 with like 10 PCI busses can now boot ok and route all the PCI
interrupts. Hopefully this will also fix problems people are having with
CardBus bridges behind PCI-PCI bridges not properly routing interrupts
when ACPI is used.
Tested on: i386, ia64
- Make the pci devclass a global variable.
- Add child devices in pci_attach() instead of pci_probe(). Change
pci_probe() to just check for a valid bus number from the associated
bridge and return -1000 if successful. This allows subclasses of the
PCI bus driver to override the generic driver.
- Move the code to load the vendor data into its own public function.
Really though, doing this at attach is just plain wrong. This should
really be done in the module load routine instead. As a side effect,
the 'busno' variable in pci_attach() is now no longer static (minor
bug that was harmless so far.)
- Change pci_add_children() to take an extra argument that is the size of
the device info structure passed to pci_read_device() and make it public
so subclasses of the PCI bus can call it in their attach routines.
- Move the bits to attach a probed PCI child to a PCI bus into a global
pci_add_child() function. This will allow subclasses that can detect
a PCI device not found in the normal PCI probe to add those devices in
their own attach routine. (I have seen this in the ACPI tree on my
laptop for example.) As a side effect, change the static function
pci_add_resources() to get the busno, slot, and func from the passed
in dinfo structure instead of requiring them as function arguments.
Tested on: i386, alpha, ia64, sparc64
code into cardbus and s/pci/cardbus. This exposes a few pci_*
functions that are now static.
This work is similar to work Justin posted to the mobile list about a
year or two ago, which I have neglected since then.
This is a subset of his current work with the multiple inheritance
newbus architecutre. When completed, that will eliminate the need for
pci/pci_private.h.
Similar work is needed for the cardbus_cis and pccard_cis code as well.
all alphas with devices behind ppb's. I'm working on a better solution now.
Note that all alphas that use per-platform interrupt mapping are broken
again (as they have been for several months)
breakage:
- call PCIB_ROUTE_INTERRUPT() regardless of how valid the intline looks.
Some alphas leave garbage in the intline and leave the intr mapping
to OS platform support routines that map slots/buses to intlines
- Down in the alpha pci code, first try platform.pci_intr_route() and
if it doesn't exist or returns garbage, just read the intline out of
config space.
tested on AS500 (garbage in intline) and UP1000 (PC-like, intline is valid)
Note that a nice little hack like the APIC_IO section of pci_cfgregread()
is not workable. This is because the calling interface for
alpha_pci_route_interrupt() requires us to figure out the bus/slot/etc
from a device_t. At pci_read_device() time, we don't have a device_t
for the bus/slot/func in question.
- Break out the /dev/pci driver into a separate file.
- Kill the COMPAT_OLDPCI support.
- Make the EISA bridge attach a bit more like the old code; explicitly
check for the existence of eisa0/isa0 and only attach if they don't
already exist. Only make one bus_generic_attach() pass over the
bridge, once both busses are attached. Note that the stupid Intel
bridge's class is entirely unpredictable.
- Add prototypes and re-layout the core PCI modules in line with
current coding standards (not a major whitespace change, just moving
the module data to the top of the file).
- Remove redundant type-2 bridge support from the core PCI code; the
PCI-CardBus code does this itself internally. Remove the now
entirely redundant header-class-specific support, as well as the
secondary and subordinate bus number fields. These are bridge
attributes now.
- Add support for PCI Extended Capabilities.
- Add support for PCI Power Management. The interface currently
allows a driver to query and set the power state of a device.
- Add helper functions to allow drivers to enable/disable busmastering
and the decoding of I/O and memory ranges.
- Use PCI_SLOTMAX and PCI_FUNCMAX rather than magic numbers in some
places.
- Make the PCI-PCI bridge code a little more paranoid about valid
I/O and memory decodes.
- Add some more PCI register definitions for the command and status
registers. Correct another bogus definition for type-1 bridges.
- Improve the formatting for devices identified by the database.
- Fix the pcib_route_interrupt method definition, as an old version
snuck in here somehow 8(
- Remove a couple of the vendor/device IDs for PCI:ISA bridges which
correctly identify themselves.
Submitted by: peter
- Move PCI core code to dev/pci.
- Split bridge code out into separate modules.
- Remove the descriptive strings from the bridge drivers. If you
want to know what a device is, use pciconf. Add support for
broadly identifying devices based on class/subclass, and for
parsing a preloaded device identification database so that if
you want to waste the memory, you can identify *anything* we know
about.
- Remove machine-dependant code from the core PCI code. APIC interrupt
mapping is performed by shadowing the intline register in machine-
dependant code.
- Bring interrupt routing support to the Alpha
(although many platforms don't yet support routing or mapping
interrupts entirely correctly). This resulted in spamming
<sys/bus.h> into more places than it really should have gone.
- Put sys/dev on the kernel/modules include path. This avoids
having to change *all* the pci*.h includes.
command register is too aggressive. Revert to the previous behaviour, but
leave the new behaviour available as an undocumented option. It's not
clear what the Right, Right Thing is to do here, but the more conservative
approach is safer.
#ifdef away the offending code until somebody with more newbus fu than
me can figure out where to put a default function that returns 255
without touching each alpha chipset driver..
bus/slot/function numbers. The old PCI code used other markers or
something, but without it here under the new pci code it is very hard to
tell which device is which (this only affects bootverbose mode).
enable bit hasn't been set in the command register, set the bit and
honour the register. It seems that quite a few lazy BIOS writers
aren't bothering to do this, which upsets the existing code and causes
us to miss out on properly-configured devices.
the drivers.
* Remove legacy inx/outx support from chipset and replace with macros
which call busspace.
* Rework pci config accesses to route through the pcib device instead of
calling a MD function directly.
With these changes it is possible to cleanly support machines which have
more than one independantly numbered PCI busses. As a bonus, the new
busspace implementation should be measurably faster than the old one.
"options COMPAT_OLDPCI". This option already existed, but now also tidies
up the declarations in #include <pci/pci*.h>. It is amazing how much stuff
was using the old pre-FreeBSD 3.x names and going silently undetected.
not u_long. On i386's with 64-bit longs, returning u_longs indirectly
in (more than) the space reserved for uintptr_t's tended to corrupt the
previous frame pointer in the stack frame, so it was not easy to debug.
The type mismatches are hidden by the bogus cast in DEVMETHOD().
non-device code.
* Re-implement the method dispatch to improve efficiency. The new system
takes about 40ns for a method dispatch on a 300Mhz PII which is only
10ns slower than a direct function call on the same hardware.
This changes the new-bus ABI slightly so make sure you re-compile any
driver modules which you use.
it's options COMPAT_OLDISA and COMPAT_OLDPCI. This is meant to be a
fairly strong incentive to update the older drivers to newbus, but doesn't
(quite) leave anybody hanging with no hardware support. I was talking with
a few folks and I was encouraged to simply break or disable the shims but
that was a bit too drastic for my liking.
platform we're running on so we know how many bits to reserve at the top
end for the 'hose' value. It turns out that there's *just* enough room
to support all possible hoses on TurboLaser.
Reviewed by: gallatin@freebsd.org, dfr@free3bsd.org
from useful drivers such as the 3D DRI drivers I will be porting for
hardware accelerated OpenGL. The hardware will still be reported during
boot using the nomatch system.
Approved by: jkh
are using an old unconverted driver. Most (if not all) of the drivers
for common hardware are newbus these days. However, we don't want
to encourage people to take the easy way out and write new drivers
using the shims. This is just passive "encouragement".
Reviewed by: phk
attaching to the device via chip*, use the newbus nomatch method to report
the device. This leaves them unattached so that a driver can be easily
loaded to grab them later.
background ]
Rename sys/pci/pci_ioctl.h to sys/sys/pciio.h to make it easier for
userland programs to use this interface. Reformat the file, and add a
BSD-style copyright to it.
Add a new man page for pci(4). The PCIOCGETCONF, PCIOCREAD, and PCIOCWRITE
ioctls are documented, but the PCIOCATTACHED ioctl is not documented
because it is not implemented.
Change includes of <pci/pci_ioctl.h> to <sys/pciio.h> or remove them
altogether. In many cases, pci_ioctl.h was unused.
Reviewed by: steve
device_add_child_ordered(). 'ivars' may now be set using the
device_set_ivars() function.
This makes it easier for us to change how arbitrary data structures are
associated with a device_t. Eventually we won't be modifying device_t
to add additional pointers for ivars, softc data etc.
Despite my best efforts I've probably forgotten something so let me know
if this breaks anything. I've been running with this change for months
and its been quite involved actually isolating all the changes from
the rest of the local changes in my tree.
Reviewed by: peter, dfr
rather than an "it's mine!" so that other newbus-aware drivers can
bid for the device too. This should allow the sym driver to out-bid
the ncr driver for devices it supports without having to modify ncr.c
at all. ncr would then function as a catch-all.
pci_probe_nomatch, so it won't be in the way when loading USB as a module.
The reason for them being there in the first place is that every
motherboard comes with USB kit and this way it looks more pretty (peter).
The real solution will be to define some method of detaching a driver
after it has attached.
"rw" argument, rather than hijacking B_{READ|WRITE}.
Fix two bugs (physio & cam) resulting by the confusion caused by this.
Submitted by: Tor.Egge@fast.no
Reviewed by: alc, ken (partly)
* Change the hack used on the alpha for mapping devices into DENSE or
BWX memory spaces to a simpler one. Its still a hack and should be
a seperate api to explicitly map the resource.
* Add $FreeBSD$ as necessary.
Rather than teaching pci_ioctl about hoses, we just pass down a magic number
& let the platform code figure out what the hose is based on what the bus
number is.
concept approved by dfr
For unknown devices the output will now be
pci0: unknown card (vendor=0x109e, dev=0x0878) at 14.1 irq 19
instead of
pci0: unknown card DD^0878 (vendor=0x109e, dev=0x0878) at 14.1 irq 19
Before this change, the code used to take the PCI vendor id and translate it
into a three letter ASCII name.
For PnP devices, the vendor id _does_ map to a nice ASCII name
(eg Creative Labs PnP ID maps to "CTL", ESS PnP ID maps to "ESS")
But there is no such mapping for PCI devices, as can be seen by the
example above where the Brooktree PCI vendor ID maps to "DD^"
The PCI Special Interest Group confirmed they do not have any mappings
from vendor ID to ASCII.
have been there in the first place. A GENERIC kernel shrinks almost 1k.
Add a slightly different safetybelt under nostop for tty drivers.
Add some missing FreeBSD tags
Diskslice/label code not yet handled.
Vinum, i4b, alpha, pc98 not dealt with (left to respective Maintainers)
Add the correct hook for devfs to kern_conf.c
The net result of this excercise is that a lot less files depends on DEVFS,
and devtoname() gets more sensible output in many cases.
A few drivers had minor additional cleanups performed relating to cdevsw
registration.
A few drivers don't register a cdevsw{} anymore, but only use make_dev().
- device_print_child() either lets the BUS_PRINT_CHILD
method produce the entire device announcement message or
it prints "foo0: not found\n"
Alter sys/kern/subr_bus.c:bus_generic_print_child() to take on
the previous behavior of device_print_child() (printing the
"foo0: <FooDevice 1.1>" bit of the announce message.)
Provide bus_print_child_header() and bus_print_child_footer()
to actually print the output for bus_generic_print_child().
These functions should be used whenever possible (unless you can
just use bus_generic_print_child())
The BUS_PRINT_CHILD method now returns int instead of void.
Modify everything else that defines or uses a BUS_PRINT_CHILD
method to comply with the above changes.
- Devices are 'on' a bus, not 'at' it.
- If a custom BUS_PRINT_CHILD method does the same thing
as bus_generic_print_child(), use bus_generic_print_child()
- Use device_get_nameunit() instead of both
device_get_name() and device_get_unit()
- All BUS_PRINT_CHILD methods return the number of
characters output.
Reviewed by: dfr, peter
equivalent to SYS_RES_MEMORY for x86 but for alpha, the rman_get_virtual()
address of the resource is initialised to point into either dense-mapped
or bwx-mapped space respectively, allowing direct memory pointers to be
used to device memory.
Reviewed by: Andrew Gallatin <gallatin@cs.duke.edu>
