ISTR /proc/pci being deprecated at one point in the past. It may have only
been discussed, though. In which case, is it possible to deprecate it?
lscpi(8) is considered a superior means to derive the same information.
Elimination of it would eliminate a chunk of code in drivers/pci/proc.c,
and obviate the use of struct device::name by the PCI layer. This change
would probably allow us to remove the name field altogether, since PCI is
the only code that really relies on it (and only for /proc/pci AFAICT).
Is anything in userspace still relying on /proc/pci?
-pat
Patrick Mochel wrote:
> ISTR /proc/pci being deprecated at one point in the past. It may have only
> been discussed, though. In which case, is it possible to deprecate it?
> lscpi(8) is considered a superior means to derive the same information.
>
> Elimination of it would eliminate a chunk of code in drivers/pci/proc.c,
> and obviate the use of struct device::name by the PCI layer. This change
> would probably allow us to remove the name field altogether, since PCI is
> the only code that really relies on it (and only for /proc/pci AFAICT).
Historically, this was a Linus call :)
IIRC it was one of (a) deprecated, (b) removed, or (c) almost removed in
the past, and Linus un-deprecated it. The logic back then was that it
provides a quick summary of a lot of useful info, a la /proc/cpuinfo and
/proc/meminfo. i.e. you don't need lspci installed, just been /bin/cat.
Personally, I think it would be nice to eliminate /proc/pci -- in favor
of something that provides similar functionality from sysfs: "cat
/sys/all-busses" or somesuch. I dunno how feasible that is. The main
idea is to list as many attached devices as possible in one go, without
having to cat 40 different files :) [unfortunately I think this means I
am disagreeing with you ;)]
I do grant you it would make various __init sections and in-memory
structures smaller if we eliminated the names... do we want to? Sure
we have lseisa and lspci and lsusb, et. al. Does that obviate the need
for a simple summary of attached hardware?
Jeff
On Fri, 6 Dec 2002, Jeff Garzik wrote:
> Patrick Mochel wrote:
> > ISTR /proc/pci being deprecated at one point in the past. It may have only
> > been discussed, though. In which case, is it possible to deprecate it?
> > lscpi(8) is considered a superior means to derive the same information.
> >
> > Elimination of it would eliminate a chunk of code in drivers/pci/proc.c,
> > and obviate the use of struct device::name by the PCI layer. This change
> > would probably allow us to remove the name field altogether, since PCI is
> > the only code that really relies on it (and only for /proc/pci AFAICT).
>
>
> Historically, this was a Linus call :)
Yeah, Randy said that about 30s before I got this. :)
> IIRC it was one of (a) deprecated, (b) removed, or (c) almost removed in
> the past, and Linus un-deprecated it. The logic back then was that it
> provides a quick summary of a lot of useful info, a la /proc/cpuinfo and
> /proc/meminfo. i.e. you don't need lspci installed, just been /bin/cat.
Ok, I can see that. But, are there really many systems that do not come
with lspci(8) pre-installed? I would expect that most distributions do; at
least the one I use does..
But, look the usage model. Who queries PCI information from the system? I
would argue a) developers, b) power users, and c) users hitting a bug.
a) are going to use lspci, since it's much more powerful. b) may use
either text format, but it's also likely they'll use a graphical tool.
Looking at my gnome setup, I do not find anything that lists PCI devices
(besides a file browser in sysfs :). And, c) are most likely going to use
lspci becaus a developer asks for it. I do not remember the last time I
saw someone ask for the output of /proc/pci. :)
> Personally, I think it would be nice to eliminate /proc/pci -- in favor
> of something that provides similar functionality from sysfs: "cat
> /sys/all-busses" or somesuch. I dunno how feasible that is. The main
> idea is to list as many attached devices as possible in one go, without
> having to cat 40 different files :) [unfortunately I think this means I
> am disagreeing with you ;)]
I totally agree with you. But, I don't think the answer is in
consolidating files; I think it's in writing intelligent and efficient
tools to grok that data.
> I do grant you it would make various __init sections and in-memory
> structures smaller if we eliminated the names... do we want to? Sure
> we have lseisa and lspci and lsusb, et. al. Does that obviate the need
> for a simple summary of attached hardware?
IMO, yes, since those tools provide the summary, and exist almost purely
in userspace. I forgot to mention in the orginal email that we could
also drop the PCI names database, right? This would save a considerable
amount in the kernel image alone..
-pat
On 6 Dec 02 at 16:13, Patrick Mochel wrote:
>
> > IIRC it was one of (a) deprecated, (b) removed, or (c) almost removed in
> > the past, and Linus un-deprecated it. The logic back then was that it
> > provides a quick summary of a lot of useful info, a la /proc/cpuinfo and
> > /proc/meminfo. i.e. you don't need lspci installed, just been /bin/cat.
>
> Ok, I can see that. But, are there really many systems that do not come with
> lspci(8) pre-installed? I would expect that most distributions do; at least
> the one I use does..
>
> But, look the usage model. Who queries PCI information from the system? I
> would argue a) developers, b) power users, and c) users hitting a bug.
It is invaluable during installation, when no lspci is installed yet.
I know that I need e100/eepro100 for
'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not
have even slightest idea what device 8086:2449 is, whether USB or NIC or
VGA or some bridge.
Next problem is that some drivers want to print "user readable" hardware
name to user, and although some have its own name database (e100), some
use name from pcidev...
> > I do grant you it would make various __init sections and in-memory
> > structures smaller if we eliminated the names... do we want to? Sure we
> > have lseisa and lspci and lsusb, et. al. Does that obviate the need for a
> > simple summary of attached hardware?
>
> IMO, yes, since those tools provide the summary, and exist almost purely in
> userspace. I forgot to mention in the orginal email that we could also drop
> the PCI names database, right? This would save a considerable amount in the
> kernel image alone..
If you want, make it user configurable like it was during 2.2.x. But
I personally prefer descriptive names and system overview I can parse
without having mounted /usr to get working lspci.
Best regards,
Petr Vandrovec
[email protected]
On Sat, Dec 07, 2002 at 12:18:05AM +0100, Petr Vandrovec wrote:
> It is invaluable during installation, when no lspci is installed yet.
> I know that I need e100/eepro100 for
> 'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not
> have even slightest idea what device 8086:2449 is, whether USB or NIC or
> VGA or some bridge.
at least, the file "modules.pcimap" tells you which modules support these
devices, by vendor/model codes. I once developped a little installation script
which loaded all the NICs it could by listing /proc/bus/pci/devices and
modules.pcimap. I too agree that names in /proc/pci are *really* useful, but I
often omit them when I need a very little image. Perhaps having a list of names
only for devices supported by the kernel and modules at compile time would be
an acceptable compromise ?
Regards,
Willy
Petr Vandrovec ([email protected]) wrote:
> On 6 Dec 02 at 16:13, Patrick Mochel wrote:
>>
>> > IIRC it was one of (a) deprecated, (b) removed, or (c) almost removed in
>> > the past, and Linus un-deprecated it. The logic back then was that it
>> > provides a quick summary of a lot of useful info, a la /proc/cpuinfo and
>> > /proc/meminfo. i.e. you don't need lspci installed, just been /bin/cat.
>>
>> Ok, I can see that. But, are there really many systems that do not come with
>> lspci(8) pre-installed? I would expect that most distributions do; at least
>> the one I use does..
>>
>> But, look the usage model. Who queries PCI information from the system? I
>> would argue a) developers, b) power users, and c) users hitting a bug.
>
> It is invaluable during installation, when no lspci is installed yet.
> I know that I need e100/eepro100 for
> 'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not
> have even slightest idea what device 8086:2449 is, whether USB or NIC or
> VGA or some bridge.
Every half-decent installer autodetects all PCI devices. AND had lspci
installed in the install image.
> Next problem is that some drivers want to print "user readable" hardware
> name to user, and although some have its own name database (e100), some
> use name from pcidev...
Ugh :-/ That's a reason to keep it around then.
>> > I do grant you it would make various __init sections and in-memory
>> > structures smaller if we eliminated the names... do we want to? Sure we
>> > have lseisa and lspci and lsusb, et. al. Does that obviate the need for a
>> > simple summary of attached hardware?
>>
>> IMO, yes, since those tools provide the summary, and exist almost purely in
>> userspace. I forgot to mention in the orginal email that we could also drop
>> the PCI names database, right? This would save a considerable amount in the
>> kernel image alone..
>
> If you want, make it user configurable like it was during 2.2.x. But
> I personally prefer descriptive names and system overview I can parse
> without having mounted /usr to get working lspci.
lspci should be installed in /sbin.
--
Erik Hensema ([email protected])
* Erik Hensema ([email protected]) wrote:
>
> Every half-decent installer autodetects all PCI devices. AND had lspci
> installed in the install image.
Yes, but wait till you find yourself stuck on a weird embedded board
with a small flash and a serial console and you are trying to debug the
PCI device you've built.
Sure in most cases you have lspci (and its friends); but why do people
want to deprecate a perfectly good tool that occasionally comes in
useful? (Make it a compile time option sure, remove it - no).
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
> > IMO, yes, since those tools provide the summary, and exist almost purely in
> > userspace. I forgot to mention in the orginal email that we could also drop
> > the PCI names database, right? This would save a considerable amount in the
> > kernel image alone..
>
> If you want, make it user configurable like it was during 2.2.x. But
> I personally prefer descriptive names and system overview I can parse
> without having mounted /usr to get working lspci.
Actually I'm inclined to insist that lspci belong in /sbin. Really. :)
--
Tomas Szepe <[email protected]>
> > It is invaluable during installation, when no lspci is installed yet.
> > I know that I need e100/eepro100 for
> > 'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not
> > have even slightest idea what device 8086:2449 is, whether USB or NIC or
> > VGA or some bridge.
>
> at least, the file "modules.pcimap" tells you which modules support these
> devices, by vendor/model codes. I once developped a little installation script
> which loaded all the NICs it could by listing /proc/bus/pci/devices and
> modules.pcimap. I too agree that names in /proc/pci are *really* useful, but I
> often omit them when I need a very little image. Perhaps having a list of names
> only for devices supported by the kernel and modules at compile time would be
> an acceptable compromise?
I've been using the following script in my install images to find kernel
modules for various PCI devices (the mechanism's not perfect, though,
I know of at least one module that "doesn't put" its ids in modules.pcimap):
#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin
PCIMAP=/lib/modules/$(uname -r)/modules.pcimap
ALLDEV=$(lspci -n| sed -e 's/^.*:[[:blank:]]\+\([^[:blank:]]\+\).*$/\1/')
if [ -n "$ALLDEV" -a -r $PCIMAP ]; then
for i in $ALLDEV; do
VENDOR="$(echo $i| cut -d':' -f1)"
DEVICE="$(echo $i| cut -d':' -f2)"
MODULE=$(grep "0x0000$VENDOR[[:blank:]]\+0x0000$DEVICE" $PCIMAP| \
awk '{ print $1; }')
echo -n "Vendor $VENDOR, dev $DEVICE: "
if [ -n "$MODULE" ]; then
echo $MODULE
else
echo "(no matching module)"
fi
done
fi
--
Tomas Szepe <[email protected]>
Em Sat, Dec 07, 2002 at 01:15:59PM +0000, Dr. David Alan Gilbert escreveu:
> * Erik Hensema ([email protected]) wrote:
> >
> > Every half-decent installer autodetects all PCI devices. AND had lspci
> > installed in the install image.
>
> Yes, but wait till you find yourself stuck on a weird embedded board
> with a small flash and a serial console and you are trying to debug the
> PCI device you've built.
In this weird embedded board with small flash it'd be lovely to save one
more page (or perhaps more) in the kernel image, no? :-)
> Sure in most cases you have lspci (and its friends); but why do people
> want to deprecate a perfectly good tool that occasionally comes in
> useful? (Make it a compile time option sure, remove it - no).
See above. And as you said lspci mostly is available. Remove it or make
it a compile time option, please.
- Arnaldo
On Sat, Dec 07, 2002 at 02:14:24PM +0100, Tomas Szepe wrote:
> > > IMO, yes, since those tools provide the summary, and exist almost purely in
> > > userspace. I forgot to mention in the orginal email that we could also drop
> > > the PCI names database, right? This would save a considerable amount in the
> > > kernel image alone..
> >
> > If you want, make it user configurable like it was during 2.2.x. But
> > I personally prefer descriptive names and system overview I can parse
> > without having mounted /usr to get working lspci.
>
> Actually I'm inclined to insist that lspci belong in /sbin. Really. :)
Try it. At least on Debian it is useless without name database, which lives in
/usr/share/misc/pci.ids... I can read numbers directly from /proc/bus/pci, if
I want numbers.
Petr Vandrovec
[email protected]
One thing that /proc/pci gives you that 'lspci' historically didn't was
the correct interrupt setup (because kernel irq routing has nothing to do
with the PCI irq config byte on most "interesting" machines).
I don't know if lspci gets that right these days, and the information does
exist in /sys, so there is certainly at least the _potential_ of dropping
/proc/pci.
Linus
[email protected] (Patrick Mochel) wrote on 06.12.02 in <[email protected]>:
> But, look the usage model. Who queries PCI information from the system? I
> would argue a) developers, b) power users, and c) users hitting a bug.
>
> a) are going to use lspci, since it's much more powerful. b) may use
> either text format, but it's also likely they'll use a graphical tool.
> Looking at my gnome setup, I do not find anything that lists PCI devices
> (besides a file browser in sysfs :). And, c) are most likely going to use
> lspci becaus a developer asks for it. I do not remember the last time I
> saw someone ask for the output of /proc/pci. :)
Hmm. Seems I am in neither group.
I use cat /proc/pci for the same reason I use cat /proc/scsi - when
configuring a box, or adding new hardware, to figure out what I should
look for and where it is.
I don't particularly care which part of the file system this omes from,
but I do care about being able to find it quickly, and about it being easy
(i.e. not need looking at 7868 separate files) and giving the essential
info (which is the info that can be found in the relevant docs or be fed
to google).
> I totally agree with you. But, I don't think the answer is in
> consolidating files; I think it's in writing intelligent and efficient
> tools to grok that data.
I seriously distrust tool-based solutions for this. It is far too likely
that any new tool will be missing when I most need it, and old tools
already aren't a particularly convincing solution.
I don't want to grovel through 7868 tools just as I don't want to grovel
through 7868 files. And the more those are, the less likely I am to even
have heard of them - from the lsXXX tools, the only one I knew about was
lspci, and lsusb (which seems to be the other one actually installed)
seems to be a lot more reluctant to give useful info to the non-USB-
expert.
MfG Kai
> One thing that /proc/pci gives you that 'lspci' historically didn't was
> the correct interrupt setup (because kernel irq routing has nothing to do
> with the PCI irq config byte on most "interesting" machines).
>
> I don't know if lspci gets that right these days, and the information does
> exist in /sys, so there is certainly at least the _potential_ of dropping
> /proc/pci.
It appears to:
[mochel@tina mochel]$ lspci -v | grep -B 2 IRQ | fgrep -v Subsystem
00:07.4 USB Controller: Advanced Micro Devices [AMD] AMD-765 [Viper] USB (rev 07) (prog-if 10 [OHCI])
Flags: bus master, medium devsel, latency 16, IRQ 19
--
00:09.0 Multimedia audio controller: Creative Labs: Unknown device 0004 (rev 03)
Flags: bus master, medium devsel, latency 64, IRQ 17
--
00:09.2 FireWire (IEEE 1394): Creative Labs: Unknown device 4001 (prog-if 10 [OHCI])
Flags: bus master, medium devsel, latency 64, IRQ 18
--
00:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
Flags: bus master, medium devsel, latency 64, IRQ 19
--
00:0c.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 01)
Flags: bus master, medium devsel, latency 66, IRQ 16
--
01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5144 (prog-if 00 [VGA])
Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel, latency 66, IRQ 18
[mochel@tina mochel]$ fgrep -B 1 IRQ /proc/pci
USB Controller: Advanced Micro Devic AMD-766 [ViperPlus] (rev 7).
IRQ 19.
--
Multimedia audio controller: Creative Labs SB Audigy (rev 3).
IRQ 17.
--
FireWire (IEEE 1394): Creative Labs SB Audigy FireWire P (rev 0).
IRQ 18.
--
Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boo (rev 0).
IRQ 19.
--
Ethernet controller: Intel Corp. 82557/8/9 [Ethernet (rev 1).
IRQ 16.
--
VGA compatible controller: ATI Technologies Inc Radeon QD (rev 0).
IRQ 18.
The appended patch both make /proc/pci a compile-time option and
deprecates it and the PCI names database. Text has been added to the
configuration options, and the top of the file.
The /proc/pci functionality has been moved from drivers/pci/proc.c to
drivers/pci/names.c, to make it closer to the PCI names interface. It
ain't the prettiest, but it's simple to understand.
-pat
diffstat:
Documentation/Changes | 4 +
drivers/pci/Kconfig | 38 ++++++++---
drivers/pci/names.c | 167 +++++++++++++++++++++++++++++++++++++++++++++++++-
drivers/pci/proc.c | 113 ---------------------------------
4 files changed, 199 insertions(+), 123 deletions(-)
===== Documentation/Changes 1.28 vs edited =====
--- 1.28/Documentation/Changes Fri Nov 8 01:47:19 2002
+++ edited/Documentation/Changes Sat Dec 7 20:53:59 2002
@@ -347,6 +347,10 @@
----------
o <http://powertweak.sourceforge.net/>
+pci-utils
+---------
+o <ftp://ftp.kernel.org/pub/software/utils/pciutils/>
+
Networking
**********
===== drivers/pci/Kconfig 1.1 vs edited =====
--- 1.1/drivers/pci/Kconfig Tue Oct 29 19:16:55 2002
+++ edited/drivers/pci/Kconfig Sat Dec 7 20:37:24 2002
@@ -1,18 +1,38 @@
#
# PCI configuration
#
+
+config PCI_OLD_PROC
+ bool "/proc/pci Interface"
+ depends on PCI && PROC_FS
+ ---help---
+ This option is deprecated.
+
+ This option provides the traditional /proc/pci interface, which lists
+ every PCI device and some information extracted from their configuration
+ space.
+
+ This option has been deprecated as of kernel version 2.5.51. The option
+ and the /proc/pci interface will be removed at a futre date. The
+ preferred alternative is to use the lspci(8) utility. Please refer to
+ Documentation/Changes for information on where to get the latest version.
+
+ If unsure, say N and use lspci(8) instead.
+
config PCI_NAMES
bool "PCI device name database"
depends on PCI
---help---
- By default, the kernel contains a database of all known PCI device
- names to make the information in /proc/pci, /proc/ioports and
- similar files comprehensible to the user. This database increases
- size of the kernel image by about 80KB, but it gets freed after the
- system boots up, so it doesn't take up kernel memory. Anyway, if you
- are building an installation floppy or kernel for an embedded system
- where kernel image size really matters, you can disable this feature
- and you'll get device ID numbers instead of names.
+ This option is deprecated.
+
+ This option adds a database of PCI device names to make the names of
+ PCI devices in /proc/pci and /proc/ioports more sensible. The /proc/pci
+ interface has been deprecated, and when it is removed, the PCI names
+ database will also probably be removed.
+
+ This option increases the size of the kernel by about 55KB. If
+ CONFIG_HOTPLUG is not set, then this memory is freed after the system
+ boots up.
- When in doubt, say Y.
+ When in doubt, say N.
===== drivers/pci/names.c 1.5 vs edited =====
--- 1.5/drivers/pci/names.c Sat Nov 16 16:54:29 2002
+++ edited/drivers/pci/names.c Sat Dec 7 20:45:23 2002
@@ -1,8 +1,16 @@
/*
- * PCI Class and Device Name Tables
+ * PCI Class and Device Name Tables and /proc/pci interface.
*
* Copyright 1993--1999 Drew Eckhardt, Frederic Potter,
* David Mosberger-Tang, Martin Mares
+ *
+ * These features have been depcrecated as of v2.5.51.
+ * The PCI names interface was useful only for presenting meaningful names
+ * in /proc/pci and /proc/ioports.
+ * The /proc/pci interface is deprecated, as lspci(8) is a much more useful
+ * tool that provides all the info in /proc/pci and more, while existing
+ * completely in userspace. That is now the preferred method of extracting
+ * PCI device data.
*/
#include <linux/config.h>
@@ -11,6 +19,7 @@
#include <linux/pci.h>
#include <linux/init.h>
+
#ifdef CONFIG_PCI_NAMES
struct pci_device_info {
@@ -136,3 +145,159 @@
#endif /* CONFIG_PCI_NAMES */
+
+#ifdef CONFIG_PCI_OLD_PROC
+
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+
+/* iterator */
+static void *pci_seq_start(struct seq_file *m, loff_t *pos)
+{
+ struct list_head *p = &pci_devices;
+ loff_t n = *pos;
+
+ /* XXX: surely we need some locking for traversing the list? */
+ while (n--) {
+ p = p->next;
+ if (p == &pci_devices)
+ return NULL;
+ }
+ return p;
+}
+static void *pci_seq_next(struct seq_file *m, void *v, loff_t *pos)
+{
+ struct list_head *p = v;
+ (*pos)++;
+ return p->next != &pci_devices ? p->next : NULL;
+}
+static void pci_seq_stop(struct seq_file *m, void *v)
+{
+ /* release whatever locks we need */
+}
+
+
+/*
+ * Backward compatible /proc/pci interface.
+ */
+
+/*
+ * Convert some of the configuration space registers of the device at
+ * address (bus,devfn) into a string (possibly several lines each).
+ * The configuration string is stored starting at buf[len]. If the
+ * string would exceed the size of the buffer (SIZE), 0 is returned.
+ */
+static int show_dev_config(struct seq_file *m, void *v)
+{
+ struct list_head *p = v;
+ struct pci_dev *dev;
+ struct pci_driver *drv;
+ u32 class_rev;
+ unsigned char latency, min_gnt, max_lat, *class;
+ int reg;
+
+ if (p == &pci_devices) {
+ seq_puts(m, "PCI devices found:\n");
+ return 0;
+ }
+
+ dev = pci_dev_g(p);
+ drv = pci_dev_driver(dev);
+
+ pci_read_config_dword(dev, PCI_CLASS_REVISION, &class_rev);
+ pci_read_config_byte (dev, PCI_LATENCY_TIMER, &latency);
+ pci_read_config_byte (dev, PCI_MIN_GNT, &min_gnt);
+ pci_read_config_byte (dev, PCI_MAX_LAT, &max_lat);
+ seq_printf(m, " Bus %2d, device %3d, function %2d:\n",
+ dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+ class = pci_class_name(class_rev >> 16);
+ if (class)
+ seq_printf(m, " %s", class);
+ else
+ seq_printf(m, " Class %04x", class_rev >> 16);
+ seq_printf(m, ": %s (rev %d).\n", dev->dev.name, class_rev & 0xff);
+
+ if (dev->irq)
+ seq_printf(m, " IRQ %d.\n", dev->irq);
+
+ if (latency || min_gnt || max_lat) {
+ seq_printf(m, " Master Capable. ");
+ if (latency)
+ seq_printf(m, "Latency=%d. ", latency);
+ else
+ seq_puts(m, "No bursts. ");
+ if (min_gnt)
+ seq_printf(m, "Min Gnt=%d.", min_gnt);
+ if (max_lat)
+ seq_printf(m, "Max Lat=%d.", max_lat);
+ seq_putc(m, '\n');
+ }
+
+ for (reg = 0; reg < 6; reg++) {
+ struct resource *res = dev->resource + reg;
+ unsigned long base, end, flags;
+
+ base = res->start;
+ end = res->end;
+ flags = res->flags;
+ if (!end)
+ continue;
+
+ if (flags & PCI_BASE_ADDRESS_SPACE_IO) {
+ seq_printf(m, " I/O at 0x%lx [0x%lx].\n",
+ base, end);
+ } else {
+ const char *pref, *type = "unknown";
+
+ if (flags & PCI_BASE_ADDRESS_MEM_PREFETCH)
+ pref = "P";
+ else
+ pref = "Non-p";
+ switch (flags & PCI_BASE_ADDRESS_MEM_TYPE_MASK) {
+ case PCI_BASE_ADDRESS_MEM_TYPE_32:
+ type = "32 bit"; break;
+ case PCI_BASE_ADDRESS_MEM_TYPE_1M:
+ type = "20 bit"; break;
+ case PCI_BASE_ADDRESS_MEM_TYPE_64:
+ type = "64 bit"; break;
+ }
+ seq_printf(m, " %srefetchable %s memory at "
+ "0x%lx [0x%lx].\n", pref, type,
+ base,
+ end);
+ }
+ }
+ return 0;
+}
+
+static struct seq_operations proc_pci_op = {
+ .start = pci_seq_start,
+ .next = pci_seq_next,
+ .stop = pci_seq_stop,
+ .show = show_dev_config
+};
+
+static int proc_pci_open(struct inode *inode, struct file *file)
+{
+ return seq_open(file, &proc_pci_op);
+}
+static struct file_operations proc_pci_operations = {
+ .open = proc_pci_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
+
+static int __init pci_old_proc_init(void)
+{
+ struct proc_dir_entry * entry;
+ entry = create_proc_entry("pci", 0, NULL);
+ if (entry)
+ entry->proc_fops = &proc_pci_operations;
+ return 0;
+}
+
+module_init(pci_old_proc_init);
+
+#endif /* CONFIG_PCI_OLD_PROC */
===== drivers/pci/proc.c 1.21 vs edited =====
--- 1.21/drivers/pci/proc.c Mon Nov 18 01:09:47 2002
+++ edited/drivers/pci/proc.c Sat Dec 7 20:27:46 2002
@@ -473,106 +473,6 @@
}
-/*
- * Backward compatible /proc/pci interface.
- */
-
-/*
- * Convert some of the configuration space registers of the device at
- * address (bus,devfn) into a string (possibly several lines each).
- * The configuration string is stored starting at buf[len]. If the
- * string would exceed the size of the buffer (SIZE), 0 is returned.
- */
-static int show_dev_config(struct seq_file *m, void *v)
-{
- struct list_head *p = v;
- struct pci_dev *dev;
- struct pci_driver *drv;
- u32 class_rev;
- unsigned char latency, min_gnt, max_lat, *class;
- int reg;
-
- if (p == &pci_devices) {
- seq_puts(m, "PCI devices found:\n");
- return 0;
- }
-
- dev = pci_dev_g(p);
- drv = pci_dev_driver(dev);
-
- pci_read_config_dword(dev, PCI_CLASS_REVISION, &class_rev);
- pci_read_config_byte (dev, PCI_LATENCY_TIMER, &latency);
- pci_read_config_byte (dev, PCI_MIN_GNT, &min_gnt);
- pci_read_config_byte (dev, PCI_MAX_LAT, &max_lat);
- seq_printf(m, " Bus %2d, device %3d, function %2d:\n",
- dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
- class = pci_class_name(class_rev >> 16);
- if (class)
- seq_printf(m, " %s", class);
- else
- seq_printf(m, " Class %04x", class_rev >> 16);
- seq_printf(m, ": %s (rev %d).\n", dev->dev.name, class_rev & 0xff);
-
- if (dev->irq)
- seq_printf(m, " IRQ %d.\n", dev->irq);
-
- if (latency || min_gnt || max_lat) {
- seq_printf(m, " Master Capable. ");
- if (latency)
- seq_printf(m, "Latency=%d. ", latency);
- else
- seq_puts(m, "No bursts. ");
- if (min_gnt)
- seq_printf(m, "Min Gnt=%d.", min_gnt);
- if (max_lat)
- seq_printf(m, "Max Lat=%d.", max_lat);
- seq_putc(m, '\n');
- }
-
- for (reg = 0; reg < 6; reg++) {
- struct resource *res = dev->resource + reg;
- unsigned long base, end, flags;
-
- base = res->start;
- end = res->end;
- flags = res->flags;
- if (!end)
- continue;
-
- if (flags & PCI_BASE_ADDRESS_SPACE_IO) {
- seq_printf(m, " I/O at 0x%lx [0x%lx].\n",
- base, end);
- } else {
- const char *pref, *type = "unknown";
-
- if (flags & PCI_BASE_ADDRESS_MEM_PREFETCH)
- pref = "P";
- else
- pref = "Non-p";
- switch (flags & PCI_BASE_ADDRESS_MEM_TYPE_MASK) {
- case PCI_BASE_ADDRESS_MEM_TYPE_32:
- type = "32 bit"; break;
- case PCI_BASE_ADDRESS_MEM_TYPE_1M:
- type = "20 bit"; break;
- case PCI_BASE_ADDRESS_MEM_TYPE_64:
- type = "64 bit"; break;
- }
- seq_printf(m, " %srefetchable %s memory at "
- "0x%lx [0x%lx].\n", pref, type,
- base,
- end);
- }
- }
- return 0;
-}
-
-static struct seq_operations proc_pci_op = {
- .start = pci_seq_start,
- .next = pci_seq_next,
- .stop = pci_seq_stop,
- .show = show_dev_config
-};
-
static int proc_bus_pci_dev_open(struct inode *inode, struct file *file)
{
return seq_open(file, &proc_bus_pci_devices_op);
@@ -583,16 +483,6 @@
.llseek = seq_lseek,
.release = seq_release,
};
-static int proc_pci_open(struct inode *inode, struct file *file)
-{
- return seq_open(file, &proc_pci_op);
-}
-static struct file_operations proc_pci_operations = {
- .open = proc_pci_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = seq_release,
-};
static int __init pci_proc_init(void)
{
@@ -607,9 +497,6 @@
pci_for_each_dev(dev) {
pci_proc_attach_device(dev);
}
- entry = create_proc_entry("pci", 0, NULL);
- if (entry)
- entry->proc_fops = &proc_pci_operations;
}
return 0;
}
On Sat, 7 Dec 2002, Patrick Mochel wrote:
>
> > I don't know if lspci gets that right these days, and the information does
> > exist in /sys, so there is certainly at least the _potential_ of dropping
> > /proc/pci.
>
> It appears to:
>
> [mochel@tina mochel]$ lspci -v | grep -B 2 IRQ | fgrep -v Subsystem
>
> 00:07.4 USB Controller: Advanced Micro Devices [AMD] AMD-765 [Viper] USB (rev 07) (prog-if 10 [OHCI])
> Flags: bus master, medium devsel, latency 16, IRQ 19
Just out of interest, where _does_ it get the information? Does it try to
do its own irq routing (bad!) or does it do it from /proc/bus/pci/devices?
Linus
Petr Vandrovec ([email protected]) wrote:
> On Sat, Dec 07, 2002 at 02:14:24PM +0100, Tomas Szepe wrote:
>> > > IMO, yes, since those tools provide the summary, and exist almost purely in
>> > > userspace. I forgot to mention in the orginal email that we could also drop
>> > > the PCI names database, right? This would save a considerable amount in the
>> > > kernel image alone..
>> >
>> > If you want, make it user configurable like it was during 2.2.x. But
>> > I personally prefer descriptive names and system overview I can parse
>> > without having mounted /usr to get working lspci.
>>
>> Actually I'm inclined to insist that lspci belong in /sbin. Really. :)
>
> Try it. At least on Debian it is useless without name database, which lives in
> /usr/share/misc/pci.ids... I can read numbers directly from /proc/bus/pci, if
> I want numbers.
Hmmmm, on SuSE 8.0 too. I consider this a bug. Or at least a misfeature.
Binaries in /bin and /sbin should not need anything from /usr.
--
Erik Hensema <[email protected]>
Patrick Mochel <[email protected]> writes:
> IMO, yes, since those tools provide the summary, and exist almost purely
> in userspace. I forgot to mention in the orginal email that we could
> also drop the PCI names database, right? This would save a considerable
> amount in the kernel image alone..
I think so.
BTW: the /proc/pci doesn't show names of CardBus adapters, even if they're
inserted at boot time - cat /proc/pci | tail:
VGA compatible controller: Silicon Motion, Inc. SM720 Lynx3DM (rev 177).
IRQ 10.
Master Capable. Latency=64.
Non-prefetchable 32 bit memory at 0xf8000000 [0xfbffffff].
Bus 2, device 0, function 0:
Ethernet controller: PCI device 1011:0019 (rev 65).
IRQ 10.
Master Capable. Latency=64. Min Gnt=20.Max Lat=40.
I/O at 0x4000 [0x407f].
Non-prefetchable 32 bit memory at 0x10800000 [0x108003ff].
--
Krzysztof Halasa
Network Administrator
On Sat, Dec 07, 2002 at 08:21:21PM -0800, Linus Torvalds wrote:
> > Flags: bus master, medium devsel, latency 16, IRQ 19
>
> Just out of interest, where _does_ it get the information? Does it try to
> do its own irq routing (bad!) or does it do it from /proc/bus/pci/devices?
It just reports what's in the PCI_INTERRUPT_LINE register.
At least on Alpha, we wrote into this register during pci
configuration, so the value matches what's in /proc/interrupts.
I guess I always assumed we did the same on x86, but I've
never checked.
r~
On Mon, Dec 09, 2002 at 10:11:39AM -0800, Linus Torvalds wrote:
>
> On 9 Dec 2002, Alan Cox wrote:
> >
> > Tested and verified. If I leave it alone non apic mode works. To use
> > APIC mode I have to write the new IRQ value into that register. I've
> > shoved that into the driver for now, since its a demented chip specific
> > horror.
>
> That's definitely where it should be - the behaviour of the
> PCI_INTERRUPT_LINE register is clearly chip-specific, so it should be in
> the chip-specific drivers..
>
> It's a kind of strange behaviour, though. What chip is this? It sounds
> kind of convenient, but as far as I can tell it can only work for those
> kinds of PCI devices that are on the same chip as the irq controller..
As a reminder of ancient times, one of the reasons I wanted to do
per-PCI-device interrupt routing was due to the older incarnation of
these chips, the Via 686 a/b southbridges. They have a similar method
of routing interrupts, where writing to PCI_INTERRUPT_LINE directly
makes internal chip magic occur. So you are correct WRT
"only work ... on the same chip as the irq controller"
Jeff
On 9 Dec 2002, Alan Cox wrote:
>
> Tested and verified. If I leave it alone non apic mode works. To use
> APIC mode I have to write the new IRQ value into that register. I've
> shoved that into the driver for now, since its a demented chip specific
> horror.
That's definitely where it should be - the behaviour of the
PCI_INTERRUPT_LINE register is clearly chip-specific, so it should be in
the chip-specific drivers..
It's a kind of strange behaviour, though. What chip is this? It sounds
kind of convenient, but as far as I can tell it can only work for those
kinds of PCI devices that are on the same chip as the irq controller..
Linus
On Mon, 2002-12-09 at 17:00, Linus Torvalds wrote:
> On 9 Dec 2002, Alan Cox wrote:
> > I wonder if this is why we have all these problems with VIA chipset
> > interrupt handling. According to VIA docs they _do_ use
> > PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
> > between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"
>
> Whee.. That sounds like a load of crock in the first place, since the
> PCI_INTERRUPT_LINE thing should be just a scratch register as far as I
> know. However, it doesn't really matter - we definitely should never write
> to it anyway, so the VIA behaviour while strange should still be
> acceptable.
Tested and verified. If I leave it alone non apic mode works. To use
APIC mode I have to write the new IRQ value into that register. I've
shoved that into the driver for now, since its a demented chip specific
horror.
On 9 Dec 2002, Alan Cox wrote:
>
> I wonder if this is why we have all these problems with VIA chipset
> interrupt handling. According to VIA docs they _do_ use
> PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
> between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"
Whee.. That sounds like a load of crock in the first place, since the
PCI_INTERRUPT_LINE thing should be just a scratch register as far as I
know. However, it doesn't really matter - we definitely should never write
to it anyway, so the VIA behaviour while strange should still be
acceptable.
Anyway, to get back on the original discussion, I think we should remove
the writing, and then make sure that /sbin/lspci (or some other tool) can
be made to easily show either the kernel irq mapping value _or_ the
"original PCI config space" value. At that point I'd agree that /proc/pci
has outlived its usefulness.
(Although I still think the name database is nice to have - I certainly
prefer it over having a lot of drivers having their _own_ name databases
for printout purposes).
Linus
On Sun, Dec 08, 2002 at 05:54:16PM -0800, Linus Torvalds wrote:
> Writing it back is actively _bad_, since it will make it very hard to
> re-boot the machine without the BIOS re-enumarating the PCI bus and
> filling it in again (ie it would definitely screw up using things like
> kexec() on PC's, if the kernel we boot _from_ is an APIC kernel, but the
> kernel we boot _into_ is not).
True. This applies to alpha as well because of the way how modern consoles
encode IRQs routed through the ISA bridge (actual IRQ + 0xe0).
Probably we should eliminate pcibios_update_irq() call in
drivers/pci/setup-irq.c and see what happens. Nothing bad, I guess.
Ivan.
A PS to this btw reading over the code - currently it seems to write it
with our IRQ data if we do a suspend/resume but not initially. If so we
have an inconsistency to resolve
On Mon, 2002-12-09 at 01:54, Linus Torvalds wrote:
> - we should _never_ update the PCI_INTERRUPT_LINE register, because it
> destroys boot loader information (the same way we need to not overwrite
> BIOS extended areas and ACPI areas etc in order to be able to reboot
> cleanly)
I wonder if this is why we have all these problems with VIA chipset
interrupt handling. According to VIA docs they _do_ use
PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"
Alan
[Please CC me replies as I'm not on the list ]
Hi
When I added kt400 agp support recently (just a ID declaration since
generic via routines work fine on my box), I had to declare the KT400
pci id in gart. Which was the only thing really needed (or so I thought
in a sane world).
Then I did the 2.4 patch. And guess what ? I found I had to declare it
in dri (two times, ie for each versions supported) and in the pci id
database. What kind of madness is it ? How many people do you expect to
update *four* lists with the same info (and btw the last time I checked
2.4 followups were not merged in 2.5) ?
And all this time lspci knew my chip. In fact, I *used* lspci info to
get the right info to put in the kernel. And to this day since not
everything was merged in 2.5 lspci is more accurate than the kernel.
So from my very na?ve point of view /proc/pci wouldn't be mourned,
quite the contrary.
Regards,
--
Nicolas Mailhot
On Sun, 8 Dec 2002, Erik Hensema wrote:
> Petr Vandrovec ([email protected]) wrote:
> > On Sat, Dec 07, 2002 at 02:14:24PM +0100, Tomas Szepe wrote:
> >> > > IMO, yes, since those tools provide the summary, and exist almost purely in
> >> > > userspace. I forgot to mention in the orginal email that we could also drop
> >> > > the PCI names database, right? This would save a considerable amount in the
> >> > > kernel image alone..
> >> >
> >> > If you want, make it user configurable like it was during 2.2.x. But
> >> > I personally prefer descriptive names and system overview I can parse
> >> > without having mounted /usr to get working lspci.
> >>
> >> Actually I'm inclined to insist that lspci belong in /sbin. Really. :)
> >
> > Try it. At least on Debian it is useless without name database, which lives in
> > /usr/share/misc/pci.ids... I can read numbers directly from /proc/bus/pci, if
> > I want numbers.
>
> Hmmmm, on SuSE 8.0 too. I consider this a bug. Or at least a misfeature.
> Binaries in /bin and /sbin should not need anything from /usr.
Originally pci.ids was in /etc/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Linus Torvalds wrote:
> - we should _never_ update the PCI_INTERRUPT_LINE register, because it
> destroys boot loader information (the same way we need to not overwrite
> BIOS extended areas and ACPI areas etc in order to be able to reboot
> cleanly)
I don't think the kernel presently does this, but if it
were to actually do the chipset-specific programming change the IRQ
routing of a device, it should update PCI_INTERRUPT_LINE precisely
so that the information will be passed on across a soft reboot.
This comes up for me because I have daone motherobard with a
BIOS that never programs the USB controller's interrupt line, so I
have to do the chipset-specific bit twiddling (which, in this case
happens to be simply writing the desired irq into the device's
PCI_INTERRUPT_LINE register anyhow). By the way, I also had to change
arch/i386/kernel/pci.c to get it to reread PCI_INTERRUPT_LINE if it
thought the interrupt was not routed, although all that I would really
need is some way for a user level program to persuade the kernel to
believe that a particular PCI device's interrupt line A has changed to
irq n.
This exception is probably not relevant to what Linus and
Richard are discussing, but I thought should mention it, lest that
"_never_" be interpreted too absolutely.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
> > It just reports what's in the PCI_INTERRUPT_LINE register.
>
> That's wrong, then.
Actually, it doesn't. IIUC, it gets it from /proc/bus/pci/devices. That
info is formatted in drivers/pci/proc.c::show_device().
> > At least on Alpha, we wrote into this register during pci
> > configuration, so the value matches what's in /proc/interrupts.
> > I guess I always assumed we did the same on x86, but I've
> > never checked.
>
> It _shouldn't_ be done. The PCI_INTERRUPT_LINE register is just a byte,
> which isn't even _enough_ to identify the irq "for real" on many
> architectures. It's also a totally different namespace at least on x86
> machines: the PCI_INTERRUPT_LINE register should contain the "legacy
> interrupt", while the remapped interrupt will depend on whether the
> io-apic is enabled or not.
>
> Writing it back is actively _bad_, since it will make it very hard to
> re-boot the machine without the BIOS re-enumarating the PCI bus and
> filling it in again (ie it would definitely screw up using things like
> kexec() on PC's, if the kernel we boot _from_ is an APIC kernel, but the
> kernel we boot _into_ is not).
I couldn't find any place that ia32 writes the PCI_INTERRUPT_LINE register
during boot. And, manually reading in various places (before, during, and
after enabling a device) always returned the same info.
> So the rule should be:
> - the PCI config space is _not_ the same as "pci->irq"
> - we should _never_ update the PCI_INTERRUPT_LINE register, because it
> destroys boot loader information (the same way we need to not overwrite
> BIOS extended areas and ACPI areas etc in order to be able to reboot
> cleanly)
> - we need _some_ way of getting the "kernel irq line" from /sys or /proc.
>
> Sounds like /proc/pci still does something for us. Or is the info
> available in /proc/bus/pci/devices?
AFAICT, lspci is getting it from /proc/bus/pci/devices. I'm getting the
source now to sift through and verify. Alternatively, the data is also
available in the 'irq' file in each PCI device's sysfs directory.
-pat
[email protected] (Kai Henningsen) writes:
> I use cat /proc/pci for the same reason I use cat /proc/scsi - when
> configuring a box, or adding new hardware, to figure out what I should
> look for and where it is.
Still there is lspci. Much better than just a file in /proc, in fact:
you can have short or long output, and you always have device and
vendor names (with /proc/pci it isn't true).
As long as the database contains the names, of course (the same as with
kernel, with the difference that it doesn't use kernel space).
> I don't particularly care which part of the file system this omes from,
> but I do care about being able to find it quickly, and about it being easy
> (i.e. not need looking at 7868 separate files) and giving the essential
> info (which is the info that can be found in the relevant docs or be fed
> to google).
Same as "ps xaf". I usually don't look at /proc/*/cmdline etc either.
This doesn't mean I want a file in /proc which contains "ps axf" output.
Anyway, /proc/pci is currently broken (the kernel don't know what
hot-pluggable devices will you use, and doesn't preserve the necessary
names). If we want it in /proc, could it be corrected?
I always thought of /proc/pci as of temporary q&d debug tool.
--
Krzysztof Halasa
Network Administrator
On Sun, 8 Dec 2002, Richard Henderson wrote:
>
> It just reports what's in the PCI_INTERRUPT_LINE register.
That's wrong, then.
> At least on Alpha, we wrote into this register during pci
> configuration, so the value matches what's in /proc/interrupts.
> I guess I always assumed we did the same on x86, but I've
> never checked.
It _shouldn't_ be done. The PCI_INTERRUPT_LINE register is just a byte,
which isn't even _enough_ to identify the irq "for real" on many
architectures. It's also a totally different namespace at least on x86
machines: the PCI_INTERRUPT_LINE register should contain the "legacy
interrupt", while the remapped interrupt will depend on whether the
io-apic is enabled or not.
Writing it back is actively _bad_, since it will make it very hard to
re-boot the machine without the BIOS re-enumarating the PCI bus and
filling it in again (ie it would definitely screw up using things like
kexec() on PC's, if the kernel we boot _from_ is an APIC kernel, but the
kernel we boot _into_ is not).
So the rule should be:
- the PCI config space is _not_ the same as "pci->irq"
- we should _never_ update the PCI_INTERRUPT_LINE register, because it
destroys boot loader information (the same way we need to not overwrite
BIOS extended areas and ACPI areas etc in order to be able to reboot
cleanly)
- we need _some_ way of getting the "kernel irq line" from /sys or /proc.
Sounds like /proc/pci still does something for us. Or is the info
available in /proc/bus/pci/devices?
Linus
On Sat, Dec 07, 2002 at 03:46:58PM -0200, Arnaldo Carvalho de Melo wrote:
> Em Sat, Dec 07, 2002 at 01:15:59PM +0000, Dr. David Alan Gilbert escreveu:
> > * Erik Hensema ([email protected]) wrote:
> > >
> > > Every half-decent installer autodetects all PCI devices. AND had lspci
> > > installed in the install image.
> >
> > Yes, but wait till you find yourself stuck on a weird embedded board
> > with a small flash and a serial console and you are trying to debug the
> > PCI device you've built.
>
> In this weird embedded board with small flash it'd be lovely to save one
> more page (or perhaps more) in the kernel image, no? :-)
Agreed. But -=*if*=- I want to.
I would personally prefer to spend the page in the (compressed in flash!)
kernel image than the nine pages or so for "lspci" (possibly compressed
as well).
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
Em Mon, Dec 09, 2002 at 08:03:19PM +0100, Rogier Wolff escreveu:
> On Sat, Dec 07, 2002 at 03:46:58PM -0200, Arnaldo Carvalho de Melo wrote:
> > Em Sat, Dec 07, 2002 at 01:15:59PM +0000, Dr. David Alan Gilbert escreveu:
> > > * Erik Hensema ([email protected]) wrote:
> > > >
> > > > Every half-decent installer autodetects all PCI devices. AND had lspci
> > > > installed in the install image.
> > >
> > > Yes, but wait till you find yourself stuck on a weird embedded board
> > > with a small flash and a serial console and you are trying to debug the
> > > PCI device you've built.
> >
> > In this weird embedded board with small flash it'd be lovely to save one
> > more page (or perhaps more) in the kernel image, no? :-)
>
> Agreed. But -=*if*=- I want to.
>
> I would personally prefer to spend the page in the (compressed in flash!)
> kernel image than the nine pages or so for "lspci" (possibly compressed
> as well).
wow, is lspci so bloated? 8) And I didn't objected to having it as a user
selectable option :-)
- Arnaldo
On Mon, Dec 09, 2002 at 09:00:44AM -0800, Linus Torvalds wrote:
> On 9 Dec 2002, Alan Cox wrote:
> >
> > I wonder if this is why we have all these problems with VIA chipset
> > interrupt handling. According to VIA docs they _do_ use
> > PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
> > between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"
>
> Whee.. That sounds like a load of crock in the first place, since the
> PCI_INTERRUPT_LINE thing should be just a scratch register as far as I
> know. However, it doesn't really matter - we definitely should never write
> to it anyway, so the VIA behaviour while strange should still be
> acceptable.
I can confirm that on most builtin VIA southbridge devices (namely USB)
the register isn't just a scratch register and that indeed it is used by
the interrupt router.
> Anyway, to get back on the original discussion, I think we should remove
> the writing, and then make sure that /sbin/lspci (or some other tool) can
I guess only the irq re-routing code specific to VIA would then write
those values, because it has to if the BIOS didn't set them up correctly.
> be made to easily show either the kernel irq mapping value _or_ the
> "original PCI config space" value. At that point I'd agree that /proc/pci
> has outlived its usefulness.
>
> (Although I still think the name database is nice to have - I certainly
> prefer it over having a lot of drivers having their _own_ name databases
> for printout purposes).
It definitely made many drivers simpler.
--
Vojtech Pavlik
SuSE Labs
On Mon, 2002-12-09 at 18:11, Linus Torvalds wrote:
> That's definitely where it should be - the behaviour of the
> PCI_INTERRUPT_LINE register is clearly chip-specific, so it should be in
> the chip-specific drivers..
>
> It's a kind of strange behaviour, though. What chip is this? It sounds
> kind of convenient, but as far as I can tell it can only work for those
> kinds of PCI devices that are on the same chip as the irq controller..
VIA bridges. In my case its a CLE266 (onchip video, 5.1 audio, ide, usb,
firewire, ethernet, floppy, serial, irda. parallel...) [See why I don't
want to hack each driver 8)]
On 10 Dec 2002, Alan Cox wrote:
> On Mon, 2002-12-09 at 18:11, Linus Torvalds wrote:
> > That's definitely where it should be - the behaviour of the
> > PCI_INTERRUPT_LINE register is clearly chip-specific, so it should be in
> > the chip-specific drivers..
> >
> > It's a kind of strange behaviour, though. What chip is this? It sounds
> > kind of convenient, but as far as I can tell it can only work for those
> > kinds of PCI devices that are on the same chip as the irq controller..
>
> VIA bridges. In my case its a CLE266 (onchip video, 5.1 audio, ide, usb,
> firewire, ethernet, floppy, serial, irda. parallel...) [See why I don't
> want to hack each driver 8)]
Oh, I didn't mean each sub-chip driver, I meant the "southbridge driver".
Right now that's really only the PIRQ table mini-driver (all ten lines of
it ;)
Sadly, we do _not_ have a really good generic model for setting interrupt
lines. The PIRQ stuff comes closest to a driver model, but it gets
disabled by the MP table parsing, and then we don't have anything good to
fall back on, I'm afraid.
Linus
Alan Cox <[email protected]> writes:
> On Mon, 2002-12-09 at 17:00, Linus Torvalds wrote:
> > On 9 Dec 2002, Alan Cox wrote:
> > > I wonder if this is why we have all these problems with VIA chipset
> > > interrupt handling. According to VIA docs they _do_ use
> > > PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
> > > between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"
> >
> > Whee.. That sounds like a load of crock in the first place, since the
> > PCI_INTERRUPT_LINE thing should be just a scratch register as far as I
> > know. However, it doesn't really matter - we definitely should never write
> > to it anyway, so the VIA behaviour while strange should still be
> > acceptable.
>
> Tested and verified. If I leave it alone non apic mode works. To use
> APIC mode I have to write the new IRQ value into that register. I've
> shoved that into the driver for now, since its a demented chip specific
> horror.
Think you can put in a reboot notifier/device shutdown method to restore
it to it's old value, so kexec has a chance of working correctly with
this hardware.
Eric
Hi Linus!
> Just out of interest, where _does_ it get the information? Does it try to
> do its own irq routing (bad!) or does it do it from /proc/bus/pci/devices?
The latter (unless you use `lspci -b' which reads the config registers
directly) and it's doing it this way since the first version ;)
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Anything is good and useful if it's made of chocolate.
kernel 2.4.20 inbuilt isapp returns false data:
-----------------------------------------------
from /var/log/messages
sb creative 'vibra16',
1) non-functional with isapnp by kernel:
kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
kernel: sb: Creative ViBRA16X PnP detected
Dec 2 18:16:57 Lux3 kernel: sb: ISAPnP reports 'Creative ViBRA16X PnP' at
i/o 0x220, irq 10, dma 1, 3
kernel: SB 4.16 detected OK (220)
kernel: SB16: Bad or missing 16 bit DMA channel
Dec 2 18:16:57 Lux3 kernel: sb: 1 Soundblaster PnP card(s) found.
------------------------------------------------
2) all but /dev/sndstat (which worked w. 2.4.19, same set-up)
if kernel-isapnp disabled and, configured after <pnpdump> otput:
kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
kernel: SB 4.16 detected OK (220)
kernel: <Sound Blaster 16 (4.16)> at 0x220 irq 7 dma 1,5
kernel: <Sound Blaster 16> at 0x330 irq 7 dma 0,0
kernel: YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft
1993-1996
kernel: <Yamaha OPL3> at 0x388
kernel: MIDI Loopback device driver
# -----------------------------------
system, <ver_linux>:
---
Linux Lux3 2.4.20 #2 Sat Dec 7 09:50:48 GMT 2002 i586 unknown
---
C compiler 2.95.4
make 3.79.1
binutils 20020814
util-linux v2.11n
mount 2.11n
modutils 2.4.15
e2fsprogs 1.27
ppp 2.4.1
isdn4k-utils 3.1pre4
C library 2.2.5
dynamic linker (ldd) 2.2.5
procps 2.0.7
net-tools 1.60
console-tools 0.2.3
sh-utils 2.0.11
modules isdn_bsdcomp hisax isdn ipchains bridge romfs nls_utf8
nls_koi8-u nls_koi8-ru nls_koi8-r nls_iso8859-7 nls_iso8859-5 nls_iso8859-4
nls_iso8859-15 nls_iso8859-14 nls_iso8859-13 nls_iso8859-1 nls_gb2312
nls_cp936 nls_cp866 nls_cp865 nls_cp864 nls_cp855 nls_cp852 nls_cp850
nls_cp775 nls_cp437 nls_cp1251 nls_cp1250 nls_cp950 nls_big5 minix autofs acm
usbcore v_midi opl3 sb sb_lib uart401 sound soundcore 8139too mii nbd
# -----------------------------------
statistics (after pnpdump config, only):
cat /dev/sndstat:
-----------------
-/-
cat /proc/modules:
------------------
isdn_bsdcomp 5888 0
hisax 131104 29 (autoclean)
isdn 115200 30 (autoclean) [isdn_bsdcomp hisax]
ipchains 35876 0 (unused)
bridge 15308 0 (unused)
romfs 3584 0 (unused)
nls_utf8 800 0 (unused)
...(more lang. mods)
nls_koi8-u 3872 1 (autoclean)
nls_iso8859-13 3392 0 (unused)
nls_iso8859-1 2880 2
minix 18176 0 (unused)
autofs 8932 0 (unused)
acm 5024 0 (unused)
usbcore 53536 0 [acm]
v_midi 4992 0 (unused)
opl3 10792 0 (unused)
sb 1792 0
sb_lib 32288 0 [sb]
uart401 6048 0 [sb_lib]
sound 52588 0 [v_midi opl3 sb_lib uart401]
soundcore 3460 7 [sb_lib sound]
8139too 13376 1
mii 2224 0 [8139too]
nbd 14944 0 (unused)
cat /proc/interrupts:
---------------------
CPU0
0: 44823924 XT-PIC timer
1: 1045591 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 5026848 XT-PIC HiSax
7: 350 XT-PIC soundblaster
8: 3 XT-PIC rtc
10: 0 XT-PIC eth0
12: 3054844 XT-PIC PS/2 Mouse
14: 147687 XT-PIC ide0
15: 1403251 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0
cat /proc/ioports:
------------------
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0220-022f : soundblaster
0240-0240 : HiSax hscx A fifo
02f8-02ff : serial(set)
0330-0333 : MPU-401 UART
0376-0376 : ide1
0378-037a : parport0
0388-038b : Yamaha OPL3
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
0640-065f : HiSax hscx A
0a40-0a40 : HiSax hscx B fifo
0cf8-0cff : PCI conf1
0e40-0e5f : HiSax hscx B
1240-1240 : HiSax isac fifo
1640-165f : HiSax isac
1a40-1a47 : avm cfg
5c20-5c3f : Acer Laboratories Inc. [ALi] M7101 PMU
d400-d40f : Acer Laboratories Inc. [ALi] M5229 IDE
d400-d407 : ide0
d408-d40f : ide1
d800-d8ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
d800-d8ff : 8139too
cat /proc/dma:
1: SoundBlaster8
4: cascade
5: SoundBlaster16