public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Ralf Baechle <ralf@uni-koblenz.de>
Cc: "chen, xiangping" <chen_xiangping@emc.com>, linux-kernel@vger.kernel.org
Subject: Re: PCI bus speed
Date: 04 Aug 2001 02:10:28 -0600	[thread overview]
Message-ID: <m1lml0w8i3.fsf@frodo.biederman.org> (raw)
In-Reply-To: <276737EB1EC5D311AB950090273BEFDD043BC536@elway.lss.emc.com> <20010803153231.A28624@bacchus.dhis.org>
In-Reply-To: <20010803153231.A28624@bacchus.dhis.org>

Ralf Baechle <ralf@uni-koblenz.de> writes:

> On Thu, Aug 02, 2001 at 06:47:49PM -0400, chen, xiangping wrote:
> 
> > Is there any easy way to probe the PCI bus speed of an Intel box?
> 
> You can find about PCI33 or PCI66 standards but there is no way to find
> the exact clock rate the PCI bus is actually clocked at.  

There is no portable way to find out the bus speed.  If you really
have to you can go in and stick an analyizer on the bus and measure it
but that is no help from  the software point of view.

Additionally there is not requirement that a PCI33 bus even run at
33Mhz  It can legaly run at 15Mhz to save powe if someone wants to,
and as of PCI 2.1 I believe it is perfectly legal to clock even a
PCI66 capable bus with all PCI66 capable cards down to 1Mhz.

As most systems use integrated solutions you can usually do something
like ask the northbridge of the chipset what frequency it is running
the PCI bus at.  This is code that needs to be written for every PCI
host bridge, and probably every PCI<->PCI bridge as well.

With linuxBIOS I might be able to help out a little bit by reporting
motherboard hardcodes but that is likely the most a BIOS can do.
Having a driver that understands how your northbridge chip clocks the
PCI bus goes much farther, to solving this problem.

> Which is a
> problem with certain non-compliant cards; the IOC3 card and a few others
> derive internal clocks from the PCI bus clock rate so will not properly
> work if operated on a bus with different clock rate.

Hmm.  So it looks like we need some kind of interface in linux to
propogate this information from the northbridge chip :(

Eric

  parent reply	other threads:[~2001-08-04  8:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-02 22:47 PCI bus speed chen, xiangping
2001-08-03 13:32 ` Ralf Baechle
2001-08-03 16:42   ` Tim Hockin
2001-08-04  8:10   ` Eric W. Biederman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-08-03 14:27 chen, xiangping
2001-08-03 15:45 ` Ralf Baechle
2001-08-03 15:45 ` Todd
2001-08-03 15:51 ` Richard Gooch
2001-08-03 16:39 ` Tim Hockin
2001-08-03 17:19   ` Richard B. Johnson
2001-08-03 15:52 chen, xiangping

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1lml0w8i3.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=chen_xiangping@emc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ralf@uni-koblenz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox