All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Jeff Garzik <jgarzik@pobox.com>, linux-kernel@vger.kernel.org
Subject: Re: PCI and MWI
Date: Tue, 04 Mar 2003 10:15:44 -0800	[thread overview]
Message-ID: <3E64ED50.2030305@pacbell.net> (raw)
In-Reply-To: 20030302192215.A645@localhost.park.msu.ru

Ivan Kokshaysky wrote:
> David Brownell wrote:
> 
>> I wonder if it might not be best to
>>have cpuinfo_x86 store that value; people don't really expect
>>to see cpu-specific logic in the pci code.
> 
> 
> Don't know. The cpuinfo_x86 is per-CPU thing, while pci_cache_line_size
> is definitely system-wide.

So pci_cache_line_size = max (all L1 cacheline sizes in the system)
with some possible fudging (that i486 issue, etc).  But your patch
would seem to handle most archs correctly already.


>>One minor curiousity:  a multifunction device seemed to share
>>PCI_CACHE_LINE_SIZE between the enabled/active function and ones
>>without a driver.  Makes sense, the values can never legally
>>differ, but some more troublesome devices don't do that...
> 
> 
> Hmm, we treat each function as an independent PCI device, as per PCI
> spec. Sharing the config space between functions sounds like a severe
> hardware bug. Do you have any examples?

I just happened to notice _this specific case_ which as I mentioned
sure doesn't feel like a hardware bug to me!  The specific device
was a Philips ISP 1561 USB 2.0 controller (two OHCI one EHCI), and
the two more troublesome (less forgiving) devices were from VIA.

So that machine had quite a few high speed USB controllers (including
a NetChip 2280 :) running Linux, all using MWI and no particular
problems being visible ... and no messages about broken BIOS setup.


>>Re Jeff's suggestion to merge this to 2.5 ASAP, sounds right
>>to me if all the arch code gets worked out up front.  I have
>>no problem with the idea of enabling it as done here (when
>>the device is enabled) rather than waiting to enable DMA,
>>though I'd certainly pay attention to people who know about
>>devices broken enough to get indigestion that way.
> 
> 
> Well, in 2.4 on Alpha and ARM we still have pdev_enable_device() thing
> which is the mostly __init-only variant of the pci_enable_device(),
> but it also forces correct cacheline size and reasonable (more or less)
> latency timer for *all* devices. Nobody had problems with it over the last
> 2 years, so I believe that setting cacheline size in pci_enable_device()
> rather than in pci_set_master() is the right thing (and agrees with the
> spec better).

Sounds good to me then.

- Dave




      reply	other threads:[~2003-03-04 17:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3E4622B0.7040201@pobox.com>
     [not found] ` <20030210151813.B12043@jurassic.park.msu.ru>
     [not found]   ` <3E47DF75.20801@pacbell.net>
     [not found]     ` <3E5B1C08.6030906@pacbell.net>
     [not found]       ` <3E5C2368.6010502@pobox.com>
     [not found]         ` <20030226160403.A15729@jurassic.park.msu.ru>
2003-03-01  0:44           ` PCI and MWI David Brownell
2003-03-02 16:22             ` Ivan Kokshaysky
2003-03-04 18:15               ` David Brownell [this message]

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=3E64ED50.2030305@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.