* [PATCH] powerpc: Restore dma ops for powermac cardbus drivers
From: roger blofeld @ 2009-11-30 4:23 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, stable
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
Commit 4ae0ff606e848fa4957ebf8f97e5db5fdeec27be broke dma setup for cardbus
devices such as sata_sil, rt2500 and ath5k. This patch restores the default
dma ops for cardbus devices. Tested with sata_sil on a powerbook G4.
bz#537176
Signed-off-by: Roger Blofeld <blofeldus@yahoo.com>
---
The inline patch is whitespace damaged by this mailer. The attachment should be ok,
and passes checkpatch.pl
diff -up linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c
--- linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig 2009-06-09 22:05:27.000000000 -0500
+++ linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c 2009-11-29 21:47:15.000000000 -0600
@@ -514,6 +514,44 @@ static void __init pmac_init_early(void)
#endif
}
+#ifdef CONFIG_CARDBUS
+static int pmac_cardbus_notify(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct device *dev = data;
+ struct device *parent;
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ /* We are only interested in device addition */
+ if (action != BUS_NOTIFY_ADD_DEVICE)
+ return 0;
+
+ parent = pdev->dev.parent;
+
+ if (!parent->archdata.of_node)
+ return 0;
+
+ if (!of_device_is_compatible(parent->archdata.of_node,
+ "cardbus-bridge"))
+ return 0;
+
+ /* We use the direct ops for cardbus */
+ dev->archdata.dma_ops = &dma_direct_ops;
+
+ return 0;
+}
+
+static struct notifier_block cardbus_notifier = {
+ .notifier_call = pmac_cardbus_notify,
+};
+
+static int __init pmac_cardbus_init(void)
+{
+ return bus_register_notifier(&pci_bus_type, &cardbus_notifier);
+}
+machine_device_initcall(powermac, pmac_cardbus_init);
+#endif
+
static int __init pmac_declare_of_platform_devices(void)
{
struct device_node *np;
[-- Attachment #2: powermac-cardbus-dma-notifier.patch --]
[-- Type: application/octet-stream, Size: 1719 bytes --]
[PATCH] powerpc: Restore dma ops for powermac cardbus drivers
Commit 4ae0ff606e848fa4957ebf8f97e5db5fdeec27be broke dma setup for cardbus
devices such as sata_sil, rt2500 and ath5k. This patch restores the default
dma ops for cardbus devices. Tested with sata_sil on a powerbook G4.
bz#537176
Signed-off-by: Roger Blofeld <blofeldus@yahoo.com>
diff -up linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c
--- linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig 2009-06-09 22:05:27.000000000 -0500
+++ linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c 2009-11-29 21:47:15.000000000 -0600
@@ -514,6 +514,44 @@ static void __init pmac_init_early(void)
#endif
}
+#ifdef CONFIG_CARDBUS
+static int pmac_cardbus_notify(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct device *dev = data;
+ struct device *parent;
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ /* We are only interested in device addition */
+ if (action != BUS_NOTIFY_ADD_DEVICE)
+ return 0;
+
+ parent = pdev->dev.parent;
+
+ if (!parent->archdata.of_node)
+ return 0;
+
+ if (!of_device_is_compatible(parent->archdata.of_node,
+ "cardbus-bridge"))
+ return 0;
+
+ /* We use the direct ops for cardbus */
+ dev->archdata.dma_ops = &dma_direct_ops;
+
+ return 0;
+}
+
+static struct notifier_block cardbus_notifier = {
+ .notifier_call = pmac_cardbus_notify,
+};
+
+static int __init pmac_cardbus_init(void)
+{
+ return bus_register_notifier(&pci_bus_type, &cardbus_notifier);
+}
+machine_device_initcall(powermac, pmac_cardbus_init);
+#endif
+
static int __init pmac_declare_of_platform_devices(void)
{
struct device_node *np;
^ permalink raw reply
* Re: [PATCH] powerpc: Restore dma ops for powermac cardbus drivers
From: Benjamin Herrenschmidt @ 2009-11-30 5:49 UTC (permalink / raw)
To: roger blofeld; +Cc: linuxppc-dev, stable
In-Reply-To: <187031.59622.qm@web53502.mail.re2.yahoo.com>
On Sun, 2009-11-29 at 20:23 -0800, roger blofeld wrote:
> Commit 4ae0ff606e848fa4957ebf8f97e5db5fdeec27be broke dma setup for cardbus
> devices such as sata_sil, rt2500 and ath5k. This patch restores the default
> dma ops for cardbus devices. Tested with sata_sil on a powerbook G4.
>
> bz#537176
>
> Signed-off-by: Roger Blofeld <blofeldus@yahoo.com>
Hi !
That's an interesting way to do it :-)
However, I suppose a better approach would be to fix cardbus to call the
proper fixup code in the arch, ie, dma isn't the only thing that's going
to be broken without that (at least maybe on pmac that is, but machines
with an iommu will suffer etc...)
I will try to have a look as soon as I'm done with porting the pmac IDE
driver to libata.
Cheers,
Ben.
> ---
> The inline patch is whitespace damaged by this mailer. The attachment should be ok,
> and passes checkpatch.pl
>
>
> diff -up linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c
> --- linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig 2009-06-09 22:05:27.000000000 -0500
> +++ linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c 2009-11-29 21:47:15.000000000 -0600
> @@ -514,6 +514,44 @@ static void __init pmac_init_early(void)
> #endif
> }
>
> +#ifdef CONFIG_CARDBUS
> +static int pmac_cardbus_notify(struct notifier_block *nb, unsigned long action,
> + void *data)
> +{
> + struct device *dev = data;
> + struct device *parent;
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + /* We are only interested in device addition */
> + if (action != BUS_NOTIFY_ADD_DEVICE)
> + return 0;
> +
> + parent = pdev->dev.parent;
> +
> + if (!parent->archdata.of_node)
> + return 0;
> +
> + if (!of_device_is_compatible(parent->archdata.of_node,
> + "cardbus-bridge"))
> + return 0;
> +
> + /* We use the direct ops for cardbus */
> + dev->archdata.dma_ops = &dma_direct_ops;
> +
> + return 0;
> +}
> +
> +static struct notifier_block cardbus_notifier = {
> + .notifier_call = pmac_cardbus_notify,
> +};
> +
> +static int __init pmac_cardbus_init(void)
> +{
> + return bus_register_notifier(&pci_bus_type, &cardbus_notifier);
> +}
> +machine_device_initcall(powermac, pmac_cardbus_init);
> +#endif
> +
> static int __init pmac_declare_of_platform_devices(void)
> {
> struct device_node *np;
>
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 08/11] powerpc: gamecube/wii: early debugging using usbgecko
From: Albert Herranz @ 2009-11-30 5:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259536695.2076.40.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Sat, 2009-11-28 at 21:43 +0100, Albert Herranz wrote:
>> + * Prepare again the same BAT for MMU_init.
>> + * This allows udbg I/O to continue working after the MMU is
>> + * turned on for real.
>> + *
>> + * We are assuming here that exi_io_base is identity mapped.
>> + */
>> + addr = ((unsigned long)exi_io_base) & 0xffff0000;
>> + setbat(1, addr, addr, 128*1024, PAGE_KERNEL_NCG);
>
> How do you prevent that from overlapping otherwise valid kernel
> mappings ?
>
ug_udbg_init() is called from ppc_md.init_early.
It doesn't overlap any valid kernel mappings because exi_io_base is hardcoded to an i/o region not used yet by the kernel.
See udbg_early_grab_exi_io_base().
The setbat just prepares again, exactly in the same way, the same BAT that we got setup by setup_usbgecko_bat in head_32.S.
_start
__start
> early_init
> mmu_off
# mmu off
> clear_bats
> flush_tlbs
> initial_bats
> setup_usbgecko_bat <--- BAT1 setup here
> call_setup_cpu
> init_idle_6xx
! relocate_kernel
! turn_on_mmu
# mmu on
! start_here
> machine_init
>> udbg_early_init
>>> udbg_init_usbgecko <--- BAT1 prepared again here for after MMU_init
>> early_init_devtree
> __save_cpu_setup
> MMU_init
# mmu off
> load_up_mmu
# mmu on
! start_kernel
> You need to allocate the virtual space. For a debug thing like that, you
> could use the fixmap. In fact, I think we should create a fixmap entry
> or two always available for use by early debug.
>
Or give us back ppc_md.setup_io_mappings :)
> Cheers,
> Ben.
>
Thanks,
Albert
^ permalink raw reply
* Re: [RFC PATCH v2 08/11] powerpc: gamecube/wii: early debugging using usbgecko
From: Benjamin Herrenschmidt @ 2009-11-30 6:14 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B135D3D.9030006@yahoo.es>
On Mon, 2009-11-30 at 06:50 +0100, Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
> > On Sat, 2009-11-28 at 21:43 +0100, Albert Herranz wrote:
> >> + * Prepare again the same BAT for MMU_init.
> >> + * This allows udbg I/O to continue working after the MMU is
> >> + * turned on for real.
> >> + *
> >> + * We are assuming here that exi_io_base is identity mapped.
> >> + */
> >> + addr = ((unsigned long)exi_io_base) & 0xffff0000;
> >> + setbat(1, addr, addr, 128*1024, PAGE_KERNEL_NCG);
> >
> > How do you prevent that from overlapping otherwise valid kernel
> > mappings ?
> >
>
> ug_udbg_init() is called from ppc_md.init_early.
> It doesn't overlap any valid kernel mappings because exi_io_base is
> hardcoded to an i/o region not used yet by the kernel.
But that doesn't allocate virtual space does it ?
> See udbg_early_grab_exi_io_base().
Yeah, I see that:
+#if defined(CONFIG_GAMECUBE)
+ return (void __iomem *)0x0c006800;
+#elif defined(CONFIG_WII)
+ return (void __iomem *)0x0d006800;
+#else
So you'll have BATs floating over user addresses ? That sounds fishy :-)
It should be trivial to just create a fixmap entry instead. That will
give you a virtual address that is known at compile time (so you can
use it from head_32.S as well for setting up your BAT).
Actually you probably need more than one entry in there since it needs
to be big enough to cover a BAT min size and be aligned, but it's not
-that- hard to do (I think x86 does similar tricks in their fixmap
iirc)
> The setbat just prepares again, exactly in the same way, the same BAT that we got
> setup by setup_usbgecko_bat in head_32.S.
.../...
> > You need to allocate the virtual space. For a debug thing like that, you
> > could use the fixmap. In fact, I think we should create a fixmap entry
> > or two always available for use by early debug.
> >
>
> Or give us back ppc_md.setup_io_mappings :)
Not happening :-) Or if you get one, it will allocate virtual addresses
and so you cannot rely on an identity mapping.
^ permalink raw reply
* Re: [RFC PATCH v2 08/11] powerpc: gamecube/wii: early debugging using usbgecko
From: Albert Herranz @ 2009-11-30 6:15 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <4B135D3D.9030006@yahoo.es>
Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
>> On Sat, 2009-11-28 at 21:43 +0100, Albert Herranz wrote:
>>> + * Prepare again the same BAT for MMU_init.
>>> + * This allows udbg I/O to continue working after the MMU is
>>> + * turned on for real.
>>> + *
>>> + * We are assuming here that exi_io_base is identity mapped.
>>> + */
>>> + addr = ((unsigned long)exi_io_base) & 0xffff0000;
>>> + setbat(1, addr, addr, 128*1024, PAGE_KERNEL_NCG);
>> How do you prevent that from overlapping otherwise valid kernel
>> mappings ?
>>
>
> ug_udbg_init() is called from ppc_md.init_early.
^^^
This got here, but although it's true it doesn't apply here :)
> It doesn't overlap any valid kernel mappings because exi_io_base is hardcoded to an i/o region not used yet by the kernel.
> See udbg_early_grab_exi_io_base().
> The setbat just prepares again, exactly in the same way, the same BAT that we got setup by setup_usbgecko_bat in head_32.S.
>
Thanks,
Albert
^ permalink raw reply
* Re: [RFC PATCH v2 08/11] powerpc: gamecube/wii: early debugging using usbgecko
From: Albert Herranz @ 2009-11-30 6:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259561692.2076.78.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Mon, 2009-11-30 at 06:50 +0100, Albert Herranz wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Sat, 2009-11-28 at 21:43 +0100, Albert Herranz wrote:
>>>> + * Prepare again the same BAT for MMU_init.
>>>> + * This allows udbg I/O to continue working after the MMU is
>>>> + * turned on for real.
>>>> + *
>>>> + * We are assuming here that exi_io_base is identity mapped.
>>>> + */
>>>> + addr = ((unsigned long)exi_io_base) & 0xffff0000;
>>>> + setbat(1, addr, addr, 128*1024, PAGE_KERNEL_NCG);
>>> How do you prevent that from overlapping otherwise valid kernel
>>> mappings ?
>>>
>> ug_udbg_init() is called from ppc_md.init_early.
>> It doesn't overlap any valid kernel mappings because exi_io_base is
>> hardcoded to an i/o region not used yet by the kernel.
>
> But that doesn't allocate virtual space does it ?
>
No.
>> See udbg_early_grab_exi_io_base().
>
> Yeah, I see that:
>
> +#if defined(CONFIG_GAMECUBE)
> + return (void __iomem *)0x0c006800;
> +#elif defined(CONFIG_WII)
> + return (void __iomem *)0x0d006800;
> +#else
>
> So you'll have BATs floating over user addresses ? That sounds fishy :-)
>
Heh, I was told to identity map it :)
Originally it used kernel address space (0xc{c,d}006800).
> It should be trivial to just create a fixmap entry instead. That will
> give you a virtual address that is known at compile time (so you can
> use it from head_32.S as well for setting up your BAT).
>
> Actually you probably need more than one entry in there since it needs
> to be big enough to cover a BAT min size and be aligned, but it's not
> -that- hard to do (I think x86 does similar tricks in their fixmap
> iirc)
>
I've never worked with fixmap entries. I'll look into it. Thanks.
>> The setbat just prepares again, exactly in the same way, the same BAT that we got
>> setup by setup_usbgecko_bat in head_32.S.
>
> .../...
>
>>> You need to allocate the virtual space. For a debug thing like that, you
>>> could use the fixmap. In fact, I think we should create a fixmap entry
>>> or two always available for use by early debug.
>>>
>> Or give us back ppc_md.setup_io_mappings :)
>
> Not happening :-) Or if you get one, it will allocate virtual addresses
> and so you cannot rely on an identity mapping.
>
But we can use then a known mapping scheme, and have all the i/o region covered by bats there.
We can do that already, yes, but setup_io_mappings purpose was originally that, no?
Thanks,
Albert
^ permalink raw reply
* Re: [RFC PATCH v2 08/11] powerpc: gamecube/wii: early debugging using usbgecko
From: Benjamin Herrenschmidt @ 2009-11-30 6:42 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B136624.4030505@yahoo.es>
On Mon, 2009-11-30 at 07:28 +0100, Albert Herranz wrote:
>
>
> Heh, I was told to identity map it :)
Hah ? By whome ? :-)
> Originally it used kernel address space (
> 0xc{c,d}006800).
In any case, kernel space also needs to be reserved. There is no magic
free spot in the kernel virtual space unless you reserve some either by
lowering ioremap_bot early at boot or by using the fixmap (well, there
is if you don't enable HIGHMEM but that's going away soon :-)
> I've never worked with fixmap entries. I'll look into it. Thanks.
Look at fixmap.h, basically it's an emum of reserved pages starting near
the top of the address space and walking down from there. The kernel
ensure that space stays reserved and it gives you things calculated at
compile time (so via asm-offsets.h you can feed them into your asm).
I'm half tempted to say we should just bluntly reserve the top 128K (or
whatever is the min size of a BAT) for that sort of debug crap though
and be done with it :-) Always handy to have some space we know we can
mess around with.
> But we can use then a known mapping scheme, and have all the i/o
> region covered by bats there.
We could yes. I was hoping Grant would produce something there but he
hadn't had time yet.,
> We can do that already, yes, but setup_io_mappings purpose was
> originally that, no?
Sort-of. I don't like hard coding virtual addresses, it causes all sort
of problems (other than in the fixmap). It wouldn't be very hard to
bring back some variant of io_block_mapping() though that works by
moving ioremap_bot down early during boot, and allows you to setup some
IO BATs for perfs reasons. Subsequent ioremaps would automatically pick
up that space and benefit from it.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
From: Li Yang @ 2009-11-30 10:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Li Yang-R58472
In-Reply-To: <19215.14808.476221.223143@drongo.ozlabs.ibm.com>
On Fri, Nov 27, 2009 at 10:30 AM, Paul Mackerras <paulus@samba.org> wrote:
> Li Yang writes:
>
>> That's my concern too. =C2=A0But after all mmap without O_SYNC on I/O
>> devices should be deprecated.
>
> It should? =C2=A0Why?
>
> Shouldn't the onus rather be on those proposing an incompatible change
> to the kernel ABI, such as this is, to show why the change is
> absolutely essential?
In addition to the performance issue I stated earlier in this thread.
There was also cache paradoxes problem too. If a memory region is
shared between two cores/OS'es and Linux can't map the region with the
same cacheable property as the other OS had mapped, there will be a
problem. The best solution for this problem is to make the
cacheablity controllable.
And it seems to be generic issue which does not only exist on powerpc
platforms. So it might be better dealt with the already existed
O_SYNC flag which was meant to deal with this kind of thing. I agree
with your comment in another email that device tree could be used, but
that solution is not generic enough though.
- Leo
^ permalink raw reply
* [PATCH] PPC: Sync guest visible MMU state
From: Alexander Graf @ 2009-11-30 13:02 UTC (permalink / raw)
To: kvm; +Cc: kvm-ppc, linuxppc-dev
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This patch exports enough of the MMU segment state to userspace to make
debugging work and thus also includes the groundwork for migration.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
Ben, please take this patch in your tree.
v2 -> v3:
- don't use anonymous unions/structs
v3 -> v4:
- don't change API to what it was before
---
arch/powerpc/include/asm/kvm.h | 18 +++++++++++-
arch/powerpc/include/asm/kvm_asm.h | 1 +
arch/powerpc/include/asm/kvm_book3s.h | 3 ++
arch/powerpc/kvm/book3s.c | 49 +++++++++++++++++++++++++++++++++
arch/powerpc/kvm/book3s_64_emulate.c | 38 +++++++++++++++----------
arch/powerpc/kvm/book3s_64_mmu.c | 2 +
arch/powerpc/kvm/powerpc.c | 3 ++
include/linux/kvm.h | 3 ++
8 files changed, 101 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index c9ca97f..81f3b0b 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -47,7 +47,23 @@ struct kvm_regs {
struct kvm_sregs {
__u32 pvr;
- char pad[1020];
+ union {
+ struct {
+ __u64 sdr1;
+ struct {
+ struct {
+ __u64 slbe;
+ __u64 slbv;
+ } slb[64];
+ } ppc64;
+ struct {
+ __u32 sr[16];
+ __u64 ibat[8];
+ __u64 dbat[8];
+ } ppc32;
+ } s;
+ __u8 pad[1020];
+ } u;
};
struct kvm_fpu {
diff --git a/arch/powerpc/include/asm/kvm_asm.h b/arch/powerpc/include/asm/kvm_asm.h
index 19ddb35..af2abe7 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -87,6 +87,7 @@
#define BOOK3S_IRQPRIO_MAX 16
#define BOOK3S_HFLAG_DCBZ32 0x1
+#define BOOK3S_HFLAG_SLB 0x2
#define RESUME_FLAG_NV (1<<0) /* Reload guest nonvolatile state? */
#define RESUME_FLAG_HOST (1<<1) /* Resume host? */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index c601133..74b7369 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -46,6 +46,7 @@ struct kvmppc_sr {
};
struct kvmppc_bat {
+ u64 raw;
u32 bepi;
u32 bepi_mask;
bool vs;
@@ -113,6 +114,8 @@ extern struct kvmppc_pte *kvmppc_mmu_find_pte(struct kvm_vcpu *vcpu, u64 ea, boo
extern int kvmppc_ld(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr, bool data);
extern int kvmppc_st(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr);
extern void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, unsigned int vec);
+extern void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat,
+ bool upper, u32 val);
extern u32 kvmppc_trampoline_lowmem;
extern u32 kvmppc_trampoline_enter;
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 42037d4..3e294bd 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -281,6 +281,7 @@ void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu)
void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
{
+ vcpu->arch.hflags &= ~BOOK3S_HFLAG_SLB;
vcpu->arch.pvr = pvr;
if ((pvr >= 0x330000) && (pvr < 0x70330000)) {
kvmppc_mmu_book3s_64_init(vcpu);
@@ -762,14 +763,62 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
+ struct kvmppc_vcpu_book3s *vcpu3s = to_book3s(vcpu);
+ int i;
+
sregs->pvr = vcpu->arch.pvr;
+
+ sregs->u.s.sdr1 = to_book3s(vcpu)->sdr1;
+ if (vcpu->arch.hflags & BOOK3S_HFLAG_SLB) {
+ for (i = 0; i < 64; i++) {
+ sregs->u.s.ppc64.slb[i].slbe = vcpu3s->slb[i].orige | i;
+ sregs->u.s.ppc64.slb[i].slbv = vcpu3s->slb[i].origv;
+ }
+ } else {
+ for (i = 0; i < 16; i++) {
+ sregs->u.s.ppc32.sr[i] = vcpu3s->sr[i].raw;
+ sregs->u.s.ppc32.sr[i] = vcpu3s->sr[i].raw;
+ }
+ for (i = 0; i < 8; i++) {
+ sregs->u.s.ppc32.ibat[i] = vcpu3s->ibat[i].raw;
+ sregs->u.s.ppc32.dbat[i] = vcpu3s->dbat[i].raw;
+ }
+ }
return 0;
}
int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
+ struct kvmppc_vcpu_book3s *vcpu3s = to_book3s(vcpu);
+ int i;
+
kvmppc_set_pvr(vcpu, sregs->pvr);
+
+ vcpu3s->sdr1 = sregs->u.s.sdr1;
+ if (vcpu->arch.hflags & BOOK3S_HFLAG_SLB) {
+ for (i = 0; i < 64; i++) {
+ vcpu->arch.mmu.slbmte(vcpu, sregs->u.s.ppc64.slb[i].slbv,
+ sregs->u.s.ppc64.slb[i].slbe);
+ }
+ } else {
+ for (i = 0; i < 16; i++) {
+ vcpu->arch.mmu.mtsrin(vcpu, i, sregs->u.s.ppc32.sr[i]);
+ }
+ for (i = 0; i < 8; i++) {
+ kvmppc_set_bat(vcpu, &(vcpu3s->ibat[i]), false,
+ (u32)sregs->u.s.ppc32.ibat[i]);
+ kvmppc_set_bat(vcpu, &(vcpu3s->ibat[i]), true,
+ (u32)(sregs->u.s.ppc32.ibat[i] >> 32));
+ kvmppc_set_bat(vcpu, &(vcpu3s->dbat[i]), false,
+ (u32)sregs->u.s.ppc32.dbat[i]);
+ kvmppc_set_bat(vcpu, &(vcpu3s->dbat[i]), true,
+ (u32)(sregs->u.s.ppc32.dbat[i] >> 32));
+ }
+ }
+
+ /* Flush the MMU after messing with the segments */
+ kvmppc_mmu_pte_flush(vcpu, 0, 0);
return 0;
}
diff --git a/arch/powerpc/kvm/book3s_64_emulate.c b/arch/powerpc/kvm/book3s_64_emulate.c
index c343e67..1027eac 100644
--- a/arch/powerpc/kvm/book3s_64_emulate.c
+++ b/arch/powerpc/kvm/book3s_64_emulate.c
@@ -185,7 +185,27 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
return emulated;
}
-static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u64 val)
+void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat, bool upper,
+ u32 val)
+{
+ if (upper) {
+ /* Upper BAT */
+ u32 bl = (val >> 2) & 0x7ff;
+ bat->bepi_mask = (~bl << 17);
+ bat->bepi = val & 0xfffe0000;
+ bat->vs = (val & 2) ? 1 : 0;
+ bat->vp = (val & 1) ? 1 : 0;
+ bat->raw = (bat->raw & 0xffffffff00000000ULL) | val;
+ } else {
+ /* Lower BAT */
+ bat->brpn = val & 0xfffe0000;
+ bat->wimg = (val >> 3) & 0xf;
+ bat->pp = val & 3;
+ bat->raw = (bat->raw & 0x00000000ffffffffULL) | ((u64)val << 32);
+ }
+}
+
+static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u32 val)
{
struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
struct kvmppc_bat *bat;
@@ -207,19 +227,7 @@ static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u64 val)
BUG();
}
- if (!(sprn % 2)) {
- /* Upper BAT */
- u32 bl = (val >> 2) & 0x7ff;
- bat->bepi_mask = (~bl << 17);
- bat->bepi = val & 0xfffe0000;
- bat->vs = (val & 2) ? 1 : 0;
- bat->vp = (val & 1) ? 1 : 0;
- } else {
- /* Lower BAT */
- bat->brpn = val & 0xfffe0000;
- bat->wimg = (val >> 3) & 0xf;
- bat->pp = val & 3;
- }
+ kvmppc_set_bat(vcpu, bat, !(sprn % 2), val);
}
int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
@@ -243,7 +251,7 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
case SPRN_IBAT4U ... SPRN_IBAT7L:
case SPRN_DBAT0U ... SPRN_DBAT3L:
case SPRN_DBAT4U ... SPRN_DBAT7L:
- kvmppc_write_bat(vcpu, sprn, vcpu->arch.gpr[rs]);
+ kvmppc_write_bat(vcpu, sprn, (u32)vcpu->arch.gpr[rs]);
/* BAT writes happen so rarely that we're ok to flush
* everything here */
kvmppc_mmu_pte_flush(vcpu, 0, 0);
diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
index a31f9c6..5598f88 100644
--- a/arch/powerpc/kvm/book3s_64_mmu.c
+++ b/arch/powerpc/kvm/book3s_64_mmu.c
@@ -473,4 +473,6 @@ void kvmppc_mmu_book3s_64_init(struct kvm_vcpu *vcpu)
mmu->esid_to_vsid = kvmppc_mmu_book3s_64_esid_to_vsid;
mmu->ea_to_vp = kvmppc_mmu_book3s_64_ea_to_vp;
mmu->is_dcbz32 = kvmppc_mmu_book3s_64_is_dcbz32;
+
+ vcpu->arch.hflags |= BOOK3S_HFLAG_SLB;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 692c370..d82551e 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -144,6 +144,9 @@ int kvm_dev_ioctl_check_extension(long ext)
int r;
switch (ext) {
+ case KVM_CAP_PPC_SEGSTATE:
+ r = 1;
+ break;
case KVM_CAP_COALESCED_MMIO:
r = KVM_COALESCED_MMIO_PAGE_OFFSET;
break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f8f8900..caf6173 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -436,6 +436,9 @@ struct kvm_ioeventfd {
#endif
#define KVM_CAP_IOEVENTFD 36
#define KVM_CAP_SET_IDENTITY_MAP_ADDR 37
+/* KVM upstream has more features, but we synched this number.
+ Linux, please remove this comment on rebase. */
+#define KVM_CAP_PPC_SEGSTATE 43
#ifdef KVM_CAP_IRQ_ROUTING
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] PPC: Sync guest visible MMU state
From: Avi Kivity @ 2009-11-30 13:15 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <1259586122-19155-1-git-send-email-agraf@suse.de>
On 11/30/2009 03:02 PM, Alexander Graf wrote:
> Currently userspace has no chance to find out which virtual address space we're
> in and resolve addresses. While that is a big problem for migration, it's also
> unpleasent when debugging, as gdb and the monitor don't work on virtual
> addresses.
>
> This patch exports enough of the MMU segment state to userspace to make
> debugging work and thus also includes the groundwork for migration.
>
Looks good. Ben, please carry this in your tree.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
From: Josh Boyer @ 2009-11-30 13:41 UTC (permalink / raw)
To: Curtis Wald; +Cc: linuxppc-dev
In-Reply-To: <13F6A75BE29CE44F801B912901C3EF27022A3993@wgv4.watchguardvideo.local>
On Mon, Nov 16, 2009 at 11:36:40AM -0600, Curtis Wald wrote:
>Yosemite.dts stanza for PCI was copied from Bamboo which has four PCI
>slots; Yosemite only has one PCI slot which is mapped to
>IDSEL 12, ADDR 22, IRQ2 Vector 25, INTA.
>
>Signed-off-by: Curtis Wald <cwald@watchguardvideo.com>
Your patch looks correct (I think), but is very badly word wrapped and
whitespace damaged. Could you resend?
josh
^ permalink raw reply
* Re: [PATCH] powerpc: Restore dma ops for powermac cardbus drivers
From: roger blofeld @ 2009-11-30 14:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259560167.2076.58.camel@pasglop>
> To: roger blofeld <blofeldus@yahoo.com>
> Cc: galak@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; stable@kernel.org
> Sent: Sun, November 29, 2009 11:49:27 PM
> Subject: Re: [PATCH] powerpc: Restore dma ops for powermac cardbus drivers
>
> On Sun, 2009-11-29 at 20:23 -0800, roger blofeld wrote:
> > Commit 4ae0ff606e848fa4957ebf8f97e5db5fdeec27be broke dma setup for cardbus
> > devices such as sata_sil, rt2500 and ath5k. This patch restores the default
> > dma ops for cardbus devices. Tested with sata_sil on a powerbook G4.
> >
> > bz#537176
> >
> > Signed-off-by: Roger Blofeld
>
> Hi !
>
> That's an interesting way to do it :-)
>
> However, I suppose a better approach would be to fix cardbus to call the
> proper fixup code in the arch, ie, dma isn't the only thing that's going
> to be broken without that (at least maybe on pmac that is, but machines
> with an iommu will suffer etc...)
>
> I will try to have a look as soon as I'm done with porting the pmac IDE
> driver to libata.
>
> Cheers,
> Ben.
>
Thanks. That would be great. I just copied this mostly from what pasemi did for their cardbus.
-roger
> > ---
> > The inline patch is whitespace damaged by this mailer. The attachment should
> be ok,
> > and passes checkpatch.pl
> >
> >
> > diff -up linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig
> linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c
> > --- linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig
> 2009-06-09 22:05:27.000000000 -0500
> > +++ linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c 2009-11-29
> 21:47:15.000000000 -0600
> > @@ -514,6 +514,44 @@ static void __init pmac_init_early(void)
> > #endif
> > }
> >
> > +#ifdef CONFIG_CARDBUS
> > +static int pmac_cardbus_notify(struct notifier_block *nb, unsigned long
> action,
> > + void *data)
> > +{
> > + struct device *dev = data;
> > + struct device *parent;
> > + struct pci_dev *pdev = to_pci_dev(dev);
> > +
> > + /* We are only interested in device addition */
> > + if (action != BUS_NOTIFY_ADD_DEVICE)
> > + return 0;
> > +
> > + parent = pdev->dev.parent;
> > +
> > + if (!parent->archdata.of_node)
> > + return 0;
> > +
> > + if (!of_device_is_compatible(parent->archdata.of_node,
> > + "cardbus-bridge"))
> > + return 0;
> > +
> > + /* We use the direct ops for cardbus */
> > + dev->archdata.dma_ops = &dma_direct_ops;
> > +
> > + return 0;
> > +}
> > +
> > +static struct notifier_block cardbus_notifier = {
> > + .notifier_call = pmac_cardbus_notify,
> > +};
> > +
> > +static int __init pmac_cardbus_init(void)
> > +{
> > + return bus_register_notifier(&pci_bus_type, &cardbus_notifier);
> > +}
> > +machine_device_initcall(powermac, pmac_cardbus_init);
> > +#endif
> > +
> > static int __init pmac_declare_of_platform_devices(void)
> > {
> > struct device_node *np;
> >
> >
> >
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: hypervisor call tracepoints hcall_stats touchup.
From: Will Schmidt @ 2009-11-30 15:17 UTC (permalink / raw)
To: rostedt; +Cc: linuxppc-dev, Frederic Weisbecker, mingo, Anton Blanchard
In-Reply-To: <1259183974.21397.73.camel@gandalf.stny.rr.com>
On Wed, 2009-11-25 at 16:19 -0500, Steven Rostedt wrote:
> On Wed, 2009-11-25 at 10:12 -0600, Will Schmidt wrote:
>
> > Tested-by: Will Schmidt <will_schmidt@vnet.ibm.com>
> > Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
>
> Isn't it assumed that the one that made the patch also tested it? Well I
> would hope that is the norm.
I like to make that assumption, but wanted to be clear on the point for
anyone with doubts. :-)
>
> -- Steve
>
>
^ permalink raw reply
* RE: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
From: Curtis Wald @ 2009-11-30 15:25 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20091130134145.GA2937@zod.rchland.ibm.com>
Josh,
Here is a resend of the Yosemite.dts patch, deleting tabs and spaces in
the IDSEL section that should look better when viewing as 80 column.=20
The comments added before the ranges declaration provides info on the
array element as processed by the kernel - there is no runtime
difference for this change, but adds some background. Since the ranges
declaration is beyond 80 columns the comments added are lined up with
the entries and when viewed as 80 column will wrap. If you have
suggestions on correcting this I will implement.=20
Thanks,
-Curtis
The stanza for PCI was copied from Bamboo which has four PCI
slots; Yosemite only has one PCI slot which is mapped to
IDSEL 12, ADDR 22, IRQ2 Vector 25, INTA.
Signed-off-by: Curtis Wald <cwald@watchguardvideo.com>
---
arch/powerpc/boot/dts/yosemite.dts | 17 +++++------------
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/yosemite.dts
b/arch/powerpc/boot/dts/yosemite.dts
index 1fa3cb4..8328be5 100644
--- a/arch/powerpc/boot/dts/yosemite.dts
+++ b/arch/powerpc/boot/dts/yosemite.dts
@@ -276,27 +276,19 @@
* later cannot be changed. Chip supports a second
* IO range but we don't use it for now
*/
+
+ /* u32 u64 u64
u64 */
+ /* pci_space pci_addr cpu_addr
size */
ranges =3D <0x02000000 0x00000000 0xa0000000 0x00000000 0xa0000000
0x00000000 0x20000000
0x01000000 0x00000000 0x00000000 0x00000000 0xe8000000
0x00000000 0x00010000>;
=20
/* Inbound 2GB range starting at 0 */
dma-ranges =3D <0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
=20
- /* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask =3D <0xf800 0x0 0x0 0x0>;
interrupt-map =3D <
- /* IDSEL 1 */
- 0x800 0x0 0x0 0x0 &UIC0 0x1c 0x8
-
- /* IDSEL 2 */
- 0x1000 0x0 0x0 0x0 &UIC0 0x1b 0x8
-
- /* IDSEL 3 */
- 0x1800 0x0 0x0 0x0 &UIC0 0x1a 0x8
-
- /* IDSEL 4 */
- 0x2000 0x0 0x0 0x0 &UIC0 0x19 0x8
+ /* IDSEL 12, ADDR 22, INTA, IRQ2 =3D Vector 25, 0x19 */
+ 0x6000 0x0 0x0 0x0 &UIC0 0x19 0x8
>;
};
};
--=20
1.5.5.6
> -----Original Message-----
> From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com]
> Sent: Monday, November 30, 2009 7:42 AM
> To: Curtis Wald
> Cc: mporter@kernel.crashing.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
>=20
> On Mon, Nov 16, 2009 at 11:36:40AM -0600, Curtis Wald wrote:
> >Yosemite.dts stanza for PCI was copied from Bamboo which has four PCI
> >slots; Yosemite only has one PCI slot which is mapped to
> >IDSEL 12, ADDR 22, IRQ2 Vector 25, INTA.
> >
> >Signed-off-by: Curtis Wald <cwald@watchguardvideo.com>
>=20
> Your patch looks correct (I think), but is very badly word wrapped and
> whitespace damaged. Could you resend?
>=20
> josh
^ permalink raw reply related
* Re: Ethernet issues with lite5200 board from linux-2.6.31
From: Grant Likely @ 2009-11-30 15:59 UTC (permalink / raw)
To: Yogesh Chaudhari
Cc: Robin Gareus, rt-users, Fernando Lopez-Lezcano, Peter Zijlstra,
Frank Rowand, Philippe Reynes, Mark Knecht, LKML, Steven Rostedt,
Sven-Thorsten Dietrich, linuxppc-dev, Clark Williams, Darren Hart,
Will Schmidt, Jon Masters, John Kacur, Ingo Molnar, Jan Blunck,
Gregory Haskins
In-Reply-To: <d1f76ba30911300150g10c1382clb2958245ebf94362@mail.gmail.com>
On Mon, Nov 30, 2009 at 2:50 AM, Yogesh Chaudhari <mr.yogesh@gmail.com> wro=
te:
> Hello,
> =A0 =A0 =A0 =A0 I am running linux kernel with rt patch on embedded board
> based on lite5200 eval board. From linux-2.6.31 release, in which the
> mdio patch has gone inside, =A0the fec ethernet does not come up on this
> board. I get the following message at startup:
> mpc52xx MII bus: probed
> mdio_bus f0003000: error probing PHY at address 1
>
>
> After the bootup if I try to do a ifconfig I get the message:
> net eth2: of_phy_connect failed
>
>
> If I change the value of reg in dts file (lite5200.dts) to 0 then this
> ethernet comes up. However upto this kernel version, this was not
> required.
>
> Ethernet does not come up on board with original lite5200.dts file
Is your board based on the Lite5200 or the Lite5200B? The phys are at
different addresses on those two revisions of the board. There is a
different .dts file for each board.
> phy0: ethernet-phy@1 {
> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D=
<1>;
> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> Ethernet comes up on board with this change
> phy0: ethernet-phy@1 {
> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D=
<0>;
> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
Some PHYs treat address 0 as the 'broadcast' address. You need to
fill in this field (and modify the ethernet-phy@<address> node name)
to reflect the address that your phy is actually at.
g.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix DEBUG_HIGHMEM build break from d4515646699
From: Josh Boyer @ 2009-11-30 17:57 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, mingo
In-Reply-To: <1259015333-23485-1-git-send-email-beckyb@kernel.crashing.org>
On Mon, Nov 23, 2009 at 04:28:53PM -0600, Becky Bruce wrote:
>Code was added to mm/higmem.c that depends on several
>kmap types that powerpc does not support. We add dummy
>invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE.
>
>According to list discussion, this fix should not be needed
>anymore starting with 2.6.33. The code is commented to this
>effect so hopefully we will remember to remove this.
>
>Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Ben, I see you have this queued up in you 'next' branch, but this seems to be
impacting 2.6.32 and according to the comments won't be needed in 2.6.33.
Right now, 2.6.32 doesn't build for a general Fedora ppc32 kernel because of
this bug. Should this be sent to Linus for .32?
( http://ppc.koji.fedoraproject.org/koji/getfile?taskID=31439&name=build.log
for the curious among you that want to look at the build log)
josh
^ permalink raw reply
* Re: [PATCH] ppc64: re-enable kexec to allow module loads with CONFIG_MODVERSIONS and CONFIG_RELOCATABLE turned on
From: Neil Horman @ 2009-11-30 18:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rusty, paulus, nhorman
In-Reply-To: <20091119195216.GC11414@hmsreliant.think-freely.org>
On Thu, Nov 19, 2009 at 02:52:16PM -0500, Neil Horman wrote:
> Hey there-
> Before anyone flames me for what a oddball solution this is, let me just
> say I'm trying to get the ball rolling here. I think there may be better
> solutions that can be impemented in reloc_64.S, but I've yet to make any of the
> ones I've tried work successfully. I'm open to suggestions, but this solution
> is the only one so far that I've been able to get to work. thanks :)
>
>
> Adjust crcs in __kcrctab_* sections if relocs are used with CONFIG_RELOCATABLE
>
> When CONFIG_MODVERSIONS and CONFIG_RELOCATABLE are enabled on powerpc platforms,
> kdump has been failing in a rather odd way. specifically modules will not
> install. This is because when validating the crcs of symbols that the module
> needs, the crc of the module never matches the crc that is stored in the kernel.
>
> The underlying cause of this is how CONFIG_MODVERSIONS is implemented, and how
> CONFIG_RELOCATABLE are implemented. with CONFIG_MODVERSIONS enabled, for every
> exported symbol in the kernel we emit 2 symbols, __crc_#sym which is declared
> extern and __kcrctab_##sym, which is placed in the __kcrctab section of the
> binary. The latter has its value set equal to the address of the former
> (recalling it is declared extern). After the object file is built, genksyms is
> run on the processed source, and crcs are computed for each exported symbol.
> genksyms then emits a linker script which defines each of the needed __crc_##sym
> symbols, and sets their addresses euqal to their respective crcs. This script
> is then used in a secondary link to the previously build object file, so that
> the crcs of the missing symbol can be validated on module insert.
>
> The problem here is that because __kcrctab_sym is set equal to &__crc_##sym, a
> relocation entry is emitted by the compiler for the __kcrctab__##sym. Normally
> this is not a problem, since relocation on other arches is done without the aid
> of .rel.dyn sections. PPC however uses these relocations when
> CONFIG_RELOCATABLE is enabled. nominally, since addressing starts at 0 for ppc,
> its irrelevant, but if we start at a non-zero address (like we do when booting
> via kexec from reserved crashkernel memory), the ppc boot code iterates over the
> relocation entries, and winds up adding that relocation offset to all symbols,
> including the symbols that are actually the aforementioned crc values in the
> __kcrctab_* sections. This effectively corrupts the crcs and prevents any
> module loads from happening during a kdump.
>
> My solution is to 'undo' these relocations prior to boot up. If
> ARCH_USES_RELOC_ENTRIES is defined, we add a symbol at address zero to the
> linker script for that arch (I call it reloc_start, so that &reloc_start = 0).
> This symbol will then indicate the relocation offset for any given boot. We
> also add an initcall to the module code that, during boot, scans the __kcrctab_*
> sections and subtracts &reloc_start from every entry in those sections,
> restoring the appropriate crc value.
>
> I've verified that this allows kexec to work properly on ppc64 systems myself.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
Paul, Ben, given that Rusty hasn't come back with any opinion on this patch, do you
feel comfortable merging it via the ppc tree? Currently the earlyinit routine
is only compiled in and used for your arch, so I think its fairly benign.
Regards
Neil
^ permalink raw reply
* RE: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma driver
From: Tirumala Reddy Marri @ 2009-11-30 18:17 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: wd, dzu, Yuri Tikhonov, linux-raid, linuxppc-dev, dan.j.williams
In-Reply-To: <20091127112641.5bcb9009@wker>
Sorry I meant drver/. Probably you should consider how the iop-dma is
done.=20
-----Original Message-----
From: Anatolij Gustschin [mailto:agust@denx.de]=20
Sent: Friday, November 27, 2009 2:27 AM
To: Tirumala Reddy Marri
Cc: linux-raid@vger.kernel.org; wd@denx.de; dzu@denx.de; Yuri Tikhonov;
linuxppc-dev@ozlabs.org; dan.j.williams@intel.com
Subject: Re: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma
driver
"Tirumala Reddy Marri" <tmarri@amcc.com> wrote:
> Why are we having separate directory for 440spe. Can this be
generalized
> arch/dma/ppc4xx/ppc4xx_dma.c ?
currently there is only tested support for 440spe. If the driver
will be extended to support other CPUs, then the renaming can be
done while adding support for other CPUs. 'arch/' is not correct,
it should be 'driver/'.
Best regards,
Anatolij
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* RE: [PATCH] Adding PCI-E support for 460SX based redwood board.
From: Tirumala Reddy Marri @ 2009-11-30 18:52 UTC (permalink / raw)
To: Tirumala Reddy Marri, linuxppc-dev, benh; +Cc: tmarri
In-Reply-To: <1259192937-8591-1-git-send-email-tmarri@amcc.com>
Hi Ben,
Could you please review the patch I sent .
Thanks,
Marri
-----Original Message-----
From: tmarri@amcc.com [mailto:tmarri@amcc.com]=20
Sent: Wednesday, November 25, 2009 3:49 PM
To: linuxppc-dev@ozlabs.org
Cc: tmarri@macc.com; Tirumala Reddy Marri
Subject: [PATCH] Adding PCI-E support for 460SX based redwood board.
From: Tirumala Marri <tmarri@amcc.com>
This patch would add PCI-E support for AMCC 460SX processor based=20
redwood board.
Signed-off-by: Tirumala Marri <tmarri@amcc.com>
---
arch/powerpc/boot/dts/redwood.dts | 122
+++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/ppc4xx_pci.c | 119
++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/ppc4xx_pci.h | 58 +++++++++++++++++
3 files changed, 299 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
index ad402c4..9eeec28 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -233,6 +233,128 @@
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
+ PCIE0: pciex@d00000000 {
+ device_type =3D "pci";
+ #interrupt-cells =3D <1>;
+ #size-cells =3D <2>;
+ #address-cells =3D <3>;
+ compatible =3D "ibm,plb-pciex-460sx",
"ibm,plb-pciex";
+ primary;
+ port =3D <0x0>; /* port number */
+ reg =3D <0x0000000d 0x00000000 0x20000000
/* Config space access */
+ 0x0000000c 0x10000000
0x00001000>; /* Registers */
+ dcr-reg =3D <0x100 0x020>;
+ sdr-base =3D <0x300>;
+
+ /* Outbound ranges, one memory and one
IO,
+ * later cannot be changed
+ */
+ ranges =3D <0x02000000 0x00000000
0x80000000 0x0000000e 0x00000000 0x00000000 0x80000000
+ 0x01000000 0x00000000
0x00000000 0x0000000f 0x80000000 0x00000000 0x00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges =3D <0x42000000 0x0 0x0 0x0 0x0
0x0 0x80000000>;
+
+ /* This drives busses 10 to 0x1f */
+ bus-range =3D <0x10 0x1f>;
+
+ /* Legacy interrupts (note the weird
polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the
numbers are actually for
+ * port of the root complex virtual P2P
bridge. But I want
+ * to avoid putting a node for it in the
tree, so the numbers
+ * below are basically de-swizzled
numbers.
+ * The real slot is on idsel 0, so the
swizzling is 1:1
+ */
+ interrupt-map-mask =3D <0x0 0x0 0x0 0x7>;
+ interrupt-map =3D <
+ 0x0 0x0 0x0 0x1 &UIC3 0x0 0x4 /*
swizzled int A */
+ 0x0 0x0 0x0 0x2 &UIC3 0x1 0x4 /*
swizzled int B */
+ 0x0 0x0 0x0 0x3 &UIC3 0x2 0x4 /*
swizzled int C */
+ 0x0 0x0 0x0 0x4 &UIC3 0x3 0x4 /*
swizzled int D */>;
+ };
+
+ PCIE1: pciex@d20000000 {
+ device_type =3D "pci";
+ #interrupt-cells =3D <1>;
+ #size-cells =3D <2>;
+ #address-cells =3D <3>;
+ compatible =3D "ibm,plb-pciex-460sx",
"ibm,plb-pciex";
+ primary;
+ port =3D <0x1>; /* port number */
+ reg =3D <0x0000000d 0x20000000 0x20000000
/* Config space access */
+ 0x0000000c 0x10001000
0x00001000>; /* Registers */
+ dcr-reg =3D <0x120 0x020>;
+ sdr-base =3D <0x340>;
+
+ /* Outbound ranges, one memory and one
IO,
+ * later cannot be changed
+ */
+ ranges =3D <0x02000000 0x00000000
0x80000000 0x0000000e 0x80000000 0x00000000 0x80000000
+ 0x01000000 0x00000000
0x00000000 0x0000000f 0x80010000 0x00000000 0x00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges =3D <0x42000000 0x0 0x0 0x0 0x0
0x0 0x80000000>;
+
+ /* This drives busses 10 to 0x1f */
+ bus-range =3D <0x20 0x2f>;
+
+ /* Legacy interrupts (note the weird
polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the
numbers are actually for
+ * port of the root complex virtual P2P
bridge. But I want
+ * to avoid putting a node for it in the
tree, so the numbers
+ * below are basically de-swizzled
numbers.
+ * The real slot is on idsel 0, so the
swizzling is 1:1
+ */
+ interrupt-map-mask =3D <0x0 0x0 0x0 0x7>;
+ interrupt-map =3D <
+ 0x0 0x0 0x0 0x1 &UIC3 0x4 0x4 /*
swizzled int A */
+ 0x0 0x0 0x0 0x2 &UIC3 0x5 0x4 /*
swizzled int B */
+ 0x0 0x0 0x0 0x3 &UIC3 0x6 0x4 /*
swizzled int C */
+ 0x0 0x0 0x0 0x4 &UIC3 0x7 0x4 /*
swizzled int D */>;
+ };
+
+ PCIE2: pciex@d40000000 {
+ device_type =3D "pci";
+ #interrupt-cells =3D <1>;
+ #size-cells =3D <2>;
+ #address-cells =3D <3>;
+ compatible =3D "ibm,plb-pciex-460sx",
"ibm,plb-pciex";
+ primary;
+ port =3D <0x2>; /* port number */
+ reg =3D <0x0000000d 0x40000000 0x20000000
/* Config space access */
+ 0x0000000c 0x10002000
0x00001000>; /* Registers */
+ dcr-reg =3D <0x140 0x020>;
+ sdr-base =3D <0x370>;
+
+ /* Outbound ranges, one memory and one
IO,
+ * later cannot be changed
+ */
+ ranges =3D <0x02000000 0x00000000
0x80000000 0x0000000f 0x00000000 0x00000000 0x80000000
+ 0x01000000 0x00000000
0x00000000 0x0000000f 0x80020000 0x00000000 0x00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges =3D <0x42000000 0x0 0x0 0x0 0x0
0x0 0x80000000>;
+
+ /* This drives busses 10 to 0x1f */
+ bus-range =3D <0x30 0x3f>;
+
+ /* Legacy interrupts (note the weird
polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the
numbers are actually for
+ * port of the root complex virtual P2P
bridge. But I want
+ * to avoid putting a node for it in the
tree, so the numbers
+ * below are basically de-swizzled
numbers.
+ * The real slot is on idsel 0, so the
swizzling is 1:1
+ */
+ interrupt-map-mask =3D <0x0 0x0 0x0 0x7>;
+ interrupt-map =3D <
+ 0x0 0x0 0x0 0x1 &UIC3 0x8 0x4 /*
swizzled int A */
+ 0x0 0x0 0x0 0x2 &UIC3 0x9 0x4 /*
swizzled int B */
+ 0x0 0x0 0x0 0x3 &UIC3 0xa 0x4 /*
swizzled int C */
+ 0x0 0x0 0x0 0x4 &UIC3 0xb 0x4 /*
swizzled int D */>;
+ };
=20
};
=20
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c
b/arch/powerpc/sysdev/ppc4xx_pci.c
index 6ff9d71..64cd020 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -972,6 +972,123 @@ static struct ppc4xx_pciex_hwops
ppc460ex_pcie_hwops __initdata =3D
.setup_utl =3D ppc460ex_pciex_init_utl,
};
=20
+static int __init ppc460sx_pciex_core_init(struct device_node *np)
+{
+ /* HSS drive amplitude */
+ mtdcri(SDR0, PESDR0_460SX_HSSL0DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL1DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL2DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL3DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL4DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL5DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL6DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL7DAMP, 0xB9843211);
+
+ mtdcri(SDR0, PESDR1_460SX_HSSL0DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR1_460SX_HSSL1DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR1_460SX_HSSL2DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR1_460SX_HSSL3DAMP, 0xB9843211);
+
+ mtdcri(SDR0, PESDR2_460SX_HSSL0DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR2_460SX_HSSL1DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR2_460SX_HSSL2DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR2_460SX_HSSL3DAMP, 0xB9843211);
+
+ /* HSS TX pre-emphasis */
+ mtdcri(SDR0, PESDR0_460SX_HSSL0COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL1COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL2COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL3COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL4COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL5COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL6COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL7COEFA, 0xDCB98987);
+
+ mtdcri(SDR0, PESDR1_460SX_HSSL0COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR1_460SX_HSSL1COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR1_460SX_HSSL2COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR1_460SX_HSSL3COEFA, 0xDCB98987);
+
+ mtdcri(SDR0, PESDR2_460SX_HSSL0COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR2_460SX_HSSL1COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR2_460SX_HSSL2COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR2_460SX_HSSL3COEFA, 0xDCB98987);
+
+ /* HSS TX calibration control */
+ mtdcri(SDR0, PESDR0_460SX_HSSL1CALDRV, 0x22222222);
+ mtdcri(SDR0, PESDR1_460SX_HSSL1CALDRV, 0x22220000);
+ mtdcri(SDR0, PESDR2_460SX_HSSL1CALDRV, 0x22220000);
+
+ /* HSS TX slew control */
+ mtdcri(SDR0, PESDR0_460SX_HSSSLEW, 0xFFFFFFFF);
+ mtdcri(SDR0, PESDR1_460SX_HSSSLEW, 0xFFFF0000);
+ mtdcri(SDR0, PESDR2_460SX_HSSSLEW, 0xFFFF0000);
+
+ udelay(100);
+
+ /* De-assert PLLRESET */
+ dcri_clrset(SDR0, PESDR0_PLLLCT2, 0x00000100, 0);
+
+ /* Reset DL, UTL, GPL before configuration */
+ mtdcri(SDR0, PESDR0_460SX_RCSSET,
+ PESDRx_RCSSET_RSTDL | PESDRx_RCSSET_RSTGU);
+ mtdcri(SDR0, PESDR1_460SX_RCSSET,
+ PESDRx_RCSSET_RSTDL | PESDRx_RCSSET_RSTGU);
+ mtdcri(SDR0, PESDR2_460SX_RCSSET,
+ PESDRx_RCSSET_RSTDL | PESDRx_RCSSET_RSTGU);
+
+ udelay(100);
+
+ /*
+ * If bifurcation is not enabled, u-boot would have disabled the
+ * third PCIe port
+ */
+ if (((mfdcri(SDR0, PESDR1_460SX_HSSCTLSET) & 0x00000001) =3D=3D
+ 0x00000001)) {
+ printk(KERN_INFO "PCI: PCIE bifurcation setup
successfully.\n");
+ printk(KERN_INFO "PCI: Total 3 PCIE ports are
present\n");
+ return 3;
+ }
+
+ printk(KERN_INFO "PCI: Total 2 PCIE ports are present\n");
+ return 2;
+}
+
+static int ppc460sx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+{
+
+ if (port->endpoint)
+ dcri_clrset(SDR0, port->sdr_base + PESDRn_UTLSET2,
+ 0x01000000, 0);
+ else
+ dcri_clrset(SDR0, port->sdr_base + PESDRn_UTLSET2,
+ 0, 0x01000000);
+
+ /*Gen-1*/
+ mtdcri(SDR0, port->sdr_base + PESDRn_460SX_RCEI, 0x08000000);
+
+ dcri_clrset(SDR0, port->sdr_base + PESDRn_RCSSET,
+ (PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTDL),
+ PESDRx_RCSSET_RSTPYN);
+
+ port->has_ibpre =3D 1;
+
+ return 0;
+}
+
+static int ppc460sx_pciex_init_utl(struct ppc4xx_pciex_port *port)
+{
+ /* Max 128 Bytes */
+ out_be32 (port->utl_base + PEUTL_PBBSZ, 0x00000000);
+ return 0;
+}
+
+static struct ppc4xx_pciex_hwops ppc460sx_pcie_hwops __initdata =3D {
+ .core_init =3D ppc460sx_pciex_core_init,
+ .port_init_hw =3D ppc460sx_pciex_init_port_hw,
+ .setup_utl =3D ppc460sx_pciex_init_utl,
+};
+
#endif /* CONFIG_44x */
=20
#ifdef CONFIG_40x
@@ -1087,6 +1204,8 @@ static int __init
ppc4xx_pciex_check_core_init(struct device_node *np)
}
if (of_device_is_compatible(np, "ibm,plb-pciex-460ex"))
ppc4xx_pciex_hwops =3D &ppc460ex_pcie_hwops;
+ if (of_device_is_compatible(np, "ibm,plb-pciex-460sx"))
+ ppc4xx_pciex_hwops =3D &ppc460sx_pcie_hwops;
#endif /* CONFIG_44x */
#ifdef CONFIG_40x
if (of_device_is_compatible(np, "ibm,plb-pciex-405ex"))
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.h
b/arch/powerpc/sysdev/ppc4xx_pci.h
index d04e40b..56d9e5d 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.h
+++ b/arch/powerpc/sysdev/ppc4xx_pci.h
@@ -324,6 +324,64 @@
#define PESDR0_460EX_IHS2 0x036D
=20
/*
+ * 460SX addtional DCRs
+ */
+#define PESDRn_460SX_RCEI 0x02
+
+#define PESDR0_460SX_HSSL0DAMP 0x320
+#define PESDR0_460SX_HSSL1DAMP 0x321
+#define PESDR0_460SX_HSSL2DAMP 0x322
+#define PESDR0_460SX_HSSL3DAMP 0x323
+#define PESDR0_460SX_HSSL4DAMP 0x324
+#define PESDR0_460SX_HSSL5DAMP 0x325
+#define PESDR0_460SX_HSSL6DAMP 0x326
+#define PESDR0_460SX_HSSL7DAMP 0x327
+
+#define PESDR1_460SX_HSSL0DAMP 0x354
+#define PESDR1_460SX_HSSL1DAMP 0x355
+#define PESDR1_460SX_HSSL2DAMP 0x356
+#define PESDR1_460SX_HSSL3DAMP 0x357
+
+#define PESDR2_460SX_HSSL0DAMP 0x384
+#define PESDR2_460SX_HSSL1DAMP 0x385
+#define PESDR2_460SX_HSSL2DAMP 0x386
+#define PESDR2_460SX_HSSL3DAMP 0x387
+
+#define PESDR0_460SX_HSSL0COEFA 0x328
+#define PESDR0_460SX_HSSL1COEFA 0x329
+#define PESDR0_460SX_HSSL2COEFA 0x32A
+#define PESDR0_460SX_HSSL3COEFA 0x32B
+#define PESDR0_460SX_HSSL4COEFA 0x32C
+#define PESDR0_460SX_HSSL5COEFA 0x32D
+#define PESDR0_460SX_HSSL6COEFA 0x32E
+#define PESDR0_460SX_HSSL7COEFA 0x32F
+
+#define PESDR1_460SX_HSSL0COEFA 0x358
+#define PESDR1_460SX_HSSL1COEFA 0x359
+#define PESDR1_460SX_HSSL2COEFA 0x35A
+#define PESDR1_460SX_HSSL3COEFA 0x35B
+
+#define PESDR2_460SX_HSSL0COEFA 0x388
+#define PESDR2_460SX_HSSL1COEFA 0x389
+#define PESDR2_460SX_HSSL2COEFA 0x38A
+#define PESDR2_460SX_HSSL3COEFA 0x38B
+
+#define PESDR0_460SX_HSSL1CALDRV 0x339
+#define PESDR1_460SX_HSSL1CALDRV 0x361
+#define PESDR2_460SX_HSSL1CALDRV 0x391
+
+#define PESDR0_460SX_HSSSLEW 0x338
+#define PESDR1_460SX_HSSSLEW 0x360
+#define PESDR2_460SX_HSSSLEW 0x390
+
+#define PESDR0_460SX_HSSCTLSET 0x31E
+#define PESDR1_460SX_HSSCTLSET 0x352
+#define PESDR2_460SX_HSSCTLSET 0x382
+
+#define PESDR0_460SX_RCSSET 0x304
+#define PESDR1_460SX_RCSSET 0x344
+#define PESDR2_460SX_RCSSET 0x374
+/*
* Of the above, some are common offsets from the base
*/
#define PESDRn_UTLSET1 0x00
--=20
1.6.3.3
^ permalink raw reply related
* RE: [PATCH] Adding PCI-E support for 460SX based redwood board.
From: Benjamin Herrenschmidt @ 2009-11-30 19:38 UTC (permalink / raw)
To: Tirumala Reddy Marri; +Cc: linuxppc-dev, tmarri
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C08642D5B@SDCEXCHANGE01.ad.amcc.com>
On Mon, 2009-11-30 at 10:52 -0800, Tirumala Reddy Marri wrote:
> Hi Ben,
> Could you please review the patch I sent .
> Thanks,
> Marri
Hi !
The original message never made it. This one did but the patch is line
wrapped. Please fix your mailer and re-send.
Cheers,
Ben.
> -----Original Message-----
> From: tmarri@amcc.com [mailto:tmarri@amcc.com]
> Sent: Wednesday, November 25, 2009 3:49 PM
> To: linuxppc-dev@ozlabs.org
> Cc: tmarri@macc.com; Tirumala Reddy Marri
> Subject: [PATCH] Adding PCI-E support for 460SX based redwood board.
>
> From: Tirumala Marri <tmarri@amcc.com>
>
> This patch would add PCI-E support for AMCC 460SX processor based
> redwood board.
>
> Signed-off-by: Tirumala Marri <tmarri@amcc.com>
>
> ---
> arch/powerpc/boot/dts/redwood.dts | 122
> +++++++++++++++++++++++++++++++++++++
> arch/powerpc/sysdev/ppc4xx_pci.c | 119
> ++++++++++++++++++++++++++++++++++++
> arch/powerpc/sysdev/ppc4xx_pci.h | 58 +++++++++++++++++
> 3 files changed, 299 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/redwood.dts
> b/arch/powerpc/boot/dts/redwood.dts
> index ad402c4..9eeec28 100644
> --- a/arch/powerpc/boot/dts/redwood.dts
> +++ b/arch/powerpc/boot/dts/redwood.dts
> @@ -233,6 +233,128 @@
> has-inverted-stacr-oc;
> has-new-stacr-staopc;
> };
> + PCIE0: pciex@d00000000 {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb-pciex-460sx",
> "ibm,plb-pciex";
> + primary;
> + port = <0x0>; /* port number */
> + reg = <0x0000000d 0x00000000 0x20000000
> /* Config space access */
> + 0x0000000c 0x10000000
> 0x00001000>; /* Registers */
> + dcr-reg = <0x100 0x020>;
> + sdr-base = <0x300>;
> +
> + /* Outbound ranges, one memory and one
> IO,
> + * later cannot be changed
> + */
> + ranges = <0x02000000 0x00000000
> 0x80000000 0x0000000e 0x00000000 0x00000000 0x80000000
> + 0x01000000 0x00000000
> 0x00000000 0x0000000f 0x80000000 0x00000000 0x00010000>;
> +
> + /* Inbound 2GB range starting at 0 */
> + dma-ranges = <0x42000000 0x0 0x0 0x0 0x0
> 0x0 0x80000000>;
> +
> + /* This drives busses 10 to 0x1f */
> + bus-range = <0x10 0x1f>;
> +
> + /* Legacy interrupts (note the weird
> polarity, the bridge seems
> + * to invert PCIe legacy interrupts).
> + * We are de-swizzling here because the
> numbers are actually for
> + * port of the root complex virtual P2P
> bridge. But I want
> + * to avoid putting a node for it in the
> tree, so the numbers
> + * below are basically de-swizzled
> numbers.
> + * The real slot is on idsel 0, so the
> swizzling is 1:1
> + */
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <
> + 0x0 0x0 0x0 0x1 &UIC3 0x0 0x4 /*
> swizzled int A */
> + 0x0 0x0 0x0 0x2 &UIC3 0x1 0x4 /*
> swizzled int B */
> + 0x0 0x0 0x0 0x3 &UIC3 0x2 0x4 /*
> swizzled int C */
> + 0x0 0x0 0x0 0x4 &UIC3 0x3 0x4 /*
> swizzled int D */>;
> + };
> +
> + PCIE1: pciex@d20000000 {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb-pciex-460sx",
> "ibm,plb-pciex";
> + primary;
> + port = <0x1>; /* port number */
> + reg = <0x0000000d 0x20000000 0x20000000
> /* Config space access */
> + 0x0000000c 0x10001000
> 0x00001000>; /* Registers */
> + dcr-reg = <0x120 0x020>;
> + sdr-base = <0x340>;
> +
> + /* Outbound ranges, one memory and one
> IO,
> + * later cannot be changed
> + */
> + ranges = <0x02000000 0x00000000
> 0x80000000 0x0000000e 0x80000000 0x00000000 0x80000000
> + 0x01000000 0x00000000
> 0x00000000 0x0000000f 0x80010000 0x00000000 0x00010000>;
> +
> + /* Inbound 2GB range starting at 0 */
> + dma-ranges = <0x42000000 0x0 0x0 0x0 0x0
> 0x0 0x80000000>;
> +
> + /* This drives busses 10 to 0x1f */
> + bus-range = <0x20 0x2f>;
> +
> + /* Legacy interrupts (note the weird
> polarity, the bridge seems
> + * to invert PCIe legacy interrupts).
> + * We are de-swizzling here because the
> numbers are actually for
> + * port of the root complex virtual P2P
> bridge. But I want
> + * to avoid putting a node for it in the
> tree, so the numbers
> + * below are basically de-swizzled
> numbers.
> + * The real slot is on idsel 0, so the
> swizzling is 1:1
> + */
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <
> + 0x0 0x0 0x0 0x1 &UIC3 0x4 0x4 /*
> swizzled int A */
> + 0x0 0x0 0x0 0x2 &UIC3 0x5 0x4 /*
> swizzled int B */
> + 0x0 0x0 0x0 0x3 &UIC3 0x6 0x4 /*
> swizzled int C */
> + 0x0 0x0 0x0 0x4 &UIC3 0x7 0x4 /*
> swizzled int D */>;
> + };
> +
> + PCIE2: pciex@d40000000 {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb-pciex-460sx",
> "ibm,plb-pciex";
> + primary;
> + port = <0x2>; /* port number */
> + reg = <0x0000000d 0x40000000 0x20000000
> /* Config space access */
> + 0x0000000c 0x10002000
> 0x00001000>; /* Registers */
> + dcr-reg = <0x140 0x020>;
> + sdr-base = <0x370>;
> +
> + /* Outbound ranges, one memory and one
> IO,
> + * later cannot be changed
> + */
> + ranges = <0x02000000 0x00000000
> 0x80000000 0x0000000f 0x00000000 0x00000000 0x80000000
> + 0x01000000 0x00000000
> 0x00000000 0x0000000f 0x80020000 0x00000000 0x00010000>;
> +
> + /* Inbound 2GB range starting at 0 */
> + dma-ranges = <0x42000000 0x0 0x0 0x0 0x0
> 0x0 0x80000000>;
> +
> + /* This drives busses 10 to 0x1f */
> + bus-range = <0x30 0x3f>;
> +
> + /* Legacy interrupts (note the weird
> polarity, the bridge seems
> + * to invert PCIe legacy interrupts).
> + * We are de-swizzling here because the
> numbers are actually for
> + * port of the root complex virtual P2P
> bridge. But I want
> + * to avoid putting a node for it in the
> tree, so the numbers
> + * below are basically de-swizzled
> numbers.
> + * The real slot is on idsel 0, so the
> swizzling is 1:1
> + */
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <
> + 0x0 0x0 0x0 0x1 &UIC3 0x8 0x4 /*
> swizzled int A */
> + 0x0 0x0 0x0 0x2 &UIC3 0x9 0x4 /*
> swizzled int B */
> + 0x0 0x0 0x0 0x3 &UIC3 0xa 0x4 /*
> swizzled int C */
> + 0x0 0x0 0x0 0x4 &UIC3 0xb 0x4 /*
> swizzled int D */>;
> + };
>
> };
>
> diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c
> b/arch/powerpc/sysdev/ppc4xx_pci.c
> index 6ff9d71..64cd020 100644
> --- a/arch/powerpc/sysdev/ppc4xx_pci.c
> +++ b/arch/powerpc/sysdev/ppc4xx_pci.c
> @@ -972,6 +972,123 @@ static struct ppc4xx_pciex_hwops
> ppc460ex_pcie_hwops __initdata =
> .setup_utl = ppc460ex_pciex_init_utl,
> };
>
> +static int __init ppc460sx_pciex_core_init(struct device_node *np)
> +{
> + /* HSS drive amplitude */
> + mtdcri(SDR0, PESDR0_460SX_HSSL0DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR0_460SX_HSSL1DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR0_460SX_HSSL2DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR0_460SX_HSSL3DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR0_460SX_HSSL4DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR0_460SX_HSSL5DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR0_460SX_HSSL6DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR0_460SX_HSSL7DAMP, 0xB9843211);
> +
> + mtdcri(SDR0, PESDR1_460SX_HSSL0DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR1_460SX_HSSL1DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR1_460SX_HSSL2DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR1_460SX_HSSL3DAMP, 0xB9843211);
> +
> + mtdcri(SDR0, PESDR2_460SX_HSSL0DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR2_460SX_HSSL1DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR2_460SX_HSSL2DAMP, 0xB9843211);
> + mtdcri(SDR0, PESDR2_460SX_HSSL3DAMP, 0xB9843211);
> +
> + /* HSS TX pre-emphasis */
> + mtdcri(SDR0, PESDR0_460SX_HSSL0COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR0_460SX_HSSL1COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR0_460SX_HSSL2COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR0_460SX_HSSL3COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR0_460SX_HSSL4COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR0_460SX_HSSL5COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR0_460SX_HSSL6COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR0_460SX_HSSL7COEFA, 0xDCB98987);
> +
> + mtdcri(SDR0, PESDR1_460SX_HSSL0COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR1_460SX_HSSL1COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR1_460SX_HSSL2COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR1_460SX_HSSL3COEFA, 0xDCB98987);
> +
> + mtdcri(SDR0, PESDR2_460SX_HSSL0COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR2_460SX_HSSL1COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR2_460SX_HSSL2COEFA, 0xDCB98987);
> + mtdcri(SDR0, PESDR2_460SX_HSSL3COEFA, 0xDCB98987);
> +
> + /* HSS TX calibration control */
> + mtdcri(SDR0, PESDR0_460SX_HSSL1CALDRV, 0x22222222);
> + mtdcri(SDR0, PESDR1_460SX_HSSL1CALDRV, 0x22220000);
> + mtdcri(SDR0, PESDR2_460SX_HSSL1CALDRV, 0x22220000);
> +
> + /* HSS TX slew control */
> + mtdcri(SDR0, PESDR0_460SX_HSSSLEW, 0xFFFFFFFF);
> + mtdcri(SDR0, PESDR1_460SX_HSSSLEW, 0xFFFF0000);
> + mtdcri(SDR0, PESDR2_460SX_HSSSLEW, 0xFFFF0000);
> +
> + udelay(100);
> +
> + /* De-assert PLLRESET */
> + dcri_clrset(SDR0, PESDR0_PLLLCT2, 0x00000100, 0);
> +
> + /* Reset DL, UTL, GPL before configuration */
> + mtdcri(SDR0, PESDR0_460SX_RCSSET,
> + PESDRx_RCSSET_RSTDL | PESDRx_RCSSET_RSTGU);
> + mtdcri(SDR0, PESDR1_460SX_RCSSET,
> + PESDRx_RCSSET_RSTDL | PESDRx_RCSSET_RSTGU);
> + mtdcri(SDR0, PESDR2_460SX_RCSSET,
> + PESDRx_RCSSET_RSTDL | PESDRx_RCSSET_RSTGU);
> +
> + udelay(100);
> +
> + /*
> + * If bifurcation is not enabled, u-boot would have disabled the
> + * third PCIe port
> + */
> + if (((mfdcri(SDR0, PESDR1_460SX_HSSCTLSET) & 0x00000001) ==
> + 0x00000001)) {
> + printk(KERN_INFO "PCI: PCIE bifurcation setup
> successfully.\n");
> + printk(KERN_INFO "PCI: Total 3 PCIE ports are
> present\n");
> + return 3;
> + }
> +
> + printk(KERN_INFO "PCI: Total 2 PCIE ports are present\n");
> + return 2;
> +}
> +
> +static int ppc460sx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
> +{
> +
> + if (port->endpoint)
> + dcri_clrset(SDR0, port->sdr_base + PESDRn_UTLSET2,
> + 0x01000000, 0);
> + else
> + dcri_clrset(SDR0, port->sdr_base + PESDRn_UTLSET2,
> + 0, 0x01000000);
> +
> + /*Gen-1*/
> + mtdcri(SDR0, port->sdr_base + PESDRn_460SX_RCEI, 0x08000000);
> +
> + dcri_clrset(SDR0, port->sdr_base + PESDRn_RCSSET,
> + (PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTDL),
> + PESDRx_RCSSET_RSTPYN);
> +
> + port->has_ibpre = 1;
> +
> + return 0;
> +}
> +
> +static int ppc460sx_pciex_init_utl(struct ppc4xx_pciex_port *port)
> +{
> + /* Max 128 Bytes */
> + out_be32 (port->utl_base + PEUTL_PBBSZ, 0x00000000);
> + return 0;
> +}
> +
> +static struct ppc4xx_pciex_hwops ppc460sx_pcie_hwops __initdata = {
> + .core_init = ppc460sx_pciex_core_init,
> + .port_init_hw = ppc460sx_pciex_init_port_hw,
> + .setup_utl = ppc460sx_pciex_init_utl,
> +};
> +
> #endif /* CONFIG_44x */
>
> #ifdef CONFIG_40x
> @@ -1087,6 +1204,8 @@ static int __init
> ppc4xx_pciex_check_core_init(struct device_node *np)
> }
> if (of_device_is_compatible(np, "ibm,plb-pciex-460ex"))
> ppc4xx_pciex_hwops = &ppc460ex_pcie_hwops;
> + if (of_device_is_compatible(np, "ibm,plb-pciex-460sx"))
> + ppc4xx_pciex_hwops = &ppc460sx_pcie_hwops;
> #endif /* CONFIG_44x */
> #ifdef CONFIG_40x
> if (of_device_is_compatible(np, "ibm,plb-pciex-405ex"))
> diff --git a/arch/powerpc/sysdev/ppc4xx_pci.h
> b/arch/powerpc/sysdev/ppc4xx_pci.h
> index d04e40b..56d9e5d 100644
> --- a/arch/powerpc/sysdev/ppc4xx_pci.h
> +++ b/arch/powerpc/sysdev/ppc4xx_pci.h
> @@ -324,6 +324,64 @@
> #define PESDR0_460EX_IHS2 0x036D
>
> /*
> + * 460SX addtional DCRs
> + */
> +#define PESDRn_460SX_RCEI 0x02
> +
> +#define PESDR0_460SX_HSSL0DAMP 0x320
> +#define PESDR0_460SX_HSSL1DAMP 0x321
> +#define PESDR0_460SX_HSSL2DAMP 0x322
> +#define PESDR0_460SX_HSSL3DAMP 0x323
> +#define PESDR0_460SX_HSSL4DAMP 0x324
> +#define PESDR0_460SX_HSSL5DAMP 0x325
> +#define PESDR0_460SX_HSSL6DAMP 0x326
> +#define PESDR0_460SX_HSSL7DAMP 0x327
> +
> +#define PESDR1_460SX_HSSL0DAMP 0x354
> +#define PESDR1_460SX_HSSL1DAMP 0x355
> +#define PESDR1_460SX_HSSL2DAMP 0x356
> +#define PESDR1_460SX_HSSL3DAMP 0x357
> +
> +#define PESDR2_460SX_HSSL0DAMP 0x384
> +#define PESDR2_460SX_HSSL1DAMP 0x385
> +#define PESDR2_460SX_HSSL2DAMP 0x386
> +#define PESDR2_460SX_HSSL3DAMP 0x387
> +
> +#define PESDR0_460SX_HSSL0COEFA 0x328
> +#define PESDR0_460SX_HSSL1COEFA 0x329
> +#define PESDR0_460SX_HSSL2COEFA 0x32A
> +#define PESDR0_460SX_HSSL3COEFA 0x32B
> +#define PESDR0_460SX_HSSL4COEFA 0x32C
> +#define PESDR0_460SX_HSSL5COEFA 0x32D
> +#define PESDR0_460SX_HSSL6COEFA 0x32E
> +#define PESDR0_460SX_HSSL7COEFA 0x32F
> +
> +#define PESDR1_460SX_HSSL0COEFA 0x358
> +#define PESDR1_460SX_HSSL1COEFA 0x359
> +#define PESDR1_460SX_HSSL2COEFA 0x35A
> +#define PESDR1_460SX_HSSL3COEFA 0x35B
> +
> +#define PESDR2_460SX_HSSL0COEFA 0x388
> +#define PESDR2_460SX_HSSL1COEFA 0x389
> +#define PESDR2_460SX_HSSL2COEFA 0x38A
> +#define PESDR2_460SX_HSSL3COEFA 0x38B
> +
> +#define PESDR0_460SX_HSSL1CALDRV 0x339
> +#define PESDR1_460SX_HSSL1CALDRV 0x361
> +#define PESDR2_460SX_HSSL1CALDRV 0x391
> +
> +#define PESDR0_460SX_HSSSLEW 0x338
> +#define PESDR1_460SX_HSSSLEW 0x360
> +#define PESDR2_460SX_HSSSLEW 0x390
> +
> +#define PESDR0_460SX_HSSCTLSET 0x31E
> +#define PESDR1_460SX_HSSCTLSET 0x352
> +#define PESDR2_460SX_HSSCTLSET 0x382
> +
> +#define PESDR0_460SX_RCSSET 0x304
> +#define PESDR1_460SX_RCSSET 0x344
> +#define PESDR2_460SX_RCSSET 0x374
> +/*
> * Of the above, some are common offsets from the base
> */
> #define PESDRn_UTLSET1 0x00
^ permalink raw reply
* Re: [PATCH] powerpc: Fix DEBUG_HIGHMEM build break from d4515646699
From: Benjamin Herrenschmidt @ 2009-11-30 19:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, mingo
In-Reply-To: <20091130175750.GD2937@zod.rchland.ibm.com>
On Mon, 2009-11-30 at 12:57 -0500, Josh Boyer wrote:
> On Mon, Nov 23, 2009 at 04:28:53PM -0600, Becky Bruce wrote:
> >Code was added to mm/higmem.c that depends on several
> >kmap types that powerpc does not support. We add dummy
> >invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE.
> >
> >According to list discussion, this fix should not be needed
> >anymore starting with 2.6.33. The code is commented to this
> >effect so hopefully we will remember to remove this.
> >
> >Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
>
> Ben, I see you have this queued up in you 'next' branch, but this seems to be
> impacting 2.6.32 and according to the comments won't be needed in 2.6.33.
> Right now, 2.6.32 doesn't build for a general Fedora ppc32 kernel because of
> this bug. Should this be sent to Linus for .32?
Why would fedora have DEBUG_HIGHMEM enabled ? I'll see what I can do.
> ( http://ppc.koji.fedoraproject.org/koji/getfile?taskID=31439&name=build.log
> for the curious among you that want to look at the build log)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix DEBUG_HIGHMEM build break from d4515646699
From: Josh Boyer @ 2009-11-30 19:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, mingo
In-Reply-To: <1259610583.2076.97.camel@pasglop>
On Tue, Dec 01, 2009 at 06:49:43AM +1100, Benjamin Herrenschmidt wrote:
>On Mon, 2009-11-30 at 12:57 -0500, Josh Boyer wrote:
>> On Mon, Nov 23, 2009 at 04:28:53PM -0600, Becky Bruce wrote:
>> >Code was added to mm/higmem.c that depends on several
>> >kmap types that powerpc does not support. We add dummy
>> >invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE.
>> >
>> >According to list discussion, this fix should not be needed
>> >anymore starting with 2.6.33. The code is commented to this
>> >effect so hopefully we will remember to remove this.
>> >
>> >Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
>>
>> Ben, I see you have this queued up in you 'next' branch, but this seems to be
>> impacting 2.6.32 and according to the comments won't be needed in 2.6.33.
>> Right now, 2.6.32 doesn't build for a general Fedora ppc32 kernel because of
>> this bug. Should this be sent to Linus for .32?
>
>Why would fedora have DEBUG_HIGHMEM enabled ? I'll see what I can do.
Why shouldn't it? Fedora generally builds rawhide kernels with all kinds of
debug options set.
When you say you'll see what you can do, do you mean you'll see if you can get
the patch into .32, or change the Fedora config? If you mean change the Fedora
config, I can do that myself. I was more pointing out that you have a .32
patch not needed for .33 heading for .33... ;)
josh
^ permalink raw reply
* Re: [PATCH] powerpc: Fix DEBUG_HIGHMEM build break from d4515646699
From: Benjamin Herrenschmidt @ 2009-11-30 20:16 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, mingo
In-Reply-To: <20091130195435.GE2937@zod.rchland.ibm.com>
> When you say you'll see what you can do, do you mean you'll see if you can get
> the patch into .32, or change the Fedora config? If you mean change the Fedora
> config, I can do that myself. I was more pointing out that you have a .32
> patch not needed for .33 heading for .33... ;)
I'll try to get the patch in later today
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 0/3] Kernel handling of Dynamic Logical Partitioning
From: Nathan Fontenot @ 2009-11-30 20:48 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linuxppc-dev, gregkh, paul Mackerras, linux-kernel
In-Reply-To: <m13a3ztwtw.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Nathan Fontenot <nfont@austin.ibm.com> writes:
>
>> version 2 of the patch set with updates from comments.
>>
>> The Dynamic Logical Partitioning (DLPAR) capabilities of the powerpc pseries
>> platform allows for the addition and removal of resources (i.e. cpus,
>> memory, pci devices) from a partition. The removal of a resource involves
>> removing the resource's node from the device tree and then returning the
>> resource to firmware via the rtas set-indicator call. To add a resource, it
>> is first obtained from firmware via the rtas set-indicator call and then a
>> new device tree node is created using the ibm,configure-coinnector rtas call
>> and added to the device tree.
>>
>> The following set of patches implements the needed infrastructure to have the
>> kernel handle the DLPAR addition and removal of cpus (other DLPAR'able items to
>> follow in future patches). The framework for this is to create a set of
>> probe/release sysfs files that will facilitate arch-specific call-outs to handle
>> addition and removal of cpus to the system.
>
> How does this differ from /sys/devices/system/cpu/cpuX/online ?
>
> From the descriptions it appears that we already have what you are trying to
> add and you just need to tie it into DLPAR on ppc.
>
The DLPAR and hotplug operations need to be kept separate for ppc. One big reason
for this is that DLPAR operations on ppc are driven from the Hardware Management
Console (HMC). It is (almost always) not possible to DLPAR add a resource (i.e.
cpu, memory,pcie device) from the OS. There are HMC <=> firmware interactions
that must occur to make the resource available to the partition.
Second is that there are times when one would want to hotplug add/remove
a cpu but not dlpar add/remove it.
When a resource is DLPAR removed, the OS has no knowledge that the resource exists.
Likewise, this allows the addition of resources from the HMC after the system is booted.
This is a feature of ppc partitions that allows for the dynamic movement of resources
between partitions.
-Nathan Fontenot
^ permalink raw reply
* Re: [PATCH 00/10 v6] Fix 8xx MMU/TLB
From: Scott Wood @ 2009-11-30 22:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1259357845.2076.9.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Fri, 2009-11-27 at 11:57 +0100, Joakim Tjernlund wrote:
>> Scott and Rex, I think we need you s-o-b to make it into the kernel proper.
>>
>> Marcelo and Vitaly, I noticed you guys are listed as 8xx maintainers.
>> Have you seen this? What do you think?
>
> I think Marcelo isn't much involved with 8xx anymore. I'd say if Scott
> and Vitaly are ok, then the patches are good. But I'll wait for at least
> Scott to give an Ack as he can at least test which I can't :-)
ACK
-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