All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: wlacey <wlacey@goldenhindresearch.com>, linux-mips@linux-mips.org
Subject: Re: No PCI_AUTO in 2.6...
Date: Wed, 15 Dec 2004 19:42:13 +0100	[thread overview]
Message-ID: <20041215184213.GB32491@linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.58L.0412151648460.2706@blysk.ds.pg.gda.pl>

On Wed, Dec 15, 2004 at 05:17:14PM +0000, Maciej W. Rozycki wrote:

>  I know and I consider it a bug.  The correct way would be setting the 
> start at 0 and if avoiding the first kB of space was necessary, setting 
> PCIBIOS_MIN_IO to 0x1000.

PCIBIOS_MIN_IO is the same value for all busses.  That can turn out a bit
kludgy so I'm not much of a friend of it.

> > This makes it look like the legacy ports are not behind the PCI bus
> > which actually they are but that's a minor nit, it gets the address
> > space allocation to work right.
> 
>  I think it's going to matter if a PCI-ISA bridge is behind one or more
> PCI-PCI bridges.  I have an idea of a fix, but my initial approach haven't
> worked particularly well and I've had no time to dig into it further.  
> Actually, on systems with PCI I think reserving legacy resources should
> happen only after they have been discovered (you don't need any PC/AT or
> ISA devices for a PCI configuration space scan), but that may be tough, so
> I've thought of an alternative.

The evil about legacy devices is "they're just there".  That is you have
to know about their existence and in some case can't even do real probing
or the device will react in really nasty ways.

The existence of an ELCR register is not documented for this machine.
Anyway, the approach I've choosen is safe even we it exists.

>  Also the map of legacy resources reserved is actually incomplete -- PIC's
> ELCR is missing for example.
> 
> > >  Things start being tricky once you have to use such an offset for DMA
> > > transfers as well...
> > 
> > True, but that's dealt with elsewhere.  And I never claimed the mess that
> > PCI used to be in 2.4 has yet been fully cleaned up yet, more work to do.
> 
>  Sure, I'm more or less happy about the new code.  I'm just warning about 
> possible pitfalls.
> 
>  There is one more problem with the PCI resource manager -- it messes with
> BARs of host bridges without asking for permission (which is often a
> no-no, as any messing with host bridges in general).  I have a patch for
> it I'm currently trying to push to the PCI maintainer.  See the thread at
> "http://www.uwsg.iu.edu/hypermail/linux/kernel/0412.1/0484.html" if
> interested.  It's already being done correctly for i386 (some would
> probably argue that's what's most important) and ppc which use their own
> resource managers instead of the generic one.

That's a problem on many system controllers such as the GT-64120, all the
other Galileo / Marvell stuff and more.  The hackish solution of doing it
in the pci_ops we're currently isn't a good one.

A comment on your patch.  For most configurations it's ok and certainly
better than hacking the pci_ops.  At least on the GT-64120 it's possible
to configure the device as a memory device and that will make your patch
fail.  Also there is the case where the GT-64120 or similar system
controllers are used on a PCI card.  For the CPU on the card it'll be
the host bridge; for the host system just yet another PCI device.

  Ralf

  reply	other threads:[~2004-12-15 18:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-11 13:43 No PCI_AUTO in 2.6 wlacey
2004-12-15 13:56 ` Ralf Baechle
2004-12-15 15:25   ` Maciej W. Rozycki
2004-12-15 16:40     ` Ralf Baechle
2004-12-15 17:17       ` Maciej W. Rozycki
2004-12-15 18:42         ` Ralf Baechle [this message]
2004-12-15 19:29           ` Maciej W. Rozycki
2004-12-16  2:17           ` Atsushi Nemoto
2004-12-16 12:56             ` Ralf Baechle

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=20041215184213.GB32491@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=wlacey@goldenhindresearch.com \
    /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.