* Re: Regarding the issue of compiling >=2.6.31 on ppc with >=gcc-4.4
From: Stephen Rothwell @ 2010-07-04 22:26 UTC (permalink / raw)
To: Anthony G. Basile; +Cc: linuxppc-dev, cjg
In-Reply-To: <4C31046C.9060406@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
Hi Anthony,
On Sun, 04 Jul 2010 18:00:12 -0400 "Anthony G. Basile" <blueness@gentoo.org> wrote:
>
> Hi guys, I just hit this in trying to stabilize some kernels on gentoo
> - -> http://bugs.gentoo.org/show_bug.cgi?id=326877. Has there been any
> upstream discussion about this? I haven't seen anything on lkml. I
> thought I'd drop you a note and see if you guys had heard anything.
You should really ask questions like this on the
linuxppc-dev@lists.ozlabs.org mailing list (cc'd).
[For others: this is the 1024 byte buffer in the stack in
chrp_event_scan()]
Having said that: yes, the problem has been noticed, but no solution has
been included yet (as far as I know). There are other issues with
building 64 bit PowerPC kernels with gcc >= 4.5 for which I have proposed
a couple of patches.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 13/27] KVM: PPC: Magic Page Book3s support
From: Avi Kivity @ 2010-07-04 9:42 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C2E07AC.4010801@suse.de>
On 07/02/2010 06:37 PM, Alexander Graf wrote:
> Alexander Graf wrote:
>
>> We need to override EA as well as PA lookups for the magic page. When the guest
>> tells us to project it, the magic page overrides any guest mappings.
>>
>> In order to reflect that, we need to hook into all the MMU layers of KVM to
>> force map the magic page if necessary.
>>
>> Signed-off-by: Alexander Graf<agraf@suse.de>
>>
>> v1 -> v2:
>>
>> - RMO -> PAM
>> ---
>> arch/powerpc/kvm/book3s.c | 7 +++++++
>> arch/powerpc/kvm/book3s_32_mmu.c | 16 ++++++++++++++++
>> arch/powerpc/kvm/book3s_32_mmu_host.c | 12 ++++++++++++
>> arch/powerpc/kvm/book3s_64_mmu.c | 30 +++++++++++++++++++++++++++++-
>> arch/powerpc/kvm/book3s_64_mmu_host.c | 12 ++++++++++++
>> 5 files changed, 76 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
>> index 14db032..b22e608 100644
>> --- a/arch/powerpc/kvm/book3s.c
>> +++ b/arch/powerpc/kvm/book3s.c
>> @@ -554,6 +554,13 @@ mmio:
>>
>> static int kvmppc_visible_gfn(struct kvm_vcpu *vcpu, gfn_t gfn)
>> {
>> + ulong mp_pa = vcpu->arch.magic_page_pa;
>> +
>> + if (unlikely(mp_pa)&&
>> + unlikely((mp_pa& KVM_RMO)>> PAGE_SHIFT == gfn)) {
>>
>>
> This should be KVM_PAM :(. Should I respin the whole thing or could
> whoever commits this just make that trivial change?
>
>
A respin followed by a bisectability test (compile each revision as it
is applied), please. Of course we need to resolve the detection issue
first.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Avi Kivity @ 2010-07-04 9:41 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, linuxppc-dev, KVM list
In-Reply-To: <486564E7-7942-4021-8EB2-67DC4E56580D@suse.de>
On 07/04/2010 12:30 PM, Alexander Graf wrote:
>
>> Considering how the parts of the draft that I read about sound like, that's not the inventor's idea. PPC people love to see the BIOS be part of the virtualization solution. I don't. That's the biggest difference here and reason for us going different directions.
>>
>> I think what they thought of is something like
>>
>> if (in_kvm()) {
>> device_tree_put("/hypervisor/exit", EXIT_TYPE_MAGIC);
>> device_tree_put("/hypervisor/exit_magic", EXIT_MAGIC);
>> }
>>
>> which then the OS reads out. But that's useless, as the hypercalls are hypervisor specific. So why make the detection on the Linux side generic?
>>
> In fact, it's even worse. Right now with KVM for PPC we have 3 different ways of generating the device tree:
>
> 1) OpenBIOS (Mac emulation)
> 2) Qemu libfdt (BookE)
> 3) MOL OF implementation
>
I sympathize. But, if the arch says that's how you do things, then
that's how you do things.
> So I'd have to touch even more projects. Just for the sake of splitting out something that belongs together anyway. And probably even create new interfaces just for that sake (qemu asking the kernel which type of hypercalls the vm should use) even though the guest could just query all that itself.
>
qemu needs to be involved, in case one day you support more than one
type of hypercalls (like x86 does with hyper-v) or if you want to live
migrate from a host that has hypercall support to another host that has
this feature removed (as has already happened on x86 with the pvmmu).
Planning for the future means a lot of boring interfaces.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Avi Kivity @ 2010-07-04 9:37 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, linuxppc-dev, KVM list
In-Reply-To: <40488555-C73E-4C04-BFAD-31ED99CDBBDA@suse.de>
On 07/04/2010 12:17 PM, Alexander Graf wrote:
> On 04.07.2010, at 11:10, Avi Kivity wrote:
>
>
>> On 07/04/2010 12:04 PM, Alexander Graf wrote:
>>
>>> My biggest concern about putting things in the device-tree is that I was trying to keep things as separate as possible. Why does the firmware have to know that it's running in KVM?
>>>
>> It doesn't need to know about kvm, it needs to know that a particular hypercall protocol is available.
>>
> Considering how the parts of the draft that I read about sound like, that's not the inventor's idea. PPC people love to see the BIOS be part of the virtualization solution. I don't. That's the biggest difference here and reason for us going different directions.
>
Regardless of which direction is "correct", you need to go in one direction.
> I think what they thought of is something like
>
> if (in_kvm()) {
> device_tree_put("/hypervisor/exit", EXIT_TYPE_MAGIC);
> device_tree_put("/hypervisor/exit_magic", EXIT_MAGIC);
> }
>
> which then the OS reads out. But that's useless, as the hypercalls are hypervisor specific. So why make the detection on the Linux side generic?
>
Looks like the benefit is less magic in the detection code. x86 has
(more or less) standardized feature detection. Is this an attempt to
bring something similar to ppc-land?
>>> Why do I have to patch 3 projects (Linux, OpenBIOS, Qemu) when I could go with patching a single one (Linux)?
>>>
>>>
>> That's not a valid argument. You patch as many projects as it takes to get it right (not that I have an opinion in this particular discussion).
>>
> If you can put code in Linux that touches 3 submaintainer's directories or one submaintainer's directory with both ending up being functionally equivalent, which way would you go?
>
We would do the right thing. Trivial examples include adding defines to
include/asm/processor.h or include/asm/msr-index.h, more complicated
ones are the topic for my talk in kvm forum 2010.
Yes, coordinating the acks and trees and merge windows is not as fun as
coding. Yes, it's even more difficult with separate trees. No, that's
not an excuse if we[1] determine that the right thing to do is the most
complicated.
[1] "we" in this case are the powerpc Linux arch maintainers and/or
whoever defines the hardware specification
>> At the very least you have to patch qemu for reasons described before (backwards compatible live migration).
>>
> There is no live migration on PPC (yet). That point is completely moot atm.
>
You still need to make that feature disableable from userspace.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Alexander Graf @ 2010-07-04 9:30 UTC (permalink / raw)
To: Alexander Graf; +Cc: KVM list, kvm-ppc, Avi Kivity, linuxppc-dev
In-Reply-To: <40488555-C73E-4C04-BFAD-31ED99CDBBDA@suse.de>
On 04.07.2010, at 11:17, Alexander Graf wrote:
>=20
> On 04.07.2010, at 11:10, Avi Kivity wrote:
>=20
>> On 07/04/2010 12:04 PM, Alexander Graf wrote:
>>>=20
>>> My biggest concern about putting things in the device-tree is that I =
was trying to keep things as separate as possible. Why does the firmware =
have to know that it's running in KVM?
>>=20
>> It doesn't need to know about kvm, it needs to know that a particular =
hypercall protocol is available.
>=20
> Considering how the parts of the draft that I read about sound like, =
that's not the inventor's idea. PPC people love to see the BIOS be part =
of the virtualization solution. I don't. That's the biggest difference =
here and reason for us going different directions.
>=20
> I think what they thought of is something like
>=20
> if (in_kvm()) {
> device_tree_put("/hypervisor/exit", EXIT_TYPE_MAGIC);
> device_tree_put("/hypervisor/exit_magic", EXIT_MAGIC);
> }
>=20
> which then the OS reads out. But that's useless, as the hypercalls are =
hypervisor specific. So why make the detection on the Linux side =
generic?
In fact, it's even worse. Right now with KVM for PPC we have 3 different =
ways of generating the device tree:
1) OpenBIOS (Mac emulation)
2) Qemu libfdt (BookE)
3) MOL OF implementation
So I'd have to touch even more projects. Just for the sake of splitting =
out something that belongs together anyway. And probably even create new =
interfaces just for that sake (qemu asking the kernel which type of =
hypercalls the vm should use) even though the guest could just query all =
that itself.
Alex
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Alexander Graf @ 2010-07-04 9:17 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-ppc, linuxppc-dev, KVM list
In-Reply-To: <4C305001.7060301@redhat.com>
On 04.07.2010, at 11:10, Avi Kivity wrote:
> On 07/04/2010 12:04 PM, Alexander Graf wrote:
>>=20
>> My biggest concern about putting things in the device-tree is that I =
was trying to keep things as separate as possible. Why does the firmware =
have to know that it's running in KVM?
>=20
> It doesn't need to know about kvm, it needs to know that a particular =
hypercall protocol is available.
Considering how the parts of the draft that I read about sound like, =
that's not the inventor's idea. PPC people love to see the BIOS be part =
of the virtualization solution. I don't. That's the biggest difference =
here and reason for us going different directions.
I think what they thought of is something like
if (in_kvm()) {
device_tree_put("/hypervisor/exit", EXIT_TYPE_MAGIC);
device_tree_put("/hypervisor/exit_magic", EXIT_MAGIC);
}
which then the OS reads out. But that's useless, as the hypercalls are =
hypervisor specific. So why make the detection on the Linux side =
generic?
>=20
>> Why do I have to patch 3 projects (Linux, OpenBIOS, Qemu) when I =
could go with patching a single one (Linux)?
>> =20
>=20
> That's not a valid argument. You patch as many projects as it takes =
to get it right (not that I have an opinion in this particular =
discussion).
If you can put code in Linux that touches 3 submaintainer's directories =
or one submaintainer's directory with both ending up being functionally =
equivalent, which way would you go?
>=20
> At the very least you have to patch qemu for reasons described before =
(backwards compatible live migration).
There is no live migration on PPC (yet). That point is completely moot =
atm.
Alex
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Avi Kivity @ 2010-07-04 9:10 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, linuxppc-dev, KVM list
In-Reply-To: <79514591-DCC1-4D9E-AFB7-AA985ADF3C0F@suse.de>
On 07/04/2010 12:04 PM, Alexander Graf wrote:
>
> My biggest concern about putting things in the device-tree is that I was trying to keep things as separate as possible. Why does the firmware have to know that it's running in KVM?
It doesn't need to know about kvm, it needs to know that a particular
hypercall protocol is available.
> Why do I have to patch 3 projects (Linux, OpenBIOS, Qemu) when I could go with patching a single one (Linux)?
>
That's not a valid argument. You patch as many projects as it takes to
get it right (not that I have an opinion in this particular discussion).
At the very least you have to patch qemu for reasons described before
(backwards compatible live migration).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Alexander Graf @ 2010-07-04 9:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: kvm-ppc, linuxppc-dev, KVM list
In-Reply-To: <1278196956.4200.390.camel@pasglop>
On 04.07.2010, at 00:42, Benjamin Herrenschmidt wrote:
> On Fri, 2010-07-02 at 20:41 +0200, Alexander Graf wrote:
>> The u64s are 64-bit aligned, should they always be?
>>
>> That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit
>> aligned, no? At least that's what ld and std specify.
>
> No, the PowerPC ABI specifies u64's to be 64-bit aligned, even for
> 32-bit binaries.
I see :).
Alex
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Alexander Graf @ 2010-07-04 9:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: kvm-ppc, linuxppc-dev, KVM list
In-Reply-To: <1278196909.4200.389.camel@pasglop>
On 04.07.2010, at 00:41, Benjamin Herrenschmidt wrote:
> On Fri, 2010-07-02 at 18:27 +0200, Segher Boessenkool wrote:
>>> +To find out if we're running on KVM or not, we overlay the PVR =20
>>> register. Usually
>>> +the PVR register contains an id that identifies your CPU type. If, =20=
>>> however, you
>>> +pass KVM_PVR_PARA in the register that you want the PVR result in, =20=
>>> the register
>>> +still contains KVM_PVR_PARA after the mfpvr call.
>>> +
>>> + LOAD_REG_IMM(r5, KVM_PVR_PARA)
>>> + mfpvr r5
>>> + [r5 still contains KVM_PVR_PARA]
>>=20
>> I love this part :-)
>=20
> Me not :-)
>=20
> It should be in the device-tree instead, or something like that. =
Enough
> games with PVR...
My biggest concern about putting things in the device-tree is that I was =
trying to keep things as separate as possible. Why does the firmware =
have to know that it's running in KVM? Why do I have to patch 3 projects =
(Linux, OpenBIOS, Qemu) when I could go with patching a single one =
(Linux)?
Alex
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Alexander Graf @ 2010-07-04 9:02 UTC (permalink / raw)
To: Scott Wood; +Cc: KVM list, kvm-ppc, Dan Hettena, linuxppc-dev, Hollis Blanchard
In-Reply-To: <20100702141003.75302a9a@schlenkerla.am.freescale.net>
On 02.07.2010, at 21:10, Scott Wood wrote:
> On Fri, 2 Jul 2010 20:47:44 +0200
> Alexander Graf <agraf@suse.de> wrote:
>=20
>>=20
>> On 02.07.2010, at 19:59, Hollis Blanchard wrote:
>>=20
>>> [Resending...]
>>>=20
>>> Please reconcile this with
>>> http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
>>> discussed in the (admittedly closed) Power.org embedded hypervisor
>>> working group. Bear in mind that other hypervisors are already
>>> implementing the documented ABI, so if you have concerns, you should
>>> probably raise them with that audience...
>>=20
>> We can not use sc with LV=3D1 because that would break the KVM in
>> something else case which is KVM's strong point on PPC.
>=20
> The current proposal involves the hypervisor specifying the hcall =
opcode
> sequence in the device tree -- to allow either "sc 1" or "sc 0 plus
> magic GPR" depending on whether you've got the hardware hypervisor
> feature (hereafter HHV).
Ah right, so you can still trap a hypercall with HHV. Makes sense.
>=20
> With HHV, "sc 0 plus magic GPR" just doesn't work, since it won't trap
> to the hypervisor. "sc 1 plus magic GPR" might be problematic on some
> non-HHV implementations, especially if you *do* have HHV but the
> non-HHV hypervisor is running as an HHV guest.
Yes, that's why I need sc 0 plus magic GPR in r0 and r3 - to accomodate =
for all the non-HHV cases. And it would be clever to have a way to =
expose the same functionality when we do use the HHV features.
So, is that draft available anywhere? The wiki page Hollis pointed to is =
very vague.
Alex
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Benjamin Herrenschmidt @ 2010-07-03 22:42 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, linuxppc-dev, KVM list
In-Reply-To: <A98DA9FC-DC42-452E-BD44-5F86D1707BF0@suse.de>
On Fri, 2010-07-02 at 20:41 +0200, Alexander Graf wrote:
> The u64s are 64-bit aligned, should they always be?
>
> That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit
> aligned, no? At least that's what ld and std specify.
No, the PowerPC ABI specifies u64's to be 64-bit aligned, even for
32-bit binaries.
Ben.
> >
> >> +The "ld" and "std" instructions are transormed to "lwz" and "stw"
> instructions
> >> +respectively on 32 bit systems with an added offset of 4 to
> accomodate for big
> >> +endianness.
> >
> > Will this add never overflow? Is there anything that checks for it?
>
> It basically means that to access dar, we either do
>
> ld rX, DAR(0)
>
> or
>
> lwz rX, DAR+4(0)
>
>
> >
> >> +mtmsrd rX, 0 b <special mtmsr section>
> >> +mtmsr b <special mtmsr section>
> >
> > mtmsr rX
>
> Nod.
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Benjamin Herrenschmidt @ 2010-07-03 22:41 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: kvm-ppc, linuxppc-dev, Alexander Graf, KVM list
In-Reply-To: <EB2E1C5B-118B-481B-83D6-44CFAA2E55D3@kernel.crashing.org>
On Fri, 2010-07-02 at 18:27 +0200, Segher Boessenkool wrote:
> > +To find out if we're running on KVM or not, we overlay the PVR
> > register. Usually
> > +the PVR register contains an id that identifies your CPU type. If,
> > however, you
> > +pass KVM_PVR_PARA in the register that you want the PVR result in,
> > the register
> > +still contains KVM_PVR_PARA after the mfpvr call.
> > +
> > + LOAD_REG_IMM(r5, KVM_PVR_PARA)
> > + mfpvr r5
> > + [r5 still contains KVM_PVR_PARA]
>
> I love this part :-)
Me not :-)
It should be in the device-tree instead, or something like that. Enough
games with PVR...
Ben.
> > + __u64 scratch3;
> > + __u64 critical; /* Guest may not get interrupts if == r1 */
> > + __u64 sprg0;
> > + __u64 sprg1;
> > + __u64 sprg2;
> > + __u64 sprg3;
> > + __u64 srr0;
> > + __u64 srr1;
> > + __u64 dar;
> > + __u64 msr;
> > + __u32 dsisr;
> > + __u32 int_pending; /* Tells the guest if we have an interrupt */
> > +};
> > +
> > +Additions to the page must only occur at the end. Struct fields
> > are always 32
> > +bit aligned.
>
> The u64s are 64-bit aligned, should they always be?
>
> > +The "ld" and "std" instructions are transormed to "lwz" and "stw"
> > instructions
> > +respectively on 32 bit systems with an added offset of 4 to
> > accomodate for big
> > +endianness.
>
> Will this add never overflow? Is there anything that checks for it?
>
> > +mtmsrd rX, 0 b <special mtmsr section>
> > +mtmsr b <special mtmsr section>
>
> mtmsr rX
>
>
> Segher
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] Add cmd64x IDE driver to default pmac32 config
From: lawrence rust @ 2010-07-03 18:21 UTC (permalink / raw)
To: linuxppc-dev
The Blue/White Apple PowerMac G3 and early G4's use a cmd64x compatible
IDE disk controller. E.g. lspci shows...
01:01.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 07)
Unfortunately the default pmac32 configuration does not include this
driver and so PowerMac G3's can't load a root filesystem. This is an
issue on a least Ubuntu since version 9.04, which uses the default
config as a starting point.
Signed-off-by: Lawrence Rust <lawrence at softsystem.co.uk>
diff -uprN a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
--- a/arch/powerpc/configs/pmac32_defconfig 2010-05-16 23:17:36.000000000 +0200
+++ b/arch/powerpc/configs/pmac32_defconfig 2010-07-03 20:11:10.000000000 +0200
@@ -738,7 +738,7 @@ CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
-# CONFIG_BLK_DEV_CMD64X is not set
+CONFIG_BLK_DEV_CMD64X=y
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
^ permalink raw reply
* [PATCH 04/19] arch/powerpc/platforms/pseries: use for_each_pci_dev()
From: Kulikov Vasiliy @ 2010-07-03 16:03 UTC (permalink / raw)
To: Kernel Janitors; +Cc: Tejun Heo, Paul Mackerras, linux-kernel, linuxppc-dev
Use for_each_pci_dev() to simplify the code.
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
arch/powerpc/platforms/pseries/eeh_cache.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh_cache.c b/arch/powerpc/platforms/pseries/eeh_cache.c
index 30b987b..8ed0d2d 100644
--- a/arch/powerpc/platforms/pseries/eeh_cache.c
+++ b/arch/powerpc/platforms/pseries/eeh_cache.c
@@ -288,8 +288,7 @@ void __init pci_addr_cache_build(void)
spin_lock_init(&pci_io_addr_cache_root.piar_lock);
- while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
-
+ for_each_pci_dev(dev) {
pci_addr_cache_insert_device(dev);
dn = pci_device_to_OF_node(dev);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] [v2] powerpc: introduce basic support for the Freescale P1022DS reference board
From: Tabi Timur-B04825 @ 2010-07-03 12:48 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev
In-Reply-To: <4C2EE056.1050506@embedded-sol.com>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
Felix Radensky wrote:
>
> There are currently no drivers in mainline for FSL eSPI controller and
> eSPI flash.
> They are present only in FSL BSP kernel. Do you think it makes sense to
> keep
> DTS entries for something that is not supported ?
Yes, for two reasons:
1) The DTS is supposed to describe the hardware, regardless as to whether
there are drivers for everything. There's no audio support, but I have the
SSI node there anyway.
2) We will eventually support the SPI in the mainline kernel. I think our
plan is to merge the SPI and eSPI drivers together first.
--
Timur Tabi
Linux kernel developer
[-- Attachment #2: Type: text/html, Size: 1175 bytes --]
^ permalink raw reply
* Re: [PATCH] [v2] powerpc: introduce basic support for the Freescale P1022DS reference board
From: Felix Radensky @ 2010-07-03 7:01 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1278109503-7604-1-git-send-email-timur@freescale.com>
Hi Timur,
There are currently no drivers in mainline for FSL eSPI controller and eSPI flash.
They are present only in FSL BSP kernel. Do you think it makes sense to keep
DTS entries for something that is not supported ?
Felix.
On 7/3/2010 1:25 AM, Timur Tabi wrote:
> Introduce basic support for the Freescale P1022DS reference board, based on the
> Freescale BSP for this board. This patch excludes the DIU, SSI, and MMC/SD
> drivers. Only a 36-bit DTS is provided.
>
> Update mpc86xx_smp_defconfig and mpc85xx_defconfig to support the P1022DS.
> This means enabling 64-bit physical address support, increasing the maximum
> zone order to 12 (to allow the DIU driver to allocate large chunks), and
> clean up the audio options to disable the deprecated OSS support.
>
> Signed-off-by: Timur Tabi<timur@freescale.com>
> ---
>
> This patch is for 2.6.36.
>
> arch/powerpc/boot/dts/p1022ds.dts | 633 ++++++++++++++++++++++++++++
> arch/powerpc/configs/mpc85xx_defconfig | 34 +-
> arch/powerpc/configs/mpc85xx_smp_defconfig | 34 +-
> arch/powerpc/platforms/85xx/Kconfig | 8 +
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/p1022_ds.c | 148 +++++++
> 6 files changed, 814 insertions(+), 44 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p1022ds.dts
> create mode 100644 arch/powerpc/platforms/85xx/p1022_ds.c
>
> diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
> new file mode 100644
> index 0000000..8bcb10b
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/p1022ds.dts
> @@ -0,0 +1,633 @@
> +/*
> + * P1022 DS 36Bit Physical Address Map Device Tree Source
> + *
> + * Copyright 2010 Freescale Semiconductor, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +/ {
> + model = "fsl,P1022";
> + compatible = "fsl,P1022DS";
> + #address-cells =<2>;
> + #size-cells =<2>;
> + interrupt-parent =<&mpic>;
> +
> + aliases {
> + ethernet0 =&enet0;
> + ethernet1 =&enet1;
> + serial0 =&serial0;
> + serial1 =&serial1;
> + pci0 =&pci0;
> + pci1 =&pci1;
> + pci2 =&pci2;
> + };
> +
> + cpus {
> + #address-cells =<1>;
> + #size-cells =<0>;
> +
> + PowerPC,P1022@0 {
> + device_type = "cpu";
> + reg =<0x0>;
> + next-level-cache =<&L2>;
> + };
> +
> + PowerPC,P1022@1 {
> + device_type = "cpu";
> + reg =<0x1>;
> + next-level-cache =<&L2>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + };
> +
> + localbus@fffe05000 {
> + #address-cells =<2>;
> + #size-cells =<1>;
> + compatible = "fsl,p1022-elbc", "fsl,elbc", "simple-bus";
> + reg =<0 0xffe05000 0 0x1000>;
> + interrupts =<19 2>;
> +
> + ranges =<0x0 0x0 0xf 0xe8000000 0x08000000
> + 0x1 0x0 0xf 0xe0000000 0x08000000
> + 0x2 0x0 0x0 0xffa00000 0x00040000
> + 0x3 0x0 0xf 0xffdf0000 0x00008000>;
> +
> + nor@0,0 {
> + #address-cells =<1>;
> + #size-cells =<1>;
> + compatible = "cfi-flash";
> + reg =<0x0 0x0 0x8000000>;
> + bank-width =<2>;
> + device-width =<1>;
> +
> + partition@0 {
> + reg =<0x0 0x03000000>;
> + label = "ramdisk-nor";
> + read-only;
> + };
> +
> + partition@3000000 {
> + reg =<0x03000000 0x00e00000>;
> + label = "diagnostic-nor";
> + read-only;
> + };
> +
> + partition@3e00000 {
> + reg =<0x03e00000 0x00200000>;
> + label = "dink-nor";
> + read-only;
> + };
> +
> + partition@4000000 {
> + reg =<0x04000000 0x00400000>;
> + label = "kernel-nor";
> + read-only;
> + };
> +
> + partition@4400000 {
> + reg =<0x04400000 0x03b00000>;
> + label = "jffs2-nor";
> + };
> +
> + partition@7f00000 {
> + reg =<0x07f00000 0x00080000>;
> + label = "dtb-nor";
> + read-only;
> + };
> +
> + partition@7f80000 {
> + reg =<0x07f80000 0x00080000>;
> + label = "u-boot-nor";
> + read-only;
> + };
> + };
> +
> + nand@2,0 {
> + #address-cells =<1>;
> + #size-cells =<1>;
> + compatible = "fsl,elbc-fcm-nand";
> + reg =<0x2 0x0 0x40000>;
> +
> + partition@0 {
> + reg =<0x0 0x02000000>;
> + label = "u-boot-nand";
> + read-only;
> + };
> +
> + partition@2000000 {
> + reg =<0x02000000 0x10000000>;
> + label = "jffs2-nand";
> + };
> +
> + partition@12000000 {
> + reg =<0x12000000 0x10000000>;
> + label = "ramdisk-nand";
> + read-only;
> + };
> +
> + partition@22000000 {
> + reg =<0x22000000 0x04000000>;
> + label = "kernel-nand";
> + };
> +
> + partition@26000000 {
> + reg =<0x26000000 0x01000000>;
> + label = "dtb-nand";
> + read-only;
> + };
> +
> + partition@27000000 {
> + reg =<0x27000000 0x19000000>;
> + label = "reserved-nand";
> + };
> + };
> + };
> +
> + soc@fffe00000 {
> + #address-cells =<1>;
> + #size-cells =<1>;
> + device_type = "soc";
> + compatible = "fsl,p1022-immr", "simple-bus";
> + ranges =<0x0 0xf 0xffe00000 0x100000>;
> + bus-frequency =<0>; // Filled out by uboot.
> +
> + ecm-law@0 {
> + compatible = "fsl,ecm-law";
> + reg =<0x0 0x1000>;
> + fsl,num-laws =<12>;
> + };
> +
> + ecm@1000 {
> + compatible = "fsl,p1022-ecm", "fsl,ecm";
> + reg =<0x1000 0x1000>;
> + interrupts =<16 2>;
> + };
> +
> + memory-controller@2000 {
> + compatible = "fsl,p1022-memory-controller";
> + reg =<0x2000 0x1000>;
> + interrupts =<16 2>;
> + };
> +
> + i2c@3000 {
> + #address-cells =<1>;
> + #size-cells =<0>;
> + cell-index =<0>;
> + compatible = "fsl-i2c";
> + reg =<0x3000 0x100>;
> + interrupts =<43 2>;
> + dfsrr;
> + };
> +
> + i2c@3100 {
> + #address-cells =<1>;
> + #size-cells =<0>;
> + cell-index =<1>;
> + compatible = "fsl-i2c";
> + reg =<0x3100 0x100>;
> + interrupts =<43 2>;
> + dfsrr;
> +
> + wm8776:codec@1a {
> + compatible = "wlf,wm8776";
> + reg =<0x1a>;
> + /* MCLK source is a stand-alone oscillator */
> + clock-frequency =<12288000>;
> + };
> + };
> +
> + serial0: serial@4500 {
> + cell-index =<0>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg =<0x4500 0x100>;
> + clock-frequency =<0>;
> + interrupts =<42 2>;
> + };
> +
> + serial1: serial@4600 {
> + cell-index =<1>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg =<0x4600 0x100>;
> + clock-frequency =<0>;
> + interrupts =<42 2>;
> + };
> +
> + spi@7000 {
> + cell-index =<0>;
> + #address-cells =<1>;
> + #size-cells =<0>;
> + compatible = "fsl,espi";
> + reg =<0x7000 0x1000>;
> + interrupts =<59 0x2>;
> + espi,num-ss-bits =<4>;
> + mode = "cpu";
> +
> + fsl_m25p80@0 {
> + #address-cells =<1>;
> + #size-cells =<1>;
> + compatible = "fsl,espi-flash";
> + reg =<0>;
> + linux,modalias = "fsl_m25p80";
> + spi-max-frequency =<40000000>; /* input clock */
> + partition@0 {
> + label = "u-boot-spi";
> + reg =<0x00000000 0x00100000>;
> + read-only;
> + };
> + partition@100000 {
> + label = "kernel-spi";
> + reg =<0x00100000 0x00500000>;
> + read-only;
> + };
> + partition@600000 {
> + label = "dtb-spi";
> + reg =<0x00600000 0x00100000>;
> + read-only;
> + };
> + partition@700000 {
> + label = "file system-spi";
> + reg =<0x00700000 0x00900000>;
> + };
> + };
> + };
> +
> + ssi@15000 {
> + compatible = "fsl,mpc8610-ssi";
> + cell-index =<0>;
> + reg =<0x15000 0x100>;
> + interrupts =<75 2>;
> + fsl,mode = "i2s-slave";
> + codec-handle =<&wm8776>;
> + fsl,playback-dma =<&dma00>;
> + fsl,capture-dma =<&dma01>;
> + fsl,fifo-depth =<16>;
> + };
> +
> + dma@c300 {
> + #address-cells =<1>;
> + #size-cells =<1>;
> + compatible = "fsl,eloplus-dma";
> + reg =<0xc300 0x4>;
> + ranges =<0x0 0xc100 0x200>;
> + cell-index =<1>;
> + dma00: dma-channel@0 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg =<0x0 0x80>;
> + cell-index =<0>;
> + interrupts =<76 2>;
> + };
> + dma01: dma-channel@80 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg =<0x80 0x80>;
> + cell-index =<1>;
> + interrupts =<77 2>;
> + };
> + dma-channel@100 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg =<0x100 0x80>;
> + cell-index =<2>;
> + interrupts =<78 2>;
> + };
> + dma-channel@180 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg =<0x180 0x80>;
> + cell-index =<3>;
> + interrupts =<79 2>;
> + };
> + };
> +
> + gpio: gpio-controller@f000 {
> + #gpio-cells =<2>;
> + compatible = "fsl,mpc8572-gpio";
> + reg =<0xf000 0x100>;
> + interrupts =<47 0x2>;
> + gpio-controller;
> + };
> +
> + L2: l2-cache-controller@20000 {
> + compatible = "fsl,p1022-l2-cache-controller";
> + reg =<0x20000 0x1000>;
> + cache-line-size =<32>; // 32 bytes
> + cache-size =<0x40000>; // L2, 256K
> + interrupts =<16 2>;
> + };
> +
> + dma@21300 {
> + #address-cells =<1>;
> + #size-cells =<1>;
> + compatible = "fsl,eloplus-dma";
> + reg =<0x21300 0x4>;
> + ranges =<0x0 0x21100 0x200>;
> + cell-index =<0>;
> + dma-channel@0 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg =<0x0 0x80>;
> + cell-index =<0>;
> + interrupts =<20 2>;
> + };
> + dma-channel@80 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg =<0x80 0x80>;
> + cell-index =<1>;
> + interrupts =<21 2>;
> + };
> + dma-channel@100 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg =<0x100 0x80>;
> + cell-index =<2>;
> + interrupts =<22 2>;
> + };
> + dma-channel@180 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg =<0x180 0x80>;
> + cell-index =<3>;
> + interrupts =<23 2>;
> + };
> + };
> +
> + usb@22000 {
> + #address-cells =<1>;
> + #size-cells =<0>;
> + compatible = "fsl-usb2-dr";
> + reg =<0x22000 0x1000>;
> + interrupts =<28 0x2>;
> + phy_type = "ulpi";
> + };
> +
> + mdio@24000 {
> + #address-cells =<1>;
> + #size-cells =<0>;
> + compatible = "fsl,etsec2-mdio";
> + reg =<0x24000 0x1000 0xb0030 0x4>;
> +
> + phy0: ethernet-phy@0 {
> + interrupts =<3 1>;
> + reg =<0x1>;
> + };
> + phy1: ethernet-phy@1 {
> + interrupts =<9 1>;
> + reg =<0x2>;
> + };
> + };
> +
> + mdio@25000 {
> + #address-cells =<1>;
> + #size-cells =<0>;
> + compatible = "fsl,etsec2-mdio";
> + reg =<0x25000 0x1000 0xb1030 0x4>;
> + };
> +
> + enet0: ethernet@B0000 {
> + #address-cells =<1>;
> + #size-cells =<1>;
> + cell-index =<0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "fsl,etsec2";
> + fsl,num_rx_queues =<0x8>;
> + fsl,num_tx_queues =<0x8>;
> + fsl,magic-packet;
> + fsl,wake-on-filer;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + fixed-link =<1 1 1000 0 0>;
> + phy-handle =<&phy0>;
> + phy-connection-type = "rgmii-id";
> + queue-group@0{
> + #address-cells =<1>;
> + #size-cells =<1>;
> + reg =<0xB0000 0x1000>;
> + interrupts =<29 2 30 2 34 2>;
> + };
> + queue-group@1{
> + #address-cells =<1>;
> + #size-cells =<1>;
> + reg =<0xB4000 0x1000>;
> + interrupts =<17 2 18 2 24 2>;
> + };
> + };
> +
> + enet1: ethernet@B1000 {
> + #address-cells =<1>;
> + #size-cells =<1>;
> + cell-index =<0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "fsl,etsec2";
> + fsl,num_rx_queues =<0x8>;
> + fsl,num_tx_queues =<0x8>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + fixed-link =<1 1 1000 0 0>;
> + phy-handle =<&phy1>;
> + phy-connection-type = "rgmii-id";
> + queue-group@0{
> + #address-cells =<1>;
> + #size-cells =<1>;
> + reg =<0xB1000 0x1000>;
> + interrupts =<35 2 36 2 40 2>;
> + };
> + queue-group@1{
> + #address-cells =<1>;
> + #size-cells =<1>;
> + reg =<0xB5000 0x1000>;
> + interrupts =<51 2 52 2 67 2>;
> + };
> + };
> +
> + sdhci@2e000 {
> + compatible = "fsl,p1022-esdhc", "fsl,esdhc";
> + reg =<0x2e000 0x1000>;
> + interrupts =<72 0x2>;
> + fsl,sdhci-auto-cmd12;
> + /* Filled in by U-Boot */
> + clock-frequency =<0>;
> + };
> +
> + crypto@30000 {
> + compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0",
> + "fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1",
> + "fsl,sec2.0";
> + reg =<0x30000 0x10000>;
> + interrupts =<45 2 58 2>;
> + fsl,num-channels =<4>;
> + fsl,channel-fifo-len =<24>;
> + fsl,exec-units-mask =<0x97c>;
> + fsl,descriptor-types-mask =<0x3a30abf>;
> + };
> +
> + sata@18000 {
> + compatible = "fsl,mpc8536-sata", "fsl,pq-sata";
> + reg =<0x18000 0x1000>;
> + cell-index =<1>;
> + interrupts =<74 0x2>;
> + };
> +
> + sata@19000 {
> + compatible = "fsl,mpc8536-sata", "fsl,pq-sata";
> + reg =<0x19000 0x1000>;
> + cell-index =<2>;
> + interrupts =<41 0x2>;
> + };
> +
> + power@e0070{
> + compatible = "fsl,mpc8536-pmc", "fsl,mpc8548-pmc";
> + reg =<0xe0070 0x20>;
> + };
> +
> + display@10000 {
> + compatible = "fsl,diu", "fsl,p1022-diu";
> + reg =<0x10000 1000>;
> + interrupts =<64 2>;
> + };
> +
> + timer@41100 {
> + compatible = "fsl,mpic-global-timer";
> + reg =<0x41100 0x204>;
> + interrupts =<0xf7 0x2>;
> + };
> +
> + mpic: pic@40000 {
> + interrupt-controller;
> + #address-cells =<0>;
> + #interrupt-cells =<2>;
> + reg =<0x40000 0x40000>;
> + compatible = "chrp,open-pic";
> + device_type = "open-pic";
> + };
> +
> + msi@41600 {
> + compatible = "fsl,p1022-msi", "fsl,mpic-msi";
> + reg =<0x41600 0x80>;
> + msi-available-ranges =<0 0x100>;
> + interrupts =<
> + 0xe0 0
> + 0xe1 0
> + 0xe2 0
> + 0xe3 0
> + 0xe4 0
> + 0xe5 0
> + 0xe6 0
> + 0xe7 0>;
> + };
> +
> + global-utilities@e0000 { //global utilities block
> + compatible = "fsl,p1022-guts";
> + reg =<0xe0000 0x1000>;
> + fsl,has-rstcr;
> + };
> + };
> +
> + pci0: pcie@fffe09000 {
> + compatible = "fsl,p1022-pcie";
> + device_type = "pci";
> + #interrupt-cells =<1>;
> + #size-cells =<2>;
> + #address-cells =<3>;
> + reg =<0xf 0xffe09000 0 0x1000>;
> + bus-range =<0 255>;
> + ranges =<0x2000000 0x0 0xa0000000 0xc 0x20000000 0x0 0x20000000
> + 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
> + clock-frequency =<33333333>;
> + interrupts =<16 2>;
> + interrupt-map-mask =<0xf800 0 0 7>;
> + interrupt-map =<
> + /* IDSEL 0x0 */
> + 0000 0 0 1&mpic 4 1
> + 0000 0 0 2&mpic 5 1
> + 0000 0 0 3&mpic 6 1
> + 0000 0 0 4&mpic 7 1
> + >;
> + pcie@0 {
> + reg =<0x0 0x0 0x0 0x0 0x0>;
> + #size-cells =<2>;
> + #address-cells =<3>;
> + device_type = "pci";
> + ranges =<0x2000000 0x0 0xe0000000
> + 0x2000000 0x0 0xe0000000
> + 0x0 0x20000000
> +
> + 0x1000000 0x0 0x0
> + 0x1000000 0x0 0x0
> + 0x0 0x100000>;
> + };
> + };
> +
> + pci1: pcie@fffe0a000 {
> + compatible = "fsl,p1022-pcie";
> + device_type = "pci";
> + #interrupt-cells =<1>;
> + #size-cells =<2>;
> + #address-cells =<3>;
> + reg =<0xf 0xffe0a000 0 0x1000>;
> + bus-range =<0 255>;
> + ranges =<0x2000000 0x0 0xc0000000 0xc 0x40000000 0x0 0x20000000
> + 0x1000000 0x0 0x00000000 0xf 0xffc20000 0x0 0x10000>;
> + clock-frequency =<33333333>;
> + interrupts =<16 2>;
> + interrupt-map-mask =<0xf800 0 0 7>;
> + interrupt-map =<
> + /* IDSEL 0x0 */
> + 0000 0 0 1&mpic 0 1
> + 0000 0 0 2&mpic 1 1
> + 0000 0 0 3&mpic 2 1
> + 0000 0 0 4&mpic 3 1
> + >;
> + pcie@0 {
> + reg =<0x0 0x0 0x0 0x0 0x0>;
> + #size-cells =<2>;
> + #address-cells =<3>;
> + device_type = "pci";
> + ranges =<0x2000000 0x0 0xe0000000
> + 0x2000000 0x0 0xe0000000
> + 0x0 0x20000000
> +
> + 0x1000000 0x0 0x0
> + 0x1000000 0x0 0x0
> + 0x0 0x100000>;
> + };
> + };
> +
> +
> + pci2: pcie@fffe0b000 {
> + compatible = "fsl,p1022-pcie";
> + device_type = "pci";
> + #interrupt-cells =<1>;
> + #size-cells =<2>;
> + #address-cells =<3>;
> + reg =<0xf 0xffe0b000 0 0x1000>;
> + bus-range =<0 255>;
> + ranges =<0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
> + 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
> + clock-frequency =<33333333>;
> + interrupts =<16 2>;
> + interrupt-map-mask =<0xf800 0 0 7>;
> + interrupt-map =<
> + /* IDSEL 0x0 */
> + 0000 0 0 1&mpic 8 1
> + 0000 0 0 2&mpic 9 1
> + 0000 0 0 3&mpic 10 1
> + 0000 0 0 4&mpic 11 1
> + >;
> + pcie@0 {
> + reg =<0x0 0x0 0x0 0x0 0x0>;
> + #size-cells =<2>;
> + #address-cells =<3>;
> + device_type = "pci";
> + ranges =<0x2000000 0x0 0xe0000000
> + 0x2000000 0x0 0xe0000000
> + 0x0 0x20000000
> +
> + 0x1000000 0x0 0x0
> + 0x1000000 0x0 0x0
> + 0x0 0x100000>;
> + };
> + };
> +};
> diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
> index cfebef9..d32f31a 100644
> --- a/arch/powerpc/configs/mpc85xx_defconfig
> +++ b/arch/powerpc/configs/mpc85xx_defconfig
> @@ -19,7 +19,8 @@ CONFIG_E500=y
> CONFIG_FSL_EMB_PERFMON=y
> CONFIG_BOOKE=y
> CONFIG_FSL_BOOKE=y
> -# CONFIG_PHYS_64BIT is not set
> +CONFIG_PTE_64BIT=y
> +CONFIG_PHYS_64BIT=y
> CONFIG_SPE=y
> CONFIG_PPC_MMU_NOHASH=y
> CONFIG_PPC_MMU_NOHASH_32=y
> @@ -28,7 +29,7 @@ CONFIG_PPC_BOOK3E_MMU=y
> # CONFIG_SMP is not set
> CONFIG_PPC32=y
> CONFIG_WORD_SIZE=32
> -# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
> +CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
> CONFIG_MMU=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> CONFIG_GENERIC_TIME=y
> @@ -239,6 +240,7 @@ CONFIG_MPC85xx_MDS=y
> CONFIG_MPC8536_DS=y
> CONFIG_MPC85xx_DS=y
> CONFIG_MPC85xx_RDB=y
> +CONFIG_P1022_DS=y
> CONFIG_SOCRATES=y
> CONFIG_KSI8560=y
> CONFIG_XES_MPC85xx=y
> @@ -311,7 +313,7 @@ CONFIG_FLAT_NODE_MEM_MAP=y
> CONFIG_PAGEFLAGS_EXTENDED=y
> CONFIG_SPLIT_PTLOCK_CPUS=4
> CONFIG_MIGRATION=y
> -# CONFIG_PHYS_ADDR_T_64BIT is not set
> +CONFIG_PHYS_ADDR_T_64BIT=y
> CONFIG_ZONE_DMA_FLAG=1
> CONFIG_BOUNCE=y
> CONFIG_VIRT_TO_BUS=y
> @@ -321,7 +323,7 @@ CONFIG_PPC_4K_PAGES=y
> # CONFIG_PPC_16K_PAGES is not set
> # CONFIG_PPC_64K_PAGES is not set
> # CONFIG_PPC_256K_PAGES is not set
> -CONFIG_FORCE_MAX_ZONEORDER=11
> +CONFIG_FORCE_MAX_ZONEORDER=12
> CONFIG_PROC_DEVICETREE=y
> # CONFIG_CMDLINE_BOOL is not set
> CONFIG_EXTRA_TARGETS=""
> @@ -1122,16 +1124,13 @@ CONFIG_VGA_CONSOLE=y
> # CONFIG_VGACON_SOFT_SCROLLBACK is not set
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_SOUND=y
> -CONFIG_SOUND_OSS_CORE=y
> -CONFIG_SOUND_OSS_CORE_PRECLAIM=y
> +# CONFIG_SOUND_OSS_CORE is not set
> CONFIG_SND=y
> CONFIG_SND_TIMER=y
> CONFIG_SND_PCM=y
> # CONFIG_SND_SEQUENCER is not set
> -CONFIG_SND_OSSEMUL=y
> -CONFIG_SND_MIXER_OSS=y
> -CONFIG_SND_PCM_OSS=y
> -CONFIG_SND_PCM_OSS_PLUGINS=y
> +# CONFIG_SND_MIXER_OSS is not set
> +# CONFIG_SND_PCM_OSS is not set
> # CONFIG_SND_HRTIMER is not set
> # CONFIG_SND_DYNAMIC_MINORS is not set
> # CONFIG_SND_SUPPORT_OLD_API is not set
> @@ -1145,12 +1144,7 @@ CONFIG_SND_VMASTER=y
> # CONFIG_SND_SBAWE_SEQ is not set
> # CONFIG_SND_EMU10K1_SEQ is not set
> CONFIG_SND_AC97_CODEC=y
> -CONFIG_SND_DRIVERS=y
> -# CONFIG_SND_DUMMY is not set
> -# CONFIG_SND_MTPAV is not set
> -# CONFIG_SND_SERIAL_U16550 is not set
> -# CONFIG_SND_MPU401 is not set
> -# CONFIG_SND_AC97_POWER_SAVE is not set
> +# CONFIG_SND_DRIVERS is not set
> CONFIG_SND_PCI=y
> # CONFIG_SND_AD1889 is not set
> # CONFIG_SND_ALS300 is not set
> @@ -1218,12 +1212,8 @@ CONFIG_SND_INTEL8X0=y
> # CONFIG_SND_VIRTUOSO is not set
> # CONFIG_SND_VX222 is not set
> # CONFIG_SND_YMFPCI is not set
> -CONFIG_SND_PPC=y
> -CONFIG_SND_USB=y
> -# CONFIG_SND_USB_AUDIO is not set
> -# CONFIG_SND_USB_UA101 is not set
> -# CONFIG_SND_USB_USX2Y is not set
> -# CONFIG_SND_USB_CAIAQ is not set
> +# CONFIG_SND_PPC is not set
> +# CONFIG_SND_USB is not set
> # CONFIG_SND_SOC is not set
> # CONFIG_SOUND_PRIME is not set
> CONFIG_AC97_BUS=y
> diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
> index f5451d8..f93de10 100644
> --- a/arch/powerpc/configs/mpc85xx_smp_defconfig
> +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
> @@ -19,7 +19,8 @@ CONFIG_E500=y
> CONFIG_FSL_EMB_PERFMON=y
> CONFIG_BOOKE=y
> CONFIG_FSL_BOOKE=y
> -# CONFIG_PHYS_64BIT is not set
> +CONFIG_PTE_64BIT=y
> +CONFIG_PHYS_64BIT=y
> CONFIG_SPE=y
> CONFIG_PPC_MMU_NOHASH=y
> CONFIG_PPC_MMU_NOHASH_32=y
> @@ -29,7 +30,7 @@ CONFIG_SMP=y
> CONFIG_NR_CPUS=8
> CONFIG_PPC32=y
> CONFIG_WORD_SIZE=32
> -# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
> +CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
> CONFIG_MMU=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> CONFIG_GENERIC_TIME=y
> @@ -243,6 +244,7 @@ CONFIG_MPC85xx_MDS=y
> CONFIG_MPC8536_DS=y
> CONFIG_MPC85xx_DS=y
> CONFIG_MPC85xx_RDB=y
> +CONFIG_P1022_DS=y
> CONFIG_SOCRATES=y
> CONFIG_KSI8560=y
> CONFIG_XES_MPC85xx=y
> @@ -316,7 +318,7 @@ CONFIG_FLAT_NODE_MEM_MAP=y
> CONFIG_PAGEFLAGS_EXTENDED=y
> CONFIG_SPLIT_PTLOCK_CPUS=4
> CONFIG_MIGRATION=y
> -# CONFIG_PHYS_ADDR_T_64BIT is not set
> +CONFIG_PHYS_ADDR_T_64BIT=y
> CONFIG_ZONE_DMA_FLAG=1
> CONFIG_BOUNCE=y
> CONFIG_VIRT_TO_BUS=y
> @@ -326,7 +328,7 @@ CONFIG_PPC_4K_PAGES=y
> # CONFIG_PPC_16K_PAGES is not set
> # CONFIG_PPC_64K_PAGES is not set
> # CONFIG_PPC_256K_PAGES is not set
> -CONFIG_FORCE_MAX_ZONEORDER=11
> +CONFIG_FORCE_MAX_ZONEORDER=12
> CONFIG_PROC_DEVICETREE=y
> # CONFIG_CMDLINE_BOOL is not set
> CONFIG_EXTRA_TARGETS=""
> @@ -1127,16 +1129,13 @@ CONFIG_VGA_CONSOLE=y
> # CONFIG_VGACON_SOFT_SCROLLBACK is not set
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_SOUND=y
> -CONFIG_SOUND_OSS_CORE=y
> -CONFIG_SOUND_OSS_CORE_PRECLAIM=y
> +# CONFIG_SOUND_OSS_CORE is not set
> CONFIG_SND=y
> CONFIG_SND_TIMER=y
> CONFIG_SND_PCM=y
> # CONFIG_SND_SEQUENCER is not set
> -CONFIG_SND_OSSEMUL=y
> -CONFIG_SND_MIXER_OSS=y
> -CONFIG_SND_PCM_OSS=y
> -CONFIG_SND_PCM_OSS_PLUGINS=y
> +# CONFIG_SND_MIXER_OSS is not set
> +# CONFIG_SND_PCM_OSS is not set
> # CONFIG_SND_HRTIMER is not set
> # CONFIG_SND_DYNAMIC_MINORS is not set
> # CONFIG_SND_SUPPORT_OLD_API is not set
> @@ -1150,12 +1149,7 @@ CONFIG_SND_VMASTER=y
> # CONFIG_SND_SBAWE_SEQ is not set
> # CONFIG_SND_EMU10K1_SEQ is not set
> CONFIG_SND_AC97_CODEC=y
> -CONFIG_SND_DRIVERS=y
> -# CONFIG_SND_DUMMY is not set
> -# CONFIG_SND_MTPAV is not set
> -# CONFIG_SND_SERIAL_U16550 is not set
> -# CONFIG_SND_MPU401 is not set
> -# CONFIG_SND_AC97_POWER_SAVE is not set
> +# CONFIG_SND_DRIVERS is not set
> CONFIG_SND_PCI=y
> # CONFIG_SND_AD1889 is not set
> # CONFIG_SND_ALS300 is not set
> @@ -1223,12 +1217,8 @@ CONFIG_SND_INTEL8X0=y
> # CONFIG_SND_VIRTUOSO is not set
> # CONFIG_SND_VX222 is not set
> # CONFIG_SND_YMFPCI is not set
> -CONFIG_SND_PPC=y
> -CONFIG_SND_USB=y
> -# CONFIG_SND_USB_AUDIO is not set
> -# CONFIG_SND_USB_UA101 is not set
> -# CONFIG_SND_USB_USX2Y is not set
> -# CONFIG_SND_USB_CAIAQ is not set
> +# CONFIG_SND_PPC is not set
> +# CONFIG_SND_USB is not set
> # CONFIG_SND_SOC is not set
> # CONFIG_SOUND_PRIME is not set
> CONFIG_AC97_BUS=y
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 3a2ade2..bea1f59 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -65,6 +65,14 @@ config MPC85xx_RDB
> help
> This option enables support for the MPC85xx RDB (P2020 RDB) board
>
> +config P1022_DS
> + bool "Freescale P1022 DS"
> + select DEFAULT_UIMAGE
> + select CONFIG_PHYS_64BIT # The DTS has 36-bit addresses
> + select SWIOTLB
> + help
> + This option enables support for the Freescale P1022DS reference board.
> +
> config SOCRATES
> bool "Socrates"
> select DEFAULT_UIMAGE
> diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
> index 387c128..a2ec3f8 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_MPC8536_DS) += mpc8536_ds.o
> obj-$(CONFIG_MPC85xx_DS) += mpc85xx_ds.o
> obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
> obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
> +obj-$(CONFIG_P1022_DS) += p1022_ds.o
> obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
> obj-$(CONFIG_STX_GP3) += stx_gp3.o
> obj-$(CONFIG_TQM85xx) += tqm85xx.o
> diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
> new file mode 100644
> index 0000000..e1467c9
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/p1022_ds.c
> @@ -0,0 +1,148 @@
> +/*
> + * P1022DS board specific routines
> + *
> + * Authors: Travis Wheatley<travis.wheatley@freescale.com>
> + * Dave Liu<daveliu@freescale.com>
> + * Timur Tabi<timur@freescale.com>
> + *
> + * Copyright 2010 Freescale Semiconductor, Inc.
> + *
> + * This file is taken from the Freescale P1022DS BSP, with modifications:
> + * 1) No DIU support (pending rewrite of DIU code)
> + * 2) No AMP support
> + * 3) No PCI endpoint support
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include<linux/pci.h>
> +#include<linux/of_platform.h>
> +#include<linux/lmb.h>
> +
> +#include<asm/mpic.h>
> +#include<asm/swiotlb.h>
> +
> +#include<sysdev/fsl_soc.h>
> +#include<sysdev/fsl_pci.h>
> +
> +void __init p1022_ds_pic_init(void)
> +{
> + struct mpic *mpic;
> + struct resource r;
> + struct device_node *np;
> +
> + np = of_find_node_by_type(NULL, "open-pic");
> + if (!np) {
> + pr_err("Could not find open-pic node\n");
> + return;
> + }
> +
> + if (of_address_to_resource(np, 0,&r)) {
> + pr_err("Failed to map mpic register space\n");
> + of_node_put(np);
> + return;
> + }
> +
> + mpic = mpic_alloc(np, r.start,
> + MPIC_PRIMARY | MPIC_WANTS_RESET |
> + MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS |
> + MPIC_SINGLE_DEST_CPU,
> + 0, 256, " OpenPIC ");
> +
> + BUG_ON(mpic == NULL);
> + of_node_put(np);
> +
> + mpic_init(mpic);
> +}
> +
> +#ifdef CONFIG_SMP
> +void __init mpc85xx_smp_init(void);
> +#endif
> +
> +/*
> + * Setup the architecture
> + */
> +static void __init p1022_ds_setup_arch(void)
> +{
> +#ifdef CONFIG_PCI
> + struct device_node *np;
> +#endif
> + dma_addr_t max = 0xffffffff;
> +
> + if (ppc_md.progress)
> + ppc_md.progress("p1022_ds_setup_arch()", 0);
> +
> +#ifdef CONFIG_PCI
> + for_each_compatible_node(np, "pci", "fsl,p1022-pcie") {
> + struct resource rsrc;
> + struct pci_controller *hose;
> +
> + of_address_to_resource(np, 0,&rsrc);
> +
> + if ((rsrc.start& 0xfffff) == 0x8000)
> + fsl_add_bridge(np, 1);
> + else
> + fsl_add_bridge(np, 0);
> +
> + hose = pci_find_hose_for_OF_device(np);
> + max = min(max, hose->dma_window_base_cur +
> + hose->dma_window_size);
> + }
> +#endif
> +
> +#ifdef CONFIG_SMP
> + mpc85xx_smp_init();
> +#endif
> +
> +#ifdef CONFIG_SWIOTLB
> + if (lmb_end_of_DRAM()> max) {
> + ppc_swiotlb_enable = 1;
> + set_pci_dma_ops(&swiotlb_dma_ops);
> + ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
> + }
> +#endif
> +
> + pr_info("Freescale P1022 DS reference board\n");
> +}
> +
> +static struct of_device_id __initdata p1022_ds_ids[] = {
> + { .type = "soc", },
> + { .compatible = "soc", },
> + { .compatible = "simple-bus", },
> + { .compatible = "gianfar", },
> + {},
> +};
> +
> +static int __init p1022_ds_publish_devices(void)
> +{
> + return of_platform_bus_probe(NULL, p1022_ds_ids, NULL);
> +}
> +machine_device_initcall(p1022_ds, p1022_ds_publish_devices);
> +
> +machine_arch_initcall(p1022_ds, swiotlb_setup_bus_notifier);
> +
> +/*
> + * Called very early, device-tree isn't unflattened
> + */
> +static int __init p1022_ds_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "fsl,p1022ds");
> +}
> +
> +define_machine(p1022_ds) {
> + .name = "P1022 DS",
> + .probe = p1022_ds_probe,
> + .setup_arch = p1022_ds_setup_arch,
> + .init_IRQ = p1022_ds_pic_init,
> +#ifdef CONFIG_PCI
> + .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> +#endif
> + .get_irq = mpic_get_irq,
> + .restart = fsl_rstcr_restart,
> + .calibrate_decr = generic_calibrate_decr,
> + .progress = udbg_progress,
> +};
^ permalink raw reply
* [PATCH] [v2] powerpc: introduce basic support for the Freescale P1022DS reference board
From: Timur Tabi @ 2010-07-02 22:25 UTC (permalink / raw)
To: linuxppc-dev
Introduce basic support for the Freescale P1022DS reference board, based on the
Freescale BSP for this board. This patch excludes the DIU, SSI, and MMC/SD
drivers. Only a 36-bit DTS is provided.
Update mpc86xx_smp_defconfig and mpc85xx_defconfig to support the P1022DS.
This means enabling 64-bit physical address support, increasing the maximum
zone order to 12 (to allow the DIU driver to allocate large chunks), and
clean up the audio options to disable the deprecated OSS support.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch is for 2.6.36.
arch/powerpc/boot/dts/p1022ds.dts | 633 ++++++++++++++++++++++++++++
arch/powerpc/configs/mpc85xx_defconfig | 34 +-
arch/powerpc/configs/mpc85xx_smp_defconfig | 34 +-
arch/powerpc/platforms/85xx/Kconfig | 8 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/p1022_ds.c | 148 +++++++
6 files changed, 814 insertions(+), 44 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1022ds.dts
create mode 100644 arch/powerpc/platforms/85xx/p1022_ds.c
diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
new file mode 100644
index 0000000..8bcb10b
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -0,0 +1,633 @@
+/*
+ * P1022 DS 36Bit Physical Address Map Device Tree Source
+ *
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/ {
+ model = "fsl,P1022";
+ compatible = "fsl,P1022DS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ pci2 = &pci2;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,P1022@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+
+ PowerPC,P1022@1 {
+ device_type = "cpu";
+ reg = <0x1>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ localbus@fffe05000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,p1022-elbc", "fsl,elbc", "simple-bus";
+ reg = <0 0xffe05000 0 0x1000>;
+ interrupts = <19 2>;
+
+ ranges = <0x0 0x0 0xf 0xe8000000 0x08000000
+ 0x1 0x0 0xf 0xe0000000 0x08000000
+ 0x2 0x0 0x0 0xffa00000 0x00040000
+ 0x3 0x0 0xf 0xffdf0000 0x00008000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ reg = <0x0 0x03000000>;
+ label = "ramdisk-nor";
+ read-only;
+ };
+
+ partition@3000000 {
+ reg = <0x03000000 0x00e00000>;
+ label = "diagnostic-nor";
+ read-only;
+ };
+
+ partition@3e00000 {
+ reg = <0x03e00000 0x00200000>;
+ label = "dink-nor";
+ read-only;
+ };
+
+ partition@4000000 {
+ reg = <0x04000000 0x00400000>;
+ label = "kernel-nor";
+ read-only;
+ };
+
+ partition@4400000 {
+ reg = <0x04400000 0x03b00000>;
+ label = "jffs2-nor";
+ };
+
+ partition@7f00000 {
+ reg = <0x07f00000 0x00080000>;
+ label = "dtb-nor";
+ read-only;
+ };
+
+ partition@7f80000 {
+ reg = <0x07f80000 0x00080000>;
+ label = "u-boot-nor";
+ read-only;
+ };
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x2 0x0 0x40000>;
+
+ partition@0 {
+ reg = <0x0 0x02000000>;
+ label = "u-boot-nand";
+ read-only;
+ };
+
+ partition@2000000 {
+ reg = <0x02000000 0x10000000>;
+ label = "jffs2-nand";
+ };
+
+ partition@12000000 {
+ reg = <0x12000000 0x10000000>;
+ label = "ramdisk-nand";
+ read-only;
+ };
+
+ partition@22000000 {
+ reg = <0x22000000 0x04000000>;
+ label = "kernel-nand";
+ };
+
+ partition@26000000 {
+ reg = <0x26000000 0x01000000>;
+ label = "dtb-nand";
+ read-only;
+ };
+
+ partition@27000000 {
+ reg = <0x27000000 0x19000000>;
+ label = "reserved-nand";
+ };
+ };
+ };
+
+ soc@fffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,p1022-immr", "simple-bus";
+ ranges = <0x0 0xf 0xffe00000 0x100000>;
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,p1022-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <16 2>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,p1022-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupts = <16 2>;
+ };
+
+ i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <43 2>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
+ dfsrr;
+
+ wm8776:codec@1a {
+ compatible = "wlf,wm8776";
+ reg = <0x1a>;
+ /* MCLK source is a stand-alone oscillator */
+ clock-frequency = <12288000>;
+ };
+ };
+
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ };
+
+ serial1: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ };
+
+ spi@7000 {
+ cell-index = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,espi";
+ reg = <0x7000 0x1000>;
+ interrupts = <59 0x2>;
+ espi,num-ss-bits = <4>;
+ mode = "cpu";
+
+ fsl_m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,espi-flash";
+ reg = <0>;
+ linux,modalias = "fsl_m25p80";
+ spi-max-frequency = <40000000>; /* input clock */
+ partition@0 {
+ label = "u-boot-spi";
+ reg = <0x00000000 0x00100000>;
+ read-only;
+ };
+ partition@100000 {
+ label = "kernel-spi";
+ reg = <0x00100000 0x00500000>;
+ read-only;
+ };
+ partition@600000 {
+ label = "dtb-spi";
+ reg = <0x00600000 0x00100000>;
+ read-only;
+ };
+ partition@700000 {
+ label = "file system-spi";
+ reg = <0x00700000 0x00900000>;
+ };
+ };
+ };
+
+ ssi@15000 {
+ compatible = "fsl,mpc8610-ssi";
+ cell-index = <0>;
+ reg = <0x15000 0x100>;
+ interrupts = <75 2>;
+ fsl,mode = "i2s-slave";
+ codec-handle = <&wm8776>;
+ fsl,playback-dma = <&dma00>;
+ fsl,capture-dma = <&dma01>;
+ fsl,fifo-depth = <16>;
+ };
+
+ dma@c300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,eloplus-dma";
+ reg = <0xc300 0x4>;
+ ranges = <0x0 0xc100 0x200>;
+ cell-index = <1>;
+ dma00: dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupts = <76 2>;
+ };
+ dma01: dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupts = <77 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupts = <78 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupts = <79 2>;
+ };
+ };
+
+ gpio: gpio-controller@f000 {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8572-gpio";
+ reg = <0xf000 0x100>;
+ interrupts = <47 0x2>;
+ gpio-controller;
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,p1022-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x40000>; // L2, 256K
+ interrupts = <16 2>;
+ };
+
+ dma@21300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,eloplus-dma";
+ reg = <0x21300 0x4>;
+ ranges = <0x0 0x21100 0x200>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupts = <20 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupts = <21 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupts = <22 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupts = <23 2>;
+ };
+ };
+
+ usb@22000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl-usb2-dr";
+ reg = <0x22000 0x1000>;
+ interrupts = <28 0x2>;
+ phy_type = "ulpi";
+ };
+
+ mdio@24000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,etsec2-mdio";
+ reg = <0x24000 0x1000 0xb0030 0x4>;
+
+ phy0: ethernet-phy@0 {
+ interrupts = <3 1>;
+ reg = <0x1>;
+ };
+ phy1: ethernet-phy@1 {
+ interrupts = <9 1>;
+ reg = <0x2>;
+ };
+ };
+
+ mdio@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,etsec2-mdio";
+ reg = <0x25000 0x1000 0xb1030 0x4>;
+ };
+
+ enet0: ethernet@B0000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "fsl,etsec2";
+ fsl,num_rx_queues = <0x8>;
+ fsl,num_tx_queues = <0x8>;
+ fsl,magic-packet;
+ fsl,wake-on-filer;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ fixed-link = <1 1 1000 0 0>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ queue-group@0{
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xB0000 0x1000>;
+ interrupts = <29 2 30 2 34 2>;
+ };
+ queue-group@1{
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xB4000 0x1000>;
+ interrupts = <17 2 18 2 24 2>;
+ };
+ };
+
+ enet1: ethernet@B1000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "fsl,etsec2";
+ fsl,num_rx_queues = <0x8>;
+ fsl,num_tx_queues = <0x8>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ fixed-link = <1 1 1000 0 0>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ queue-group@0{
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xB1000 0x1000>;
+ interrupts = <35 2 36 2 40 2>;
+ };
+ queue-group@1{
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xB5000 0x1000>;
+ interrupts = <51 2 52 2 67 2>;
+ };
+ };
+
+ sdhci@2e000 {
+ compatible = "fsl,p1022-esdhc", "fsl,esdhc";
+ reg = <0x2e000 0x1000>;
+ interrupts = <72 0x2>;
+ fsl,sdhci-auto-cmd12;
+ /* Filled in by U-Boot */
+ clock-frequency = <0>;
+ };
+
+ crypto@30000 {
+ compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0",
+ "fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1",
+ "fsl,sec2.0";
+ reg = <0x30000 0x10000>;
+ interrupts = <45 2 58 2>;
+ fsl,num-channels = <4>;
+ fsl,channel-fifo-len = <24>;
+ fsl,exec-units-mask = <0x97c>;
+ fsl,descriptor-types-mask = <0x3a30abf>;
+ };
+
+ sata@18000 {
+ compatible = "fsl,mpc8536-sata", "fsl,pq-sata";
+ reg = <0x18000 0x1000>;
+ cell-index = <1>;
+ interrupts = <74 0x2>;
+ };
+
+ sata@19000 {
+ compatible = "fsl,mpc8536-sata", "fsl,pq-sata";
+ reg = <0x19000 0x1000>;
+ cell-index = <2>;
+ interrupts = <41 0x2>;
+ };
+
+ power@e0070{
+ compatible = "fsl,mpc8536-pmc", "fsl,mpc8548-pmc";
+ reg = <0xe0070 0x20>;
+ };
+
+ display@10000 {
+ compatible = "fsl,diu", "fsl,p1022-diu";
+ reg = <0x10000 1000>;
+ interrupts = <64 2>;
+ };
+
+ timer@41100 {
+ compatible = "fsl,mpic-global-timer";
+ reg = <0x41100 0x204>;
+ interrupts = <0xf7 0x2>;
+ };
+
+ mpic: pic@40000 {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x40000 0x40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ };
+
+ msi@41600 {
+ compatible = "fsl,p1022-msi", "fsl,mpic-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xe0 0
+ 0xe1 0
+ 0xe2 0
+ 0xe3 0
+ 0xe4 0
+ 0xe5 0
+ 0xe6 0
+ 0xe7 0>;
+ };
+
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,p1022-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+ };
+
+ pci0: pcie@fffe09000 {
+ compatible = "fsl,p1022-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xffe09000 0 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0xa0000000 0xc 0x20000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
+ clock-frequency = <33333333>;
+ interrupts = <16 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 4 1
+ 0000 0 0 2 &mpic 5 1
+ 0000 0 0 3 &mpic 6 1
+ 0000 0 0 4 &mpic 7 1
+ >;
+ pcie@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@fffe0a000 {
+ compatible = "fsl,p1022-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xffe0a000 0 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0xc0000000 0xc 0x40000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc20000 0x0 0x10000>;
+ clock-frequency = <33333333>;
+ interrupts = <16 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 0 1
+ 0000 0 0 2 &mpic 1 1
+ 0000 0 0 3 &mpic 2 1
+ 0000 0 0 4 &mpic 3 1
+ >;
+ pcie@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+
+ pci2: pcie@fffe0b000 {
+ compatible = "fsl,p1022-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xffe0b000 0 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+ clock-frequency = <33333333>;
+ interrupts = <16 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 8 1
+ 0000 0 0 2 &mpic 9 1
+ 0000 0 0 3 &mpic 10 1
+ 0000 0 0 4 &mpic 11 1
+ >;
+ pcie@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index cfebef9..d32f31a 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -19,7 +19,8 @@ CONFIG_E500=y
CONFIG_FSL_EMB_PERFMON=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
-# CONFIG_PHYS_64BIT is not set
+CONFIG_PTE_64BIT=y
+CONFIG_PHYS_64BIT=y
CONFIG_SPE=y
CONFIG_PPC_MMU_NOHASH=y
CONFIG_PPC_MMU_NOHASH_32=y
@@ -28,7 +29,7 @@ CONFIG_PPC_BOOK3E_MMU=y
# CONFIG_SMP is not set
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
-# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
+CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
@@ -239,6 +240,7 @@ CONFIG_MPC85xx_MDS=y
CONFIG_MPC8536_DS=y
CONFIG_MPC85xx_DS=y
CONFIG_MPC85xx_RDB=y
+CONFIG_P1022_DS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
CONFIG_XES_MPC85xx=y
@@ -311,7 +313,7 @@ CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
-# CONFIG_PHYS_ADDR_T_64BIT is not set
+CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
@@ -321,7 +323,7 @@ CONFIG_PPC_4K_PAGES=y
# CONFIG_PPC_16K_PAGES is not set
# CONFIG_PPC_64K_PAGES is not set
# CONFIG_PPC_256K_PAGES is not set
-CONFIG_FORCE_MAX_ZONEORDER=11
+CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_EXTRA_TARGETS=""
@@ -1122,16 +1124,13 @@ CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=y
-CONFIG_SOUND_OSS_CORE=y
-CONFIG_SOUND_OSS_CORE_PRECLAIM=y
+# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
-CONFIG_SND_OSSEMUL=y
-CONFIG_SND_MIXER_OSS=y
-CONFIG_SND_PCM_OSS=y
-CONFIG_SND_PCM_OSS_PLUGINS=y
+# CONFIG_SND_MIXER_OSS is not set
+# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
@@ -1145,12 +1144,7 @@ CONFIG_SND_VMASTER=y
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_AC97_CODEC=y
-CONFIG_SND_DRIVERS=y
-# CONFIG_SND_DUMMY is not set
-# CONFIG_SND_MTPAV is not set
-# CONFIG_SND_SERIAL_U16550 is not set
-# CONFIG_SND_MPU401 is not set
-# CONFIG_SND_AC97_POWER_SAVE is not set
+# CONFIG_SND_DRIVERS is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
@@ -1218,12 +1212,8 @@ CONFIG_SND_INTEL8X0=y
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
-CONFIG_SND_PPC=y
-CONFIG_SND_USB=y
-# CONFIG_SND_USB_AUDIO is not set
-# CONFIG_SND_USB_UA101 is not set
-# CONFIG_SND_USB_USX2Y is not set
-# CONFIG_SND_USB_CAIAQ is not set
+# CONFIG_SND_PPC is not set
+# CONFIG_SND_USB is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index f5451d8..f93de10 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -19,7 +19,8 @@ CONFIG_E500=y
CONFIG_FSL_EMB_PERFMON=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
-# CONFIG_PHYS_64BIT is not set
+CONFIG_PTE_64BIT=y
+CONFIG_PHYS_64BIT=y
CONFIG_SPE=y
CONFIG_PPC_MMU_NOHASH=y
CONFIG_PPC_MMU_NOHASH_32=y
@@ -29,7 +30,7 @@ CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
-# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
+CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
@@ -243,6 +244,7 @@ CONFIG_MPC85xx_MDS=y
CONFIG_MPC8536_DS=y
CONFIG_MPC85xx_DS=y
CONFIG_MPC85xx_RDB=y
+CONFIG_P1022_DS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
CONFIG_XES_MPC85xx=y
@@ -316,7 +318,7 @@ CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
-# CONFIG_PHYS_ADDR_T_64BIT is not set
+CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
@@ -326,7 +328,7 @@ CONFIG_PPC_4K_PAGES=y
# CONFIG_PPC_16K_PAGES is not set
# CONFIG_PPC_64K_PAGES is not set
# CONFIG_PPC_256K_PAGES is not set
-CONFIG_FORCE_MAX_ZONEORDER=11
+CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_EXTRA_TARGETS=""
@@ -1127,16 +1129,13 @@ CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=y
-CONFIG_SOUND_OSS_CORE=y
-CONFIG_SOUND_OSS_CORE_PRECLAIM=y
+# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
-CONFIG_SND_OSSEMUL=y
-CONFIG_SND_MIXER_OSS=y
-CONFIG_SND_PCM_OSS=y
-CONFIG_SND_PCM_OSS_PLUGINS=y
+# CONFIG_SND_MIXER_OSS is not set
+# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
@@ -1150,12 +1149,7 @@ CONFIG_SND_VMASTER=y
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_AC97_CODEC=y
-CONFIG_SND_DRIVERS=y
-# CONFIG_SND_DUMMY is not set
-# CONFIG_SND_MTPAV is not set
-# CONFIG_SND_SERIAL_U16550 is not set
-# CONFIG_SND_MPU401 is not set
-# CONFIG_SND_AC97_POWER_SAVE is not set
+# CONFIG_SND_DRIVERS is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
@@ -1223,12 +1217,8 @@ CONFIG_SND_INTEL8X0=y
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
-CONFIG_SND_PPC=y
-CONFIG_SND_USB=y
-# CONFIG_SND_USB_AUDIO is not set
-# CONFIG_SND_USB_UA101 is not set
-# CONFIG_SND_USB_USX2Y is not set
-# CONFIG_SND_USB_CAIAQ is not set
+# CONFIG_SND_PPC is not set
+# CONFIG_SND_USB is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 3a2ade2..bea1f59 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -65,6 +65,14 @@ config MPC85xx_RDB
help
This option enables support for the MPC85xx RDB (P2020 RDB) board
+config P1022_DS
+ bool "Freescale P1022 DS"
+ select DEFAULT_UIMAGE
+ select CONFIG_PHYS_64BIT # The DTS has 36-bit addresses
+ select SWIOTLB
+ help
+ This option enables support for the Freescale P1022DS reference board.
+
config SOCRATES
bool "Socrates"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 387c128..a2ec3f8 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_MPC8536_DS) += mpc8536_ds.o
obj-$(CONFIG_MPC85xx_DS) += mpc85xx_ds.o
obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
+obj-$(CONFIG_P1022_DS) += p1022_ds.o
obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
new file mode 100644
index 0000000..e1467c9
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -0,0 +1,148 @@
+/*
+ * P1022DS board specific routines
+ *
+ * Authors: Travis Wheatley <travis.wheatley@freescale.com>
+ * Dave Liu <daveliu@freescale.com>
+ * Timur Tabi <timur@freescale.com>
+ *
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ *
+ * This file is taken from the Freescale P1022DS BSP, with modifications:
+ * 1) No DIU support (pending rewrite of DIU code)
+ * 2) No AMP support
+ * 3) No PCI endpoint support
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/pci.h>
+#include <linux/of_platform.h>
+#include <linux/lmb.h>
+
+#include <asm/mpic.h>
+#include <asm/swiotlb.h>
+
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+
+void __init p1022_ds_pic_init(void)
+{
+ struct mpic *mpic;
+ struct resource r;
+ struct device_node *np;
+
+ np = of_find_node_by_type(NULL, "open-pic");
+ if (!np) {
+ pr_err("Could not find open-pic node\n");
+ return;
+ }
+
+ if (of_address_to_resource(np, 0, &r)) {
+ pr_err("Failed to map mpic register space\n");
+ of_node_put(np);
+ return;
+ }
+
+ mpic = mpic_alloc(np, r.start,
+ MPIC_PRIMARY | MPIC_WANTS_RESET |
+ MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS |
+ MPIC_SINGLE_DEST_CPU,
+ 0, 256, " OpenPIC ");
+
+ BUG_ON(mpic == NULL);
+ of_node_put(np);
+
+ mpic_init(mpic);
+}
+
+#ifdef CONFIG_SMP
+void __init mpc85xx_smp_init(void);
+#endif
+
+/*
+ * Setup the architecture
+ */
+static void __init p1022_ds_setup_arch(void)
+{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+#endif
+ dma_addr_t max = 0xffffffff;
+
+ if (ppc_md.progress)
+ ppc_md.progress("p1022_ds_setup_arch()", 0);
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, "pci", "fsl,p1022-pcie") {
+ struct resource rsrc;
+ struct pci_controller *hose;
+
+ of_address_to_resource(np, 0, &rsrc);
+
+ if ((rsrc.start & 0xfffff) == 0x8000)
+ fsl_add_bridge(np, 1);
+ else
+ fsl_add_bridge(np, 0);
+
+ hose = pci_find_hose_for_OF_device(np);
+ max = min(max, hose->dma_window_base_cur +
+ hose->dma_window_size);
+ }
+#endif
+
+#ifdef CONFIG_SMP
+ mpc85xx_smp_init();
+#endif
+
+#ifdef CONFIG_SWIOTLB
+ if (lmb_end_of_DRAM() > max) {
+ ppc_swiotlb_enable = 1;
+ set_pci_dma_ops(&swiotlb_dma_ops);
+ ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
+ }
+#endif
+
+ pr_info("Freescale P1022 DS reference board\n");
+}
+
+static struct of_device_id __initdata p1022_ds_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ { .compatible = "simple-bus", },
+ { .compatible = "gianfar", },
+ {},
+};
+
+static int __init p1022_ds_publish_devices(void)
+{
+ return of_platform_bus_probe(NULL, p1022_ds_ids, NULL);
+}
+machine_device_initcall(p1022_ds, p1022_ds_publish_devices);
+
+machine_arch_initcall(p1022_ds, swiotlb_setup_bus_notifier);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init p1022_ds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "fsl,p1022ds");
+}
+
+define_machine(p1022_ds) {
+ .name = "P1022 DS",
+ .probe = p1022_ds_probe,
+ .setup_arch = p1022_ds_setup_arch,
+ .init_IRQ = p1022_ds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.7.0.1
^ permalink raw reply related
* Re: [PATCH] powerpc: introduce basic support for the Freescale P1022DS reference board
From: Timur Tabi @ 2010-07-02 20:54 UTC (permalink / raw)
To: sandeep.kumar; +Cc: linuxppc-dev
In-Reply-To: <20100629171904.d6ae6233.kim.phillips@freescale.com>
Sandeep,
I believe you are the author of the code that adds multiple queue and
multiple group support to the Gianfar driver. Can you update
Documentation/powerpc/dts-bindings/fsl/tsec.txt with the binding
documentation for these nodes, so that we can all know what they're supposed
to look like?
Kim Phillips wrote:
>> + enet0: ethernet@B0000 {
>> + queue-group@0{
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0xB0000 0x1000>;
>> + fsl,rx-err-int-map = <0xAA>;
>> + fsl,tx-int-map = <0xAA>;
>> + interrupts = <29 2 30 2 34 2>;
>> + };
>> + queue-group@1{
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0xB4000 0x1000>;
>> + fsl,rx-err-int-map = <0x55>;
>> + fsl,tx-int-map = <0x55>;
>> + interrupts = <17 2 18 2 24 2>;
>> + };
>> + };
>> +
>> + enet1: ethernet@B1000 {
>
>> + queue-group@0{
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0xB1000 0x1000>;
>> + fsl,rx-err-int-map = <0xAA>;
>> + fsl,tx-int-map = <0xAA>;
>> + interrupts = <35 2 36 2 40 2>;
>> + };
>> + queue-group@1{
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0xB5000 0x1000>;
>> + fsl,rx-err-int-map = <0x55>;
>> + fsl,tx-int-map = <0x55>;
>> + interrupts = <51 2 52 2 67 2>;
>> + };
>
> these queue-group nodes, fsl,{r,t}x-* properties...
>
>> + crypto@30000 {
>
>> + fsl,multi-host-mode = "dual";
>> + fsl,channel-remap = <0x3>;
>
> and the above two properties aren't supported by their respective
> drivers, nor are they listed in the dts bindings documentation.
>
> Kim
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Scott Wood @ 2010-07-02 19:41 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTimX7G59glJ9CQZpT-Zlb3EUsJ1Lil4_80BOi1Nk@mail.gmail.com>
On Fri, 2 Jul 2010 12:16:11 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:
> >> The chipselect? Isn't it just the child-bus-addr? BTW, do we have
> >> to define the #address-cells to 2? 1 is not enough?
> >
> > The first cell of the child bus address is the chip select, the
> > second cell is the offset into the chip select.
>=20
> I see. So the #address-sells of 2 doesn't necessarily indicate the
> address is 64 bits?
Well, there's 64 bits of data, but it doesn't mean that it's one 64-bit
integer.
> Different processors can interpret it differently?
Different device tree bus types can -- though in this case it translates
to an ordinary CPU address using the standand ranges property.
> Where can I find such info? Is there any doc on this?
Documentation/powerpc/dts-bindings/fsl/lbc.txt
> I have a question on the serial settings. Why does it locate at 0xa80?
> According to MPC885RM.pdf, the SMC1's registers start from 0xa82.=20
I suppose the interpretation was that the register block starts at
0xa80, and the first register within that block is at 0xa82 -- though
the manual seems to actually lump those two reserved bytes in with the
previous section.
> What does the reg property specify here for SMC1, the first set of <0xa80
> 0x10> and the 2nd <0x3e80 0x40>?
=46rom Documentation/powerpc/dts-bindings/fsl/cpm.txt:
> - reg : Unless otherwise specified, the first resource represents the =20
> scc/fcc/ucc registers, and the second represents the device's
> parameter RAM region (if it has one).
-Scott
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-07-02 19:16 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <20100702124713.2e2d300c@schlenkerla.am.freescale.net>
>> The chipselect? Isn't it just the child-bus-addr? BTW, do we have to
>> define the #address-cells to 2? 1 is not enough?
>
> The first cell of the child bus address is the chip select, the second
> cell is the offset into the chip select.
I see. So the #address-sells of 2 doesn't necessarily indicate the
address is 64 bits? Different processors can interpret it differently?
Where can I find such info? Is there any doc on this?
I have a question on the serial settings. Why does it locate at 0xa80?
According to MPC885RM.pdf, the SMC1's registers start from 0xa82. What
does the reg property specify here for SMC1, the first set of <0xa80
0x10> and the 2nd <0x3e80 0x40>?
console: serial@a80 {
device_type = "serial";
compatible = "fsl,mpc875-smc-uart",
"fsl,cpm1-smc-uart";
reg = <0xa80 0x10 0x3e80 0x40>;
interrupts = <4>;
interrupt-parent = <&CPM_PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x0090>;
current-speed = <115200>;
Thanks a lot,
-Shawn.
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Scott Wood @ 2010-07-02 19:10 UTC (permalink / raw)
To: Alexander Graf
Cc: KVM list, kvm-ppc, Dan Hettena, linuxppc-dev, Hollis Blanchard
In-Reply-To: <3085B58A-01A1-4B5C-A0E7-024DCFDFD4B2@suse.de>
On Fri, 2 Jul 2010 20:47:44 +0200
Alexander Graf <agraf@suse.de> wrote:
>
> On 02.07.2010, at 19:59, Hollis Blanchard wrote:
>
> > [Resending...]
> >
> > Please reconcile this with
> > http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
> > discussed in the (admittedly closed) Power.org embedded hypervisor
> > working group. Bear in mind that other hypervisors are already
> > implementing the documented ABI, so if you have concerns, you should
> > probably raise them with that audience...
>
> We can not use sc with LV=1 because that would break the KVM in
> something else case which is KVM's strong point on PPC.
The current proposal involves the hypervisor specifying the hcall opcode
sequence in the device tree -- to allow either "sc 1" or "sc 0 plus
magic GPR" depending on whether you've got the hardware hypervisor
feature (hereafter HHV).
With HHV, "sc 0 plus magic GPR" just doesn't work, since it won't trap
to the hypervisor. "sc 1 plus magic GPR" might be problematic on some
non-HHV implementations, especially if you *do* have HHV but the
non-HHV hypervisor is running as an HHV guest.
-Scott
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Alexander Graf @ 2010-07-02 18:47 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Scott Wood, linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <AANLkTiksUkrO8ryEiX3Yv-_2KGVE6r5RIT4YDvrmoDPL@mail.gmail.com>
On 02.07.2010, at 19:59, Hollis Blanchard wrote:
> [Resending...]
>=20
> Please reconcile this with
> http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
> discussed in the (admittedly closed) Power.org embedded hypervisor
> working group. Bear in mind that other hypervisors are already
> implementing the documented ABI, so if you have concerns, you should
> probably raise them with that audience...
We can not use sc with LV=3D1 because that would break the KVM in =
something else case which is KVM's strong point on PPC.
Alex
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Alexander Graf @ 2010-07-02 18:41 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <EB2E1C5B-118B-481B-83D6-44CFAA2E55D3@kernel.crashing.org>
On 02.07.2010, at 18:27, Segher Boessenkool wrote:
>> +To find out if we're running on KVM or not, we overlay the PVR =
register. Usually
>> +the PVR register contains an id that identifies your CPU type. If, =
however, you
>> +pass KVM_PVR_PARA in the register that you want the PVR result in, =
the register
>> +still contains KVM_PVR_PARA after the mfpvr call.
>> +
>> + LOAD_REG_IMM(r5, KVM_PVR_PARA)
>> + mfpvr r5
>> + [r5 still contains KVM_PVR_PARA]
>=20
> I love this part :-)
:)
>=20
>> + __u64 scratch3;
>> + __u64 critical; /* Guest may not get interrupts if =3D=3D =
r1 */
>> + __u64 sprg0;
>> + __u64 sprg1;
>> + __u64 sprg2;
>> + __u64 sprg3;
>> + __u64 srr0;
>> + __u64 srr1;
>> + __u64 dar;
>> + __u64 msr;
>> + __u32 dsisr;
>> + __u32 int_pending; /* Tells the guest if we have an =
interrupt */
>> +};
>> +
>> +Additions to the page must only occur at the end. Struct fields are =
always 32
>> +bit aligned.
>=20
> The u64s are 64-bit aligned, should they always be?
That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit =
aligned, no? At least that's what ld and std specify.
>=20
>> +The "ld" and "std" instructions are transormed to "lwz" and "stw" =
instructions
>> +respectively on 32 bit systems with an added offset of 4 to =
accomodate for big
>> +endianness.
>=20
> Will this add never overflow? Is there anything that checks for it?
It basically means that to access dar, we either do
ld rX, DAR(0)
or
lwz rX, DAR+4(0)
>=20
>> +mtmsrd rX, 0 b <special mtmsr section>
>> +mtmsr b <special mtmsr section>
>=20
> mtmsr rX
Nod.
Alex
^ permalink raw reply
* Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
From: Hollis Blanchard @ 2010-07-02 17:59 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1277980982-12433-28-git-send-email-agraf@suse.de>
[Resending...]
Please reconcile this with
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
discussed in the (admittedly closed) Power.org embedded hypervisor
working group. Bear in mind that other hypervisors are already
implementing the documented ABI, so if you have concerns, you should
probably raise them with that audience...
-Hollis
On Thu, Jul 1, 2010 at 3:43 AM, Alexander Graf <agraf@suse.de> wrote:
>
> We just introduced a new PV interface that screams for documentation. So =
here
> it is - a shiny new and awesome text file describing the internal works o=
f
> the PPC KVM paravirtual interface.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v1 -> v2:
>
> =A0- clarify guest implementation
> =A0- clarify that privileged instructions still work
> =A0- explain safe MSR bits
> =A0- Fix dsisr patch description
> =A0- change hypervisor calls to use new register values
> ---
> =A0Documentation/kvm/ppc-pv.txt | =A0185 ++++++++++++++++++++++++++++++++=
++++++++++
> =A01 files changed, 185 insertions(+), 0 deletions(-)
> =A0create mode 100644 Documentation/kvm/ppc-pv.txt
>
> diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/kvm/ppc-pv.txt
> new file mode 100644
> index 0000000..82de6c6
> --- /dev/null
> +++ b/Documentation/kvm/ppc-pv.txt
> @@ -0,0 +1,185 @@
> +The PPC KVM paravirtual interface
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +The basic execution principle by which KVM on PowerPC works is to run al=
l kernel
> +space code in PR=3D1 which is user space. This way we trap all privilege=
d
> +instructions and can emulate them accordingly.
> +
> +Unfortunately that is also the downfall. There are quite some privileged
> +instructions that needlessly return us to the hypervisor even though the=
y
> +could be handled differently.
> +
> +This is what the PPC PV interface helps with. It takes privileged instru=
ctions
> +and transforms them into unprivileged ones with some help from the hyper=
visor.
> +This cuts down virtualization costs by about 50% on some of my benchmark=
s.
> +
> +The code for that interface can be found in arch/powerpc/kernel/kvm*
> +
> +Querying for existence
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +To find out if we're running on KVM or not, we overlay the PVR register.=
Usually
> +the PVR register contains an id that identifies your CPU type. If, howev=
er, you
> +pass KVM_PVR_PARA in the register that you want the PVR result in, the r=
egister
> +still contains KVM_PVR_PARA after the mfpvr call.
> +
> + =A0 =A0 =A0 LOAD_REG_IMM(r5, KVM_PVR_PARA)
> + =A0 =A0 =A0 mfpvr =A0 r5
> + =A0 =A0 =A0 [r5 still contains KVM_PVR_PARA]
> +
> +Once determined to run under a PV capable KVM, you can now use hypercall=
s as
> +described below.
> +
> +PPC hypercalls
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +The only viable ways to reliably get from guest context to host context =
are:
> +
> + =A0 =A0 =A0 1) Call an invalid instruction
> + =A0 =A0 =A0 2) Call the "sc" instruction with a parameter to "sc"
> + =A0 =A0 =A0 3) Call the "sc" instruction with parameters in GPRs
> +
> +Method 1 is always a bad idea. Invalid instructions can be replaced late=
r on
> +by valid instructions, rendering the interface broken.
> +
> +Method 2 also has downfalls. If the parameter to "sc" is !=3D 0 the spec=
is
> +rather unclear if the sc is targeted directly for the hypervisor or the
> +supervisor. It would also require that we read the syscall issuing instr=
uction
> +every time a syscall is issued, slowing down guest syscalls.
> +
> +Method 3 is what KVM uses. We pass magic constants (KVM_SC_MAGIC_R0 and
> +KVM_SC_MAGIC_R3) in r0 and r3 respectively. If a syscall instruction wit=
h these
> +magic values arrives from the guest's kernel mode, we take the syscall a=
s a
> +hypercall.
> +
> +The parameters are as follows:
> +
> + =A0 =A0 =A0 r0 =A0 =A0 =A0 =A0 =A0 =A0 =A0KVM_SC_MAGIC_R0
> + =A0 =A0 =A0 r3 =A0 =A0 =A0 =A0 =A0 =A0 =A0KVM_SC_MAGIC_R3 =A0 =A0 =A0 =
=A0 Return code
> + =A0 =A0 =A0 r4 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hypercall number
> + =A0 =A0 =A0 r5 =A0 =A0 =A0 =A0 =A0 =A0 =A0First parameter
> + =A0 =A0 =A0 r6 =A0 =A0 =A0 =A0 =A0 =A0 =A0Second parameter
> + =A0 =A0 =A0 r7 =A0 =A0 =A0 =A0 =A0 =A0 =A0Third parameter
> + =A0 =A0 =A0 r8 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fourth parameter
> +
> +Hypercall definitions are shared in generic code, so the same hypercall =
numbers
> +apply for x86 and powerpc alike.
> +
> +The magic page
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +To enable communication between the hypervisor and guest there is a new =
shared
> +page that contains parts of supervisor visible register state. The guest=
can
> +map this shared page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE.
> +
> +With this hypercall issued the guest always gets the magic page mapped a=
t the
> +desired location in effective and physical address space. For now, we al=
ways
> +map the page to -4096. This way we can access it using absolute load and=
store
> +functions. The following instruction reads the first field of the magic =
page:
> +
> + =A0 =A0 =A0 ld =A0 =A0 =A0rX, -4096(0)
> +
> +The interface is designed to be extensible should there be need later to=
add
> +additional registers to the magic page. If you add fields to the magic p=
age,
> +also define a new hypercall feature to indicate that the host can give y=
ou more
> +registers. Only if the host supports the additional features, make use o=
f them.
> +
> +The magic page has the following layout as described in
> +arch/powerpc/include/asm/kvm_para.h:
> +
> +struct kvm_vcpu_arch_shared {
> + =A0 =A0 =A0 __u64 scratch1;
> + =A0 =A0 =A0 __u64 scratch2;
> + =A0 =A0 =A0 __u64 scratch3;
> + =A0 =A0 =A0 __u64 critical; =A0 =A0 =A0 =A0 /* Guest may not get interr=
upts if =3D=3D r1 */
> + =A0 =A0 =A0 __u64 sprg0;
> + =A0 =A0 =A0 __u64 sprg1;
> + =A0 =A0 =A0 __u64 sprg2;
> + =A0 =A0 =A0 __u64 sprg3;
> + =A0 =A0 =A0 __u64 srr0;
> + =A0 =A0 =A0 __u64 srr1;
> + =A0 =A0 =A0 __u64 dar;
> + =A0 =A0 =A0 __u64 msr;
> + =A0 =A0 =A0 __u32 dsisr;
> + =A0 =A0 =A0 __u32 int_pending; =A0 =A0 =A0/* Tells the guest if we have=
an interrupt */
> +};
> +
> +Additions to the page must only occur at the end. Struct fields are alwa=
ys 32
> +bit aligned.
> +
> +MSR bits
> +=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +The MSR contains bits that require hypervisor intervention and bits that=
do
> +not require direct hypervisor intervention because they only get interpr=
eted
> +when entering the guest or don't have any impact on the hypervisor's beh=
avior.
> +
> +The following bits are safe to be set inside the guest:
> +
> + =A0MSR_EE
> + =A0MSR_RI
> + =A0MSR_CR
> + =A0MSR_ME
> +
> +If any other bit changes in the MSR, please still use mtmsr(d).
> +
> +Patched instructions
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +The "ld" and "std" instructions are transormed to "lwz" and "stw" instru=
ctions
> +respectively on 32 bit systems with an added offset of 4 to accomodate f=
or big
> +endianness.
> +
> +The following is a list of mapping the Linux kernel performs when runnin=
g as
> +guest. Implementing any of those mappings is optional, as the instructio=
n traps
> +also act on the shared page. So calling privileged instructions still wo=
rks as
> +before.
> +
> +From =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To
> +=3D=3D=3D=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D=3D
> +
> +mfmsr =A0rX =A0 =A0 =A0 =A0 =A0 =A0 =A0ld =A0 =A0 =A0rX, magic_page->msr
> +mfsprg rX, 0 =A0 =A0 =A0 =A0 =A0 ld =A0 =A0 =A0rX, magic_page->sprg0
> +mfsprg rX, 1 =A0 =A0 =A0 =A0 =A0 ld =A0 =A0 =A0rX, magic_page->sprg1
> +mfsprg rX, 2 =A0 =A0 =A0 =A0 =A0 ld =A0 =A0 =A0rX, magic_page->sprg2
> +mfsprg rX, 3 =A0 =A0 =A0 =A0 =A0 ld =A0 =A0 =A0rX, magic_page->sprg3
> +mfsrr0 rX =A0 =A0 =A0 =A0 =A0 =A0 =A0ld =A0 =A0 =A0rX, magic_page->srr0
> +mfsrr1 rX =A0 =A0 =A0 =A0 =A0 =A0 =A0ld =A0 =A0 =A0rX, magic_page->srr1
> +mfdar =A0rX =A0 =A0 =A0 =A0 =A0 =A0 =A0ld =A0 =A0 =A0rX, magic_page->dar
> +mfdsisr =A0 =A0 =A0 =A0rX =A0 =A0 =A0 =A0 =A0 =A0 =A0lwz =A0 =A0 rX, mag=
ic_page->dsisr
> +
> +mtmsr =A0rX =A0 =A0 =A0 =A0 =A0 =A0 =A0std =A0 =A0 rX, magic_page->msr
> +mtsprg 0, rX =A0 =A0 =A0 =A0 =A0 std =A0 =A0 rX, magic_page->sprg0
> +mtsprg 1, rX =A0 =A0 =A0 =A0 =A0 std =A0 =A0 rX, magic_page->sprg1
> +mtsprg 2, rX =A0 =A0 =A0 =A0 =A0 std =A0 =A0 rX, magic_page->sprg2
> +mtsprg 3, rX =A0 =A0 =A0 =A0 =A0 std =A0 =A0 rX, magic_page->sprg3
> +mtsrr0 rX =A0 =A0 =A0 =A0 =A0 =A0 =A0std =A0 =A0 rX, magic_page->srr0
> +mtsrr1 rX =A0 =A0 =A0 =A0 =A0 =A0 =A0std =A0 =A0 rX, magic_page->srr1
> +mtdar =A0rX =A0 =A0 =A0 =A0 =A0 =A0 =A0std =A0 =A0 rX, magic_page->dar
> +mtdsisr =A0 =A0 =A0 =A0rX =A0 =A0 =A0 =A0 =A0 =A0 =A0stw =A0 =A0 rX, mag=
ic_page->dsisr
> +
> +tlbsync =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nop
> +
> +mtmsrd rX, 0 =A0 =A0 =A0 =A0 =A0 b =A0 =A0 =A0 <special mtmsr section>
> +mtmsr =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b =A0 =A0 =A0 <special mtmsr se=
ction>
> +
> +mtmsrd rX, 1 =A0 =A0 =A0 =A0 =A0 b =A0 =A0 =A0 <special mtmsrd section>
> +
> +[BookE only]
> +wrteei [0|1] =A0 =A0 =A0 =A0 =A0 b =A0 =A0 =A0 <special wrteei section>
> +
> +
> +Some instructions require more logic to determine what's going on than a=
load
> +or store instruction can deliver. To enable patching of those, we keep s=
ome
> +RAM around where we can live translate instructions to. What happens is =
the
> +following:
> +
> + =A0 =A0 =A0 1) copy emulation code to memory
> + =A0 =A0 =A0 2) patch that code to fit the emulated instruction
> + =A0 =A0 =A0 3) patch that code to return to the original pc + 4
> + =A0 =A0 =A0 4) patch the original instruction to branch to the new code
> +
> +That way we can inject an arbitrary amount of code as replacement for a =
single
> +instruction. This allows us to check for pending interrupts when setting=
EE=3D1
> +for example.
> +
> --
> 1.6.0.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Scott Wood @ 2010-07-02 17:47 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTikELusybzh2uTh3KJ6QwelgSHW6HWWPLh-4Zc0b@mail.gmail.com>
On Fri, 2 Jul 2010 10:06:47 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:
> > Or more generally update this section to hold whatever is connected
> > to the localbus on your board. =A0The first cell is the chipselect.
>=20
> The chipselect? Isn't it just the child-bus-addr? BTW, do we have to
> define the #address-cells to 2? 1 is not enough?
The first cell of the child bus address is the chip select, the second
cell is the offset into the chip select.
> SDRAM uses CS0/6, each 64MB. BDI2000 configuration is as follows.
> ; init memory controller
> WM32 0xFA200104 0xfe000ff6 ;;OR0: Flash 32MB
> WM32 0xFA200100 0xfc000001 ;;BR0: Flash at 0xFC000000,
> 32bit, R/W, no parity, use GPCM
> WM32 0xFA20010C 0xfc000e00 ;;OR1: SDRAM 64MB, all
> accesses WM32 0xFA200108 0x00000081 ;;BR1: SDRAM at
> 0x00000000, 32bit, R/W, no parity, use UPMA
> WM32 0xFA200134 0xfc000e00 ;;OR6: SDRAM 64MB, all
> accesses WM32 0xFA200130 0x04000081 ;;BR6: SDRAM at
> 0x04000000, 32bit, R/W, no parity, use UPMA
That looks like SDRAM is on CS1/6, not CS0/6.
We haven't been putting ordinary RAM under the localbus node, even
though it's connected through the localbus on these chips.
> When defining memory's reg property, can a single pair <0 0x08000000>
> be enough? Or must it be <0 0x04000000 0x04000000 0x04000000>?
A single pair is fine.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox