From: Sergei Shtylyov <sshtylyov@ru•mvista.com>
To: Valentine Barshak <vbarshak@ru•mvista.com>
Cc: linuxppc-dev@ozlabs•org
Subject: Re: [PATCH 3/4] PowerPC: Add PCI entry to 440EPx Sequoia DTS.
Date: Mon, 07 Apr 2008 17:30:48 +0400 [thread overview]
Message-ID: <47FA2208.6090107@ru.mvista.com> (raw)
In-Reply-To: <47FA1B20.40609@ru.mvista.com>
Hello.
Valentine Barshak wrote:
>>> --- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2007-12-21
>>> 17:14:17.000000000 +0300
>>> +++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-12-21
>>> 17:18:32.000000000 +0300
>>> @@ -324,6 +324,33 @@
>>> has-new-stacr-staopc;
>>> };
>>> };
>>> +
>>> + PCI0: pci@1ec000000 {
>>> + device_type = "pci";
>>> + #interrupt-cells = <1>;
>>> + #size-cells = <2>;
>>> + #address-cells = <3>;
>>> + compatible = "ibm,plb440epx-pci", "ibm,plb-pci";
>>> + primary;
>>> + reg = <1 eec00000 8 /* Config space access */
>>> + 1 eed00000 4 /* IACK */
>>> + 1 eed00000 4 /* Special cycle */
>>> + 1 ef400000 40>; /* Internal registers */
>>> +
>>> + /* Outbound ranges, one memory and one IO,
>>> + * later cannot be changed. Chip supports a second
>>> + * IO range but we don't use it for now
>>> + */
>>> + ranges = <02000000 0 80000000 1 80000000 0 10000000
>> I wonder why the AMCC's Sequoia/Rainier manual has PCI memory
>> mapped at 0x80000000-0xbfffffff? The 0x80000000-0x8fffffff mapping was
>> assumed by arch/ppc/ code. What/why changed here?
> The addresses in the manual are relative to bus base.
Hm, that's hard to infer from the manual, and even from arch/ppc/ sources...
> PCI controller is
> located on the PLB and PLB base address is 0x100000000ULL on Sequoia.
The question is where cam one read about that. :-)
> Older PPC code has ioremap64 function that did the 64 to 32-bit trick
Ah, seeing fixup_bigphys_addr() at last -- it has escaped me before...
> It's been abolished. The kernel has support for 64-bit physical
> addresses on 32-bit. IMHO there's no big reason to keep doing that
> address trick. However, there are some drivers that use unsigned long
> for storing physical addresses. This is wrong, since
> pci_resource_start() returns a resource_size_t value. I think it's these
> drivers that have to be fixed instead of adding workarounds to ppc4xx code.
Well, I'm not arguing with that. Just tried to clarify the PCI mapping
thing for myself. :-)
>> As we now both know, having PCI memory space mapped beyound 4 GB
>> makes some drivers misbehave as they use 'unsigned long' to store the
>> result of pci_resource_start() and later ioremap() this truncated
>> value -- which is 64-bit on Sequoia due to CONFIG_RESOURCE_64BIT=y
>> that is needed to store the beyond-4GB addresses.
Luckily, this one concerns the memory resources, as the I/O resources are
actually limited to 'unsigned long' anyway...
WBR, Sergei
next prev parent reply other threads:[~2008-04-07 13:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-21 16:07 [PATCH 0/4] PowerPC: more Sequoia/Rainier updates for 2.6.25 Valentine Barshak
2007-12-21 16:22 ` [PATCH 1/4] PowerPC: Correct 440GRx machine_check callback Valentine Barshak
2007-12-21 16:24 ` [PATCH 2/4] PowerPC: update 440EP(x)/440GR(x) identical PVR issue workaround Valentine Barshak
2007-12-21 16:43 ` Josh Boyer
2007-12-21 19:47 ` Valentine Barshak
2007-12-21 19:56 ` Stefan Roese
2007-12-24 12:51 ` Valentine Barshak
2007-12-21 16:26 ` [PATCH 3/4] PowerPC: Add PCI entry to 440EPx Sequoia DTS Valentine Barshak
2007-12-21 21:21 ` Benjamin Herrenschmidt
2007-12-22 5:53 ` Stefan Roese
2008-04-05 16:30 ` Sergei Shtylyov
2008-04-07 13:01 ` Valentine Barshak
2008-04-07 13:30 ` Sergei Shtylyov [this message]
2007-12-21 16:27 ` [PATCH 4/4] PowerPC: Add PCI node to 440GRx Rainier DTS Valentine Barshak
2007-12-21 17:19 ` Valentine Barshak
2007-12-21 17:22 ` [PATCH 4/4] PowerPC: Add PCI entry " Valentine Barshak
2007-12-21 21:21 ` [PATCH 4/4] PowerPC: Add PCI node " Benjamin Herrenschmidt
2007-12-22 5:54 ` Stefan Roese
2007-12-22 5:58 ` Benjamin Herrenschmidt
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=47FA2208.6090107@ru.mvista.com \
--to=sshtylyov@ru$(echo .)mvista.com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=vbarshak@ru$(echo .)mvista.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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