All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Horton <pdh@colonel-panic.org>
To: linux-mips@linux-mips.org
Subject: PCI resources on 2.6 [Cobalt Qube]
Date: Sun, 8 Feb 2004 13:16:29 +0000	[thread overview]
Message-ID: <20040208131629.GA7276@skeleton-jack> (raw)

Hi.

I'm working to get the 2.6 kernel booting on the Qube/RaQ, but the PCI
resource stuff is giving me a hard time.

I/O accesses using inb() etc are adjusted by Galileo's PCI I/O base
thus

	00000000 - 0000ffff --> b0000000 - b000ffff

The problem is that Galileo passes I/O addresses straight to PCI so that
a read of the RTC translates to a PCI address of 1000007[01]. This works
fine for the stuff on the VIA south bridge as it doesn't seem to decode
all 32 bits of the address for I/O accesses. But this doesn't work for
the Tulip's, they must have the correct addresses written into the I/O
BAR.

If I change the PCI I/O resource range to 10000000 - 1000ffff, then
inb() etc fail because they add Galileo's PCI I/O base again

	10000000 - 1000ffff --> c0000000 - c000ffff !!

causing a page fault.

If I set the I/O port base to 00000000 to overcome this then accesses to
the peripherals on the VIA south bridge don't get Galileo's PCI I/O base
added and they land up accessing RAM.

I effectively have two I/O ranges that need to map to the same addresses

	00000000 - 0000ffff --> b0000000 - b000ffff (for VIA)
	10000000 - 1000ffff --> b0000000 - b000ffff (for PCI)

I was hopefull that the 'io_offset' field in 'struct pci_controller'
would do this for me, but I can't work out what it does :-|

This all worked in 2.4 as it's actually the boot loader that maps the
Tulip's into the I/O address space and the kernel has hardcoded resource
entries to match.

P.

             reply	other threads:[~2004-02-08 13:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-08 13:16 Peter Horton [this message]
2004-02-08 15:52 ` PCI resources on 2.6 [Cobalt Qube] ilya
2004-02-09 16:15 ` 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=20040208131629.GA7276@skeleton-jack \
    --to=pdh@colonel-panic.org \
    --cc=linux-mips@linux-mips.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.