From: Michel Lanners <mlan@cpu.lu>
To: schmitz@opal.biophys.uni-duesseldorf.de
Cc: geert@linux-m68k.org, michdaen@iiic.ethz.ch, paubert@iram.es,
bh40@calva.net, linuxppc-dev@lists.linuxppc.org
Subject: Re: LongTrail PCI resource assignment
Date: Tue, 4 Apr 2000 08:01:51 +0200 (CEST) [thread overview]
Message-ID: <200004040601.IAA00488@piglet.grunz.lu> (raw)
In-Reply-To: <Pine.LNX.4.10.10004031854280.15106-200000@opal.biophys.uni-duesseldorf.de>
Hi there,
On 3 Apr, this message from Michael Schmitz echoed through cyberspace:
>> > - OF reports two base addresses for the Mach64, one of which is the I/O
>> > region (according to the PCI BAR values) at 0xc00. OF reports its address
>> ^^^^^
>> Where does that address come from? I'm missing something here..
>
> Straight from the BAR for region 1, with the resource type bits masked
> off. BTW lspci also reports this.
Ahhh... ok. In that case, it's a possible value.
>> > as 0x80881000 or some such. Does this mean the I/O registers are
>> > accessible at 0x80881000, or did OF probing get some bogus values there?
When looking at what OF assigned, always check the BAR value in OF's
properties; they are not necessarily all in the same order all the
time. Here's for example what I have on my machine for my Matrox:
[mlan@piglet /proc/device-tree/bandit/MTRX,Millennium@F]$ hexdump reg
0000000 0000 7800 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0200 7810 0000 0000 0000 0000
0000020 0000 0000 0000 4000 4200 7814 0000 0000
0000030 0000 0000 0000 0000 0080 0000
000003c
[mlan@piglet /proc/device-tree/bandit/MTRX,Millennium@F]$ hexdump assigned-addresses
0000000 c200 7814 0000 0000 8100 0000 0000 0000
0000010 0080 0000 8200 7810 0000 0000 8080 0000
0000020 0000 0000 0000 4000
0000028
The reg property has 3 entries, where the second and third represent
BARs at 0x10 and 0x14; however, assigned-addresses has these in reverse
order...
If you look at your properties, here is their meaning:
<flags> <bus-hi> <bus-lo> <processor> <size>
All elements are 32 bits; the BAR value is in the last byte of <flags>.
You'll see that in reg, <processor> is not set; that's because reg
represents the address requests of the device before attribution.
<bus-hi> and <bus-lo> form a 64-bit PCI bus address; on 32-bit systems,
<bus-hi> is zero. assigned-addresses is what OF gave your device.
> 0xfe000000 is what pmac_pci.c uses for my machine (processor physical as
> well as virtual). I'm not trying to change that, I just didn't understand
> the address reported by OF for that region. I still don't understand it.
Can you verify your OF properties, to check whether OF _really_ assigned
a region for the IO ports at 0xc00? I doubt it...
>> If you remap the MMIO range, you need to do two things:
>>
>> 2. change the values stored in struct pci_dev, so that the kernel at
>> large (that includes other drivers, and the interface used by lspci)
>> knows about it.
>
> That's what I missed. I changed the value in the OF tree but forgot the
> PCI side.
Changing the OF device tree is nice, but probably too much hassle.
The struct pci_dev, on the other hand, is vital.
Have fun!
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-04-04 6:01 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-22 8:27 LongTrail PCI resource assignment Geert Uytterhoeven
2000-03-22 10:24 ` Michel Lanners
2000-03-22 10:43 ` Geert Uytterhoeven
2000-03-22 13:15 ` Benjamin Herrenschmidt
2000-03-23 7:41 ` Michel Lanners
2000-03-23 10:13 ` Benjamin Herrenschmidt
2000-03-23 19:22 ` Michel Lanners
2000-03-24 8:49 ` Timothy A. Seufert
2000-03-24 9:02 ` Geert Uytterhoeven
2000-03-24 9:54 ` Benjamin Herrenschmidt
2000-03-24 10:56 ` Michael Schmitz
2000-03-24 12:26 ` Geert Uytterhoeven
2000-03-24 13:36 ` Michael Schmitz
2000-03-24 13:48 ` Geert Uytterhoeven
2000-03-24 12:37 ` Geert Uytterhoeven
2000-03-24 13:27 ` Michael Schmitz
2000-03-24 13:34 ` Geert Uytterhoeven
2000-03-24 16:07 ` Michael Schmitz
2000-03-24 13:35 ` Gabriel Paubert
2000-03-24 13:48 ` Michael Schmitz
2000-03-24 14:10 ` Benjamin Herrenschmidt
2000-03-24 15:56 ` Gabriel Paubert
2000-03-24 17:40 ` Michael Schmitz
2000-03-24 17:51 ` Gabriel Paubert
2000-03-24 18:43 ` Michael Schmitz
2000-03-24 20:03 ` Gabriel Paubert
2000-03-24 21:37 ` Michael Schmitz
2000-03-25 13:35 ` Geert Uytterhoeven
2000-03-25 15:13 ` Michael Schmitz
2000-03-27 8:57 ` Michael Schmitz
2000-03-27 9:43 ` Michel Dänzer
2000-03-27 9:58 ` Michael Schmitz
2000-03-27 10:38 ` Geert Uytterhoeven
2000-03-29 20:05 ` Geert Uytterhoeven
2000-03-30 20:59 ` Michael Schmitz
2000-04-03 8:58 ` Michel Lanners
2000-04-03 18:42 ` Michael Schmitz
2000-04-04 6:01 ` Michel Lanners [this message]
2000-03-27 11:33 ` Kostas Gewrgiou
2000-03-27 11:46 ` Michael Schmitz
2000-03-27 12:04 ` Geert Uytterhoeven
2000-03-27 11:51 ` Geert Uytterhoeven
2000-03-27 11:58 ` Michael Schmitz
2000-03-27 12:04 ` Michel Dänzer
2000-03-27 11:41 ` Michel Dänzer
2000-03-27 9:50 ` Geert Uytterhoeven
2000-03-27 10:01 ` Michael Schmitz
2000-03-27 10:35 ` Geert Uytterhoeven
2000-03-27 11:34 ` Michael Schmitz
2000-03-27 11:54 ` Geert Uytterhoeven
2000-03-27 16:55 ` Michael Schmitz
2000-03-27 18:58 ` Michel Lanners
2000-03-27 20:03 ` Michael Schmitz
2000-03-27 21:03 ` Michel Lanners
2000-03-27 11:46 ` Michel Lanners
2000-03-25 14:15 ` Michel Dänzer
2000-03-25 13:28 ` Geert Uytterhoeven
2000-03-25 14:36 ` Michael Schmitz
2000-03-24 22:16 ` Michel Lanners
2000-03-24 9:43 ` Benjamin Herrenschmidt
2000-03-24 22:13 ` Michel Lanners
2000-03-24 13:12 ` Benjamin Herrenschmidt
2000-03-24 22:41 ` Michel Lanners
2000-03-22 13:18 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2000-03-24 15:42 Michel D?nzer
2000-03-24 16:30 ` Michael Schmitz
2000-03-24 17:17 ` Benjamin Herrenschmidt
2000-03-24 18:27 ` Michael Schmitz
2000-03-25 13:31 ` Geert Uytterhoeven
2000-03-25 14:28 ` Michel Dänzer
2000-03-25 14:49 ` Geert Uytterhoeven
2000-03-26 8:45 ` Michel Dänzer
2000-03-25 15:39 ` Michael Schmitz
2000-03-26 8:58 ` Michel Dänzer
2000-03-27 9:43 ` Michael Schmitz
2000-03-27 11:27 ` Michel Dänzer
[not found] <Pine.GSO.4.10.10003220927550.29557-100000@dandelion.sonytel.be>
2000-03-27 21:12 ` Martin Mares
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=200004040601.IAA00488@piglet.grunz.lu \
--to=mlan@cpu.lu \
--cc=bh40@calva.net \
--cc=geert@linux-m68k.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=michdaen@iiic.ethz.ch \
--cc=paubert@iram.es \
--cc=schmitz@opal.biophys.uni-duesseldorf.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;
as well as URLs for NNTP newsgroup(s).