* Re: [PATCH v3 12/13] [POWERPC] Promess Motion-PRO DTS
From: Grant Likely @ 2007-11-09 17:49 UTC (permalink / raw)
To: Marian Balakowicz, linuxppc-dev
In-Reply-To: <20071106224200.GE31367@localhost.localdomain>
On 11/6/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Tue, Nov 06, 2007 at 09:06:34PM +0100, Marian Balakowicz wrote:
> [snip]
> > + // PSC2 in spi master mode
> > + spi@2200 { // PSC2
> > + compatible = "mpc5200b-psc-spi","mpc5200-psc-spi";
> > + cell-index = <1>;
>
> From your description, this is an incorrect usage of cell-index - it
> should *only* be used to index into SoC shared registers; never for
> logical numbering.
Actually, this one is correct. PSCs are numbered in the data sheet
from PSC1 to PSC6; so cell-index = <0> for PSC1, cell-index = <1> for
PSC2, etc.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* PPC440EPx on Sequoia: /proc/iomem acts weird
From: Steven A. Falco @ 2007-11-09 18:30 UTC (permalink / raw)
To: linuxppc-dev
If I cat /proc/iomem on a Sequoia board, it never stops printing. Here
are the first 10 lines:
bash-3.00# head -10 /proc/iomem
e0000100-e000017f : usb
e0000100-e000017f : musbhsfc_udc
e0000300-e000038f : ehci_hcd
180000000-18fffffff : /plb/pci@1eec00000
1d0000000-1d0001fff : ndfc
1d0000000-1d0001fff : ndfc
1d0000000-1d0001fff : ndfc
1d0000000-1d0001fff : ndfc
1d0000000-1d0001fff : ndfc
1d0000000-1d0001fff : ndfc
Basically, the last line (regarding the nand flash) keeps repeating
"forever".
Is anyone else seeing this behavior? My kernel is 2.6.23 with Xenomai
patched in.
Steve
^ permalink raw reply
* Re: PPC440EPx on Sequoia: /proc/iomem acts weird
From: Josh Boyer @ 2007-11-09 18:35 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <4734A72B.2070104@harris.com>
On Fri, 09 Nov 2007 13:30:03 -0500
"Steven A. Falco" <sfalco@harris.com> wrote:
> If I cat /proc/iomem on a Sequoia board, it never stops printing. Here
> are the first 10 lines:
>
> bash-3.00# head -10 /proc/iomem
> e0000100-e000017f : usb
> e0000100-e000017f : musbhsfc_udc
> e0000300-e000038f : ehci_hcd
> 180000000-18fffffff : /plb/pci@1eec00000
> 1d0000000-1d0001fff : ndfc
> 1d0000000-1d0001fff : ndfc
> 1d0000000-1d0001fff : ndfc
> 1d0000000-1d0001fff : ndfc
> 1d0000000-1d0001fff : ndfc
> 1d0000000-1d0001fff : ndfc
>
> Basically, the last line (regarding the nand flash) keeps repeating
> "forever".
>
> Is anyone else seeing this behavior? My kernel is 2.6.23 with Xenomai
> patched in.
Erm.. 2.6.23? There is no Sequoia support in arch/ppc or arch/powerpc
for 2.6.23 in the official trees. What is Xenomai? You should
probably talk to them.
josh
^ permalink raw reply
* Re: PPC440EPx on Sequoia: /proc/iomem acts weird
From: Steven A. Falco @ 2007-11-09 18:46 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071109123522.072bc1d8@weaponx>
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
I am using the Denx 2.6.32 kernel, which does have powerpc/sequoia.
Xenomai is a real-time kernel built on Adeos/Ipipe. I'll dig into it
further.
Steve
Josh Boyer wrote:
> On Fri, 09 Nov 2007 13:30:03 -0500
> "Steven A. Falco" <sfalco@harris.com> wrote:
>
>
>> If I cat /proc/iomem on a Sequoia board, it never stops printing. Here
>> are the first 10 lines:
>>
>> bash-3.00# head -10 /proc/iomem
>> e0000100-e000017f : usb
>> e0000100-e000017f : musbhsfc_udc
>> e0000300-e000038f : ehci_hcd
>> 180000000-18fffffff : /plb/pci@1eec00000
>> 1d0000000-1d0001fff : ndfc
>> 1d0000000-1d0001fff : ndfc
>> 1d0000000-1d0001fff : ndfc
>> 1d0000000-1d0001fff : ndfc
>> 1d0000000-1d0001fff : ndfc
>> 1d0000000-1d0001fff : ndfc
>>
>> Basically, the last line (regarding the nand flash) keeps repeating
>> "forever".
>>
>> Is anyone else seeing this behavior? My kernel is 2.6.23 with Xenomai
>> patched in.
>>
>
> Erm.. 2.6.23? There is no Sequoia support in arch/ppc or arch/powerpc
> for 2.6.23 in the official trees. What is Xenomai? You should
> probably talk to them.
>
> josh
>
>
[-- Attachment #2: Type: text/html, Size: 1626 bytes --]
^ permalink raw reply
* Hardware watchpoints on Cell/B.E. broken
From: Ulrich Weigand @ 2007-11-09 18:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: arnd
Hello,
I've noticed that GDB hardware watchpoints do not work at all on Cell/B.E.
(when running without hypervisor); the kernel accepts the PTRACE_SET_DEBUGREG
call without error, but watchpoints never trigger.
This turns out to be caused by a new hardware feature in the PowerPC 2.02
architecture level: the DABRX register. This register controls in which
modes of operation (problem state, privileged state, hypervisor state)
the DABR register takes effect. (See Book III v 2.02 page 40.)
The default setting of that register on Cell/B.E. (at least on IBM blades),
which the Linux kernel currently never modifies, is to ignore DABR in all
modes -- thus watchpoints do not work at all.
The following hack sets the bit in the DABRX that enables the DABR for
problem state, whenever the DABR is set. With this patch on top of the
current Fedora 8 update kernel (kernel-2.6.23.1-48.fc8) watchpoints work
again -- all relevant test cases in the GDB test suite now pass.
Obviously, the patch cannot be applied as-is; we need to make sure we are
on a machine that supports the DABRX feature. Arnd asked me to post this
anyway as a heads-up on that problem ...
Bye,
Ulrich
--- linux-2.6.23.ppc64/arch/powerpc/kernel/process.c.orig
+++ linux-2.6.23.ppc64/arch/powerpc/kernel/process.c
@@ -229,6 +229,7 @@
/* XXX should we have a CPU_FTR_HAS_DABR ? */
#if defined(CONFIG_PPC64) || defined(CONFIG_6xx)
mtspr(SPRN_DABR, dabr);
+ mtspr(1015, 1); /* enable DABR for user space */
#endif
return 0;
}
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-09 20:16 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071109132507.GA21232@localhost.localdomain>
On Fri, 9 Nov 2007 16:25:07 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
> [...]
> > right, but whether it does or not doesn't affect your failure outcome
> > either I'm assuming.
> >
> > > > If it's something like 0x03, the u-boot patch will probably look like:
> > > >
> > > > if ((bcsr[12] == 0x10) &&
> > > > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > > > immr->sysconf.spridr == SPR_8360E_REV21))
> > > > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > > > ...
> > > >
> > > > but these linux patches would remain the same (the clk and data delay
> > > > settings for the UCC's are still valid; it's just the PHY config
> > > > that is triggering your problem from what I can tell).
> > >
> > > Yup, most likely this is not UCC specific, but PHY. For some reason
> > > delays making harm here...
>
> And today I was unable to reproduce yesterday's behaviour. Your
> patches works fine, with sixth patch and without it. With -rxid
> and with just -id.
excellent. btw, you should be paying a 50% packet loss price by not
going with the -rxid. ping your board with '-q -s 1400 -i 0.01 -c 100'
to notice the difference.
>
> Though, after few resets I hit on that:
>
> - - - -
> U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
>
> Reset Status: External/Internal Soft, External/Internal Hard
>
> CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
> Board: Freescale MPC8360EMDS
> I2C: ready
> DRAM: 256 MB (DDR2, 64-bit, ECC on)
> SDRAM: 64 MB (local bus)
> FLASH: 32 MB
> In: serial
> Out: serial
> Err: serial
> Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
> FSL UEC0: Full Duplex
> switching to rgmii 100
> FSL UEC0: Speed 100BT
> FSL UEC0: Link is up
> read wrong value : mii_id 1,mii_reg 2, base e0103120
> read wrong value : mii_id 1,mii_reg 3, base e0103120
> UEC: PHY is Generic MII (ffffffff)
> read wrong value : mii_id 1,mii_reg 1, base e0103120
> read wrong value : mii_id 1,mii_reg 1, base e0103120
> read wrong value : mii_id 1,mii_reg 5, base e0103120
> FSL UEC1: Full Duplex
> switching to rgmii 100
> FSL UEC1: Speed 100BT
> FSL UEC1: Link is up
> FSL UEC0, FSL UEC1
> - - - -
>
> And UCC1 does not work at all. After another reset that message
> disappears and it does work again.
>
the RGMII bcsr settings survive soft-resets, which confuse u-boot since
it uses GMII mode.
Kim
^ permalink raw reply
* Using PVR value after boot?
From: Mike Nuss @ 2007-11-09 20:39 UTC (permalink / raw)
To: linuxppc-dev
I'm writing a module for the Security/KASUMI function on the
PPC440EPx-S and PPC440GRx-S. This relies on checking the PVR value at
runtime, which is done early on in the boot process. What would be
the correct way to check which CPU is present during module
initialization?
Thanks,
Mike
^ permalink raw reply
* [PATCH v2] fix multiple bugs in rtas_ibm_suspend_me code
From: Nathan Lynch @ 2007-11-09 20:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20071106044309.GK9695@localdomain>
There are several issues with the rtas_ibm_suspend_me code, which
enables platform-assisted suspension of an LPAR for migration or
hibernation as covered in PAPR 2.2.
1.) rtas_ibm_suspend_me uses on_each_cpu() to invoke
rtas_percpu_suspend_me on all cpus via IPI:
if (on_each_cpu(rtas_percpu_suspend_me, &data, 1, 0))
...
'data' is on the calling task's stack, but rtas_ibm_suspend_me takes
no measures to ensure that all instances of rtas_percpu_suspend_me are
finished accessing 'data' before returning. This can result in the
IPI'd cpus accessing random stack data and getting stuck in H_JOIN.
This is addressed by using an atomic count of workers and a completion
on the stack.
2.) rtas_percpu_suspend_me is needlessly calling H_JOIN in a loop.
The only event that can cause a cpu to return from H_JOIN is an H_PROD
from another cpu or a NMI/system reset. Each cpu need call H_JOIN
only once per suspend operation.
Remove the loop and the now unnecessary 'waiting' state variable.
3.) H_JOIN must be called with MSR[EE] off, but lazy interrupt
disabling may cause the caller of rtas_ibm_suspend_me to call H_JOIN
with it on; the local_irq_disable() in on_each_cpu() is not
sufficient.
Fix this by explicitly saving the MSR and clearing the EE bit before
calling H_JOIN.
4.) H_PROD is being called with the Linux logical cpu number as the
parameter, not the platform interrupt server value. (It's also being
called for all possible cpus, which is harmless, but unnecessary.)
This is fixed by calling H_PROD for each online cpu using
get_hard_smp_processor_id(cpu) for the argument.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/kernel/rtas.c | 94 +++++++++++++++++++++++++-------------------
1 files changed, 53 insertions(+), 41 deletions(-)
Changes since v1:
- the completion is adequate for ensuring that all IPIs have
completed, so there's no need for a mutex and rtas_suspend_me_data
can be on the stack as before.
- add fix for hard-disabling interrupts before H_JOIN
- remove unnecessary H_JOIN loop and state machinery
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 2147807..3afe771 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -41,8 +41,10 @@ struct rtas_t rtas = {
EXPORT_SYMBOL(rtas);
struct rtas_suspend_me_data {
- long waiting;
- struct rtas_args *args;
+ atomic_t working; /* number of cpus accessing this struct */
+ int token; /* ibm,suspend-me */
+ int error;
+ struct completion *complete; /* wait on this until working == 0 */
};
DEFINE_SPINLOCK(rtas_data_buf_lock);
@@ -657,50 +659,62 @@ static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
#ifdef CONFIG_PPC_PSERIES
static void rtas_percpu_suspend_me(void *info)
{
- int i;
long rc;
- long flags;
+ unsigned long msr_save;
+ int cpu;
struct rtas_suspend_me_data *data =
(struct rtas_suspend_me_data *)info;
- /*
- * We use "waiting" to indicate our state. As long
- * as it is >0, we are still trying to all join up.
- * If it goes to 0, we have successfully joined up and
- * one thread got H_CONTINUE. If any error happens,
- * we set it to <0.
- */
- local_irq_save(flags);
- do {
- rc = plpar_hcall_norets(H_JOIN);
- smp_rmb();
- } while (rc == H_SUCCESS && data->waiting > 0);
- if (rc == H_SUCCESS)
- goto out;
+ atomic_inc(&data->working);
+
+ /* really need to ensure MSR.EE is off for H_JOIN */
+ msr_save = mfmsr();
+ mtmsr(msr_save & ~(MSR_EE));
+
+ rc = plpar_hcall_norets(H_JOIN);
+
+ mtmsr(msr_save);
- if (rc == H_CONTINUE) {
- data->waiting = 0;
- data->args->args[data->args->nargs] =
- rtas_call(ibm_suspend_me_token, 0, 1, NULL);
- for_each_possible_cpu(i)
- plpar_hcall_norets(H_PROD,i);
+ if (rc == H_SUCCESS) {
+ /* This cpu was prodded and the suspend is complete. */
+ goto out;
+ } else if (rc == H_CONTINUE) {
+ /* All other cpus are in H_JOIN, this cpu does
+ * the suspend.
+ */
+ printk(KERN_DEBUG "calling ibm,suspend-me on cpu %i\n",
+ smp_processor_id());
+ data->error = rtas_call(data->token, 0, 1, NULL);
+
+ if (data->error)
+ printk(KERN_DEBUG "ibm,suspend-me returned %d\n",
+ data->error);
} else {
- data->waiting = -EBUSY;
- printk(KERN_ERR "Error on H_JOIN hypervisor call\n");
+ printk(KERN_ERR "H_JOIN on cpu %i failed with rc = %ld\n",
+ smp_processor_id(), rc);
+ data->error = rc;
}
-
+ /* This cpu did the suspend or got an error; in either case,
+ * we need to prod all other other cpus out of join state.
+ * Extra prods are harmless.
+ */
+ for_each_online_cpu(cpu)
+ plpar_hcall_norets(H_PROD, get_hard_smp_processor_id(cpu));
out:
- local_irq_restore(flags);
- return;
+ if (atomic_dec_return(&data->working) == 0)
+ complete(data->complete);
}
static int rtas_ibm_suspend_me(struct rtas_args *args)
{
- int i;
long state;
long rc;
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
struct rtas_suspend_me_data data;
+ DECLARE_COMPLETION_ONSTACK(done);
+
+ if (!rtas_service_present("ibm,suspend-me"))
+ return -ENOSYS;
/* Make sure the state is valid */
rc = plpar_hcall(H_VASI_STATE, retbuf,
@@ -721,25 +735,23 @@ static int rtas_ibm_suspend_me(struct rtas_args *args)
return 0;
}
- data.waiting = 1;
- data.args = args;
+ atomic_set(&data.working, 0);
+ data.token = rtas_token("ibm,suspend-me");
+ data.error = 0;
+ data.complete = &done;
/* Call function on all CPUs. One of us will make the
* rtas call
*/
if (on_each_cpu(rtas_percpu_suspend_me, &data, 1, 0))
- data.waiting = -EINVAL;
+ data.error = -EINVAL;
- if (data.waiting != 0)
- printk(KERN_ERR "Error doing global join\n");
+ wait_for_completion(&done);
- /* Prod each CPU. This won't hurt, and will wake
- * anyone we successfully put to sleep with H_JOIN.
- */
- for_each_possible_cpu(i)
- plpar_hcall_norets(H_PROD, i);
+ if (data.error != 0)
+ printk(KERN_ERR "Error doing global join\n");
- return data.waiting;
+ return data.error;
}
#else /* CONFIG_PPC_PSERIES */
static int rtas_ibm_suspend_me(struct rtas_args *args)
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: Using PVR value after boot?
From: Benjamin Herrenschmidt @ 2007-11-09 21:07 UTC (permalink / raw)
To: Mike Nuss; +Cc: linuxppc-dev
In-Reply-To: <a340dd0e0711091239mdf1b772l1d5a8208f7def4f5@mail.gmail.com>
On Fri, 2007-11-09 at 15:39 -0500, Mike Nuss wrote:
> I'm writing a module for the Security/KASUMI function on the
> PPC440EPx-S and PPC440GRx-S. This relies on checking the PVR value at
> runtime, which is done early on in the boot process. What would be
> the correct way to check which CPU is present during module
> initialization?
Checking the PVR can be done at any time, though a better option would
be to put something in device-tree of course :-)
Ben.
^ permalink raw reply
* Re: Hardware watchpoints on Cell/B.E. broken
From: Benjamin Herrenschmidt @ 2007-11-09 21:08 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: linuxppc-dev, arnd
In-Reply-To: <200711091854.lA9IsJEB027041@d12av02.megacenter.de.ibm.com>
On Fri, 2007-11-09 at 19:54 +0100, Ulrich Weigand wrote:
> Hello,
>
> I've noticed that GDB hardware watchpoints do not work at all on Cell/B.E.
> (when running without hypervisor); the kernel accepts the PTRACE_SET_DEBUGREG
> call without error, but watchpoints never trigger.
>
> This turns out to be caused by a new hardware feature in the PowerPC 2.02
> architecture level: the DABRX register. This register controls in which
> modes of operation (problem state, privileged state, hypervisor state)
> the DABR register takes effect. (See Book III v 2.02 page 40.)
>
> The default setting of that register on Cell/B.E. (at least on IBM blades),
> which the Linux kernel currently never modifies, is to ignore DABR in all
> modes -- thus watchpoints do not work at all.
>
> The following hack sets the bit in the DABRX that enables the DABR for
> problem state, whenever the DABR is set. With this patch on top of the
> current Fedora 8 update kernel (kernel-2.6.23.1-48.fc8) watchpoints work
> again -- all relevant test cases in the GDB test suite now pass.
>
> Obviously, the patch cannot be applied as-is; we need to make sure we are
> on a machine that supports the DABRX feature. Arnd asked me to post this
> anyway as a heads-up on that problem ...
Hrm, ok, something we missed, I'll have a look. The whole DABR / debug
register handling need work anyway.
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix oops related to 4xx flush_tlb_page modification
From: Benjamin Herrenschmidt @ 2007-11-09 21:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711090358300.28266@blarg.am.freescale.net>
On Fri, 2007-11-09 at 03:58 -0600, Kumar Gala wrote:
> kmap_atomic calls flush_tlb_page with a NULL VMA and thus we end
> up dereferencing a NULL pointer to try and get the context.id.
>
> If the VMA is null use the global pid value of 0.
Ack.
> ---
> include/asm-powerpc/tlbflush.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h
> index e7b4c0d..5c91081 100644
> --- a/include/asm-powerpc/tlbflush.h
> +++ b/include/asm-powerpc/tlbflush.h
> @@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
> static inline void flush_tlb_page(struct vm_area_struct *vma,
> unsigned long vmaddr)
> {
> - _tlbie(vmaddr, vma->vm_mm->context.id);
> + _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
> }
>
> static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
> unsigned long vmaddr)
> {
> - _tlbie(vmaddr, vma->vm_mm->context.id);
> + _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
> }
>
> static inline void flush_tlb_range(struct vm_area_struct *vma,
^ permalink raw reply
* Re: Appletouch going wild
From: Benjamin Herrenschmidt @ 2007-11-09 21:12 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, linux-input
In-Reply-To: <je640ba837.fsf@sykes.suse.de>
On Fri, 2007-11-09 at 13:58 +0100, Andreas Schwab wrote:
> Every once in a while the touchpad in my iBook G4 (geyser1, 030B) is
> going wild, emitting random movement events even when not being touched.
> That started only with 2.6.24-rc1. The only way to stop it is to reload
> the appletouch module. My guess would be that reinitializing the
> touchpad can result in some kind of race condition.
I always had that problem if I do something like leaving my finger too
long on it...
Ben.
^ permalink raw reply
* Re: Using PVR value after boot?
From: Josh Boyer @ 2007-11-09 21:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194642444.21340.16.camel@pasglop>
On Sat, 2007-11-10 at 08:07 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2007-11-09 at 15:39 -0500, Mike Nuss wrote:
> > I'm writing a module for the Security/KASUMI function on the
> > PPC440EPx-S and PPC440GRx-S. This relies on checking the PVR value at
> > runtime, which is done early on in the boot process. What would be
> > the correct way to check which CPU is present during module
> > initialization?
>
> Checking the PVR can be done at any time, though a better option would
> be to put something in device-tree of course :-)
Absolutely.
josh
^ permalink raw reply
* On-going 4xx porting
From: Josh Boyer @ 2007-11-09 22:01 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
For those interested, I have a few things I'd like to focus on for
2.6.25 in regards to the current arch/powerpc 4xx porting effort. Below
is a brief list of drivers in no particular order:
PCI support
USB (440EP(x), etc)
I2C
GPIO
NDFC
RTC
I'd also like to try and get the larger page size patches ported and
merged. If another hugetlbfs type patch shows up, that would be good
too. There is also the HW watchpoint support patch, and of course new
board ports.
At some point we should really be able to have a single vmlinux be
wrapped with different zImage wrappers and .dts files and have it boot
on those various boards just fine. So I'll be looking at accomplishing
that as well. That should make new board ports fairly easy to do.
josh
^ permalink raw reply
* [PATCH] Avoid unpaired stwcx. on some processors
From: Becky Bruce @ 2007-11-09 22:08 UTC (permalink / raw)
To: linuxppc-dev
The context switch code in the kernel issues a dummy stwcx. to clear the
reservation, as recommended by the architecture. However, some processors
can have issues if this stwcx to address A occurs while the reservation
is already held to a different address B. To avoid this problem, the dummy
stwcx. needs to be paired with a dummy lwarx to the same address.
This patch adds the dummy lwarx, and creates a cpu feature bit to indicate
which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/powerpc;
build tested in arch/ppc.
<Signed-off-by> Becky Bruce <becky.bruce@freescale.com>
---
arch/powerpc/kernel/entry_32.S | 6 ++++++
arch/ppc/kernel/entry.S | 6 ++++++
include/asm-powerpc/cputable.h | 22 ++++++++++++----------
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 21d889e..6461dca 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -244,6 +244,9 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
+BEGIN_FTR_SECTION
+ lwarx r7,0,r1
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stwcx. r0,0,r1 /* to clear the reservation */
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
@@ -694,6 +697,9 @@ restore:
mtctr r11
PPC405_ERR77(0,r1)
+BEGIN_FTR_SECTION
+ lwarx r11,0,r1
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stwcx. r0,0,r1 /* to clear the reservation */
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
index fba7ca1..aa57dee 100644
--- a/arch/ppc/kernel/entry.S
+++ b/arch/ppc/kernel/entry.S
@@ -244,6 +244,9 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
+BEGIN_FTR_SECTION
+ lwarx r7,0,r1
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stwcx. r0,0,r1 /* to clear the reservation */
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
@@ -690,6 +693,9 @@ restore:
mtctr r11
PPC405_ERR77(0,r1)
+BEGIN_FTR_SECTION
+ lwarx r11,0,r1
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stwcx. r0,0,r1 /* to clear the reservation */
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 9d74338..4525c78 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -138,6 +138,7 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start,
#define CPU_FTR_FPU_UNAVAILABLE ASM_CONST(0x0000000000800000)
#define CPU_FTR_UNIFIED_ID_CACHE ASM_CONST(0x0000000001000000)
#define CPU_FTR_SPE ASM_CONST(0x0000000002000000)
+#define CPU_FTR_NEED_PAIRED_STWCX ASM_CONST(0x0000000004000000)
/*
* Add the 64-bit processor unique features in the top half of the word;
@@ -261,25 +262,25 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start,
#define CPU_FTRS_7450_20 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7450_21 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7450_23 (CPU_FTR_COMMON | \
- CPU_FTR_USE_TB | \
+ CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
#define CPU_FTRS_7455_1 (CPU_FTR_COMMON | \
- CPU_FTR_USE_TB | \
+ CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \
CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | CPU_FTR_L3CR | \
CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | CPU_FTR_HAS_HIGH_BATS | \
CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
#define CPU_FTRS_7455_20 (CPU_FTR_COMMON | \
- CPU_FTR_USE_TB | \
+ CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \
@@ -289,31 +290,32 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start,
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7447_10 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_NO_BTIC | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_NO_BTIC | CPU_FTR_PPC_LE | \
+ CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7447 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7447A (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7448 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_PPC_LE)
+ CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_82XX (CPU_FTR_COMMON | \
CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB)
#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
--
1.5.3
^ permalink raw reply related
* [PATCH] Avoid unpaired stwcx. on some processors
From: Becky Bruce @ 2007-11-09 22:17 UTC (permalink / raw)
To: linuxppc-dev
The context switch code in the kernel issues a dummy stwcx. to clear the
reservation, as recommended by the architecture. However, some processors
can have issues if this stwcx to address A occurs while the reservation
is already held to a different address B. To avoid this problem, the dummy
stwcx. needs to be paired with a dummy lwarx to the same address.
This patch adds the dummy lwarx, and creates a cpu feature bit to indicate
which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/powerpc;
build tested in arch/ppc.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
Resend with correct signed-off-by line!
arch/powerpc/kernel/entry_32.S | 6 ++++++
arch/ppc/kernel/entry.S | 6 ++++++
include/asm-powerpc/cputable.h | 22 ++++++++++++----------
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 21d889e..6461dca 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -244,6 +244,9 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
+BEGIN_FTR_SECTION
+ lwarx r7,0,r1
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stwcx. r0,0,r1 /* to clear the reservation */
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
@@ -694,6 +697,9 @@ restore:
mtctr r11
PPC405_ERR77(0,r1)
+BEGIN_FTR_SECTION
+ lwarx r11,0,r1
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stwcx. r0,0,r1 /* to clear the reservation */
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
index fba7ca1..aa57dee 100644
--- a/arch/ppc/kernel/entry.S
+++ b/arch/ppc/kernel/entry.S
@@ -244,6 +244,9 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
+BEGIN_FTR_SECTION
+ lwarx r7,0,r1
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stwcx. r0,0,r1 /* to clear the reservation */
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
@@ -690,6 +693,9 @@ restore:
mtctr r11
PPC405_ERR77(0,r1)
+BEGIN_FTR_SECTION
+ lwarx r11,0,r1
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stwcx. r0,0,r1 /* to clear the reservation */
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 9d74338..4525c78 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -138,6 +138,7 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start,
#define CPU_FTR_FPU_UNAVAILABLE ASM_CONST(0x0000000000800000)
#define CPU_FTR_UNIFIED_ID_CACHE ASM_CONST(0x0000000001000000)
#define CPU_FTR_SPE ASM_CONST(0x0000000002000000)
+#define CPU_FTR_NEED_PAIRED_STWCX ASM_CONST(0x0000000004000000)
/*
* Add the 64-bit processor unique features in the top half of the word;
@@ -261,25 +262,25 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start,
#define CPU_FTRS_7450_20 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7450_21 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7450_23 (CPU_FTR_COMMON | \
- CPU_FTR_USE_TB | \
+ CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
#define CPU_FTRS_7455_1 (CPU_FTR_COMMON | \
- CPU_FTR_USE_TB | \
+ CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \
CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | CPU_FTR_L3CR | \
CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | CPU_FTR_HAS_HIGH_BATS | \
CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
#define CPU_FTRS_7455_20 (CPU_FTR_COMMON | \
- CPU_FTR_USE_TB | \
+ CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \
@@ -289,31 +290,32 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start,
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7447_10 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_NO_BTIC | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_NO_BTIC | CPU_FTR_PPC_LE | \
+ CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7447 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7447A (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
+ CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_7448 (CPU_FTR_COMMON | \
CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
- CPU_FTR_PPC_LE)
+ CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_82XX (CPU_FTR_COMMON | \
CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB)
#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
--
1.5.3
^ permalink raw reply related
* Re: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
From: Randy Vinson @ 2007-11-09 22:34 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C90B3DB@zch01exm26.fsl.freescale.net>
Zhang Wei-r63237 wrote:
> Yes, I'm working on it. Do not worry about it.
How's this going? I've been working on this a bit myself, but if you are
close to posting your stuff, I'll stop and wait for your version
instead. It doesn't make sense for us to duplicate the same work.
Randy Vinson
^ permalink raw reply
* Re: [PATCH] Avoid unpaired stwcx. on some processors
From: Olof Johansson @ 2007-11-09 23:19 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <11946460863124-git-send-email-becky.bruce@freescale.com>
On Fri, Nov 09, 2007 at 04:08:06PM -0600, Becky Bruce wrote:
> The context switch code in the kernel issues a dummy stwcx. to clear the
> reservation, as recommended by the architecture. However, some processors
> can have issues if this stwcx to address A occurs while the reservation
> is already held to a different address B. To avoid this problem, the dummy
> stwcx. needs to be paired with a dummy lwarx to the same address.
>
> This patch adds the dummy lwarx, and creates a cpu feature bit to indicate
> which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/powerpc;
> build tested in arch/ppc.
You're still exposed even with this patch. The stwcx is there to protect
from the cases where process 1 does lwarx and get context switched
out to process 2 that by pure random chance does a stwcx. to the same
reservation granule and succeeds, in spite of not having done the lwarx
(on this side of the context switch).
In exactly that case, process 2 will instead of doing a store to a
reservation it didn't take on it's own, do a dangling stwcx, which is
your erratum. Right?
Seems like a "better" (but still ugly) workaround would be to create a
_new_ reservation to a RA that's unavailable to any userspace process,
so that they could never do a successful store to it. That way you would
have stray reservations, but never dangling stwcx:es. No?
-Olof
^ permalink raw reply
* Re: On-going 4xx porting
From: Vitaly Bordug @ 2007-11-09 23:48 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1194645701.3207.17.camel@localhost.localdomain>
On Fri, 09 Nov 2007 16:01:41 -0600
Josh Boyer wrote:
> Hi All,
>
> For those interested, I have a few things I'd like to focus on for
> 2.6.25 in regards to the current arch/powerpc 4xx porting effort.
> Below is a brief list of drivers in no particular order:
>
> PCI support
I'll look at that stuff once again. maybe it worths to head fir compromise solution in favor of replacing 32/64
ranges parsing func + a bunch of other things in one single step.
> USB (440EP(x), etc)
looks like we have code ready for that...
> I2C
Stefan's approach seems pretty close
> GPIO
> NDFC
I'd rather follow platform device wrapper way.. Big NDFC of_device rework can be done anytime later.
> RTC
>
> I'd also like to try and get the larger page size patches ported and
> merged. If another hugetlbfs type patch shows up, that would be good
> too. There is also the HW watchpoint support patch, and of course new
> board ports.
>
> At some point we should really be able to have a single vmlinux be
> wrapped with different zImage wrappers and .dts files and have it boot
> on those various boards just fine. So I'll be looking at
> accomplishing that as well. That should make new board ports fairly
> easy to do.
>
just my $0.02...
> josh
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] Avoid unpaired stwcx. on some processors
From: Becky Bruce @ 2007-11-09 23:52 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071109231927.GA19415@lixom.net>
On Nov 9, 2007, at 5:19 PM, Olof Johansson wrote:
> On Fri, Nov 09, 2007 at 04:08:06PM -0600, Becky Bruce wrote:
>> The context switch code in the kernel issues a dummy stwcx. to
>> clear the
>> reservation, as recommended by the architecture. However, some
>> processors
>> can have issues if this stwcx to address A occurs while the
>> reservation
>> is already held to a different address B. To avoid this problem,
>> the dummy
>> stwcx. needs to be paired with a dummy lwarx to the same address.
>>
>> This patch adds the dummy lwarx, and creates a cpu feature bit to
>> indicate
>> which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/
>> powerpc;
>> build tested in arch/ppc.
>
> You're still exposed even with this patch. The stwcx is there to
> protect
> from the cases where process 1 does lwarx and get context switched
> out to process 2 that by pure random chance does a stwcx. to the same
> reservation granule and succeeds, in spite of not having done the
> lwarx
> (on this side of the context switch).
> In exactly that case, process 2 will instead of doing a store to a
> reservation it didn't take on it's own, do a dangling stwcx, which is
> your erratum. Right?
I don't think so. It's not plain old dangling stwcx that's the
problem. It's dangling stwcx when the reservation is held to another
address. The lwarx that I've added prevents the normally dangling
stwcx. in the context switch/syscall path from meeting this
condition. Any process that gets swapped in and executes stwcx.
first thing is fine, because the reservation was previously cleared
by the stwcx. in the context switch path.
BTW, I think you're missing a key point here, which is this:
Architecturally, there is a single reservation per core. On e600 and
other parts, the stwcx. does *not* take the address into account for
success. If you stwcx, and the reservation is held, it succeeds
regardless of the address. Fun, no? That's one of the reasons
it's so important that the kernel have the dummy stwcx. in place.
Does that make sense?
-B
^ permalink raw reply
* Re: [PATCH] Avoid unpaired stwcx. on some processors
From: Olof Johansson @ 2007-11-10 0:18 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <260A8045-7F86-46EC-9242-08BC2669890F@freescale.com>
On Fri, Nov 09, 2007 at 05:52:30PM -0600, Becky Bruce wrote:
> I don't think so. It's not plain old dangling stwcx that's the
> problem. It's dangling stwcx when the reservation is held to another
> address.
Gack, I misread the description. My bad.
> The lwarx that I've added prevents the normally dangling
> stwcx. in the context switch/syscall path from meeting this
> condition. Any process that gets swapped in and executes stwcx.
> first thing is fine, because the reservation was previously cleared
> by the stwcx. in the context switch path.
>
> BTW, I think you're missing a key point here, which is this:
> Architecturally, there is a single reservation per core. On e600 and
> other parts, the stwcx. does *not* take the address into account for
> success. If you stwcx, and the reservation is held, it succeeds
> regardless of the address. Fun, no? That's one of the reasons
> it's so important that the kernel have the dummy stwcx. in place.
>
> Does that make sense?
Yep, it does, doesn't seem to be a better way to work around it.
-Olof
^ permalink raw reply
* Re: On-going 4xx porting
From: Josh Boyer @ 2007-11-10 0:17 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071110024813.5cada553@kernel.crashing.org>
On Sat, 2007-11-10 at 02:48 +0300, Vitaly Bordug wrote:
> On Fri, 09 Nov 2007 16:01:41 -0600
> Josh Boyer wrote:
>
> > Hi All,
> >
> > For those interested, I have a few things I'd like to focus on for
> > 2.6.25 in regards to the current arch/powerpc 4xx porting effort.
> > Below is a brief list of drivers in no particular order:
> >
> > PCI support
> I'll look at that stuff once again. maybe it worths to head fir compromise solution in favor of replacing 32/64
> ranges parsing func + a bunch of other things in one single step.
Sure, that's fine. You and Ben were working on it at one point, so I
figured you would look at it again.
> > USB (440EP(x), etc)
> looks like we have code ready for that...
It's mostly there, yes. Should be pretty easy to get in :).
> > I2C
> Stefan's approach seems pretty close
Agreed.
> > GPIO
> > NDFC
> I'd rather follow platform device wrapper way.. Big NDFC of_device rework can be done anytime later.
I would seriously consider that too.
josh
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Michael Neuling @ 2007-11-10 0:20 UTC (permalink / raw)
To: Thomas Klein, paulus
Cc: Jeff Garzik, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200711091433.51259.osstklei@de.ibm.com>
> To support ehea driver reloading in a kdump kernel the driver has to
> perform firmware handle deregistrations when the original kernel
> crashes. As there's currently no notifier chain for machine crashes
> this patch enables kdump support in the ehea driver by bending the
> ppc_md.machine_crash_shutdown hook to its own machine crash
> handler. The original machine_crash_shutdown() fn is called
> afterwards. This works fine as long as the ehea driver is the only one
> which does so. Problems may occur if other drivers do the same and
> unload regularly . This patch enables 2.6.24-rc2 to use kdump with
> ehea and only puts a very low risk on base kernel. In 2.6.24 we know
> ehea is the only user of this mechanism. The next step for 2.6.25
> would be to add a proper notifier chain. The full solution might be
> that register_reboot_notifier() provides sth like a SYS_CRASH
> action. Please apply.
If we are going to do this workaround, I'd prefer the notifier chain be
done correctly now. The way it's hacked in here, it's more likely to
cause even more issues.
Either way, if this is going to go in, it at least needs to be acked by
Paulus.
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
>
> ---
> drivers/net/ehea/ehea.h | 2 +-
> drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
> index f78e5bf..5935899 100644
> --- a/drivers/net/ehea/ehea.h
> +++ b/drivers/net/ehea/ehea.h
> @@ -40,7 +40,7 @@
> #include <asm/io.h>
>
> #define DRV_NAME "ehea"
> -#define DRV_VERSION "EHEA_0080"
> +#define DRV_VERSION "EHEA_0081"
>
> /* eHEA capability flags */
> #define DLPAR_PORT_ADD_REM 1
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index f0319f1..40a732e 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -37,6 +37,7 @@
> #include <linux/reboot.h>
>
> #include <net/ip.h>
> +#include <asm-powerpc/machdep.h>
>
> #include "ehea.h"
> #include "ehea_qmr.h"
> @@ -98,6 +99,7 @@ static int port_name_cnt = 0;
> static LIST_HEAD(adapter_list);
> u64 ehea_driver_flags = 0;
> struct work_struct ehea_rereg_mr_task;
> +static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
>
> struct semaphore dlpar_mem_lock;
>
> @@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
> .notifier_call = ehea_reboot_notifier,
> };
>
> +void ehea_crash_notifier(struct pt_regs *regs)
> +{
> + ehea_info("Machine crash: freeing all eHEA resources");
> + ibmebus_unregister_driver(&ehea_driver);
> + orig_machine_crash_shutdown(regs);
> +}
> +
> +void ehea_register_crash_notifier(void)
> +{
> +#ifdef CONFIG_KEXEC
> + orig_machine_crash_shutdown =
> + (void*)__xchg_u64((unsigned long*)&ppc_md.machine_crash_shutd
own,
> + (unsigned long)ehea_crash_notifier);
> +#endif
> +}
> +
> +void ehea_unregister_crash_notifier(void)
> +{
> +#ifdef CONFIG_KEXEC
> + ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
> +#endif
> +}
> +
> static int check_module_parm(void)
> {
> int ret = 0;
> @@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
> goto out;
>
> register_reboot_notifier(&ehea_reboot_nb);
> + ehea_register_crash_notifier();
>
> ret = ibmebus_register_driver(&ehea_driver);
> if (ret) {
> @@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
> ehea_error("failed to register capabilities attribute, ret=%d",
> ret);
> unregister_reboot_notifier(&ehea_reboot_nb);
> + ehea_unregister_crash_notifier();
> ibmebus_unregister_driver(&ehea_driver);
> goto out;
> }
> @@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
> driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
> ibmebus_unregister_driver(&ehea_driver);
> unregister_reboot_notifier(&ehea_reboot_nb);
> + ehea_unregister_crash_notifier();
> ehea_destroy_busmap();
> }
>
> --
> 1.5.2
>
^ permalink raw reply
* Re: [PATCH v4 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Stephen Rothwell @ 2007-11-10 0:31 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071109171202.16289.2618.stgit@hekate.izotz.org>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
On Fri, 09 Nov 2007 18:12:02 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>
> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
>
> +static int __init mpc5200_simple_probe(void)
> +{
> + unsigned long node = of_get_flat_dt_root();
You need to include asm/prom.h to use the flattened device tree accessors.
> + /* list of the supported boards */
> + const char *board[] = {
> + "tqc,tqm5200",
> + "promess,motionpro",
> + "schindler,cm5200",
> + NULL
> + };
Make that static.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
From: Jerry Van Baren @ 2007-11-10 1:14 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <473483DF.7060903@freescale.com>
Scott Wood wrote:
> Jerry Van Baren wrote:
>> My concern from the u-boot side is that u-boot has to know exactly
>> *where* to put the expanded blob because it has to pass it to linux
>> and keep it out of linux' way so it doesn't get "stepped on." Linux
>> has an advantage in that it "owns" all of memory and can allocate and
>> deallocate whatever and wherever and it won't step on itself (hopefully).
>
> Linux is pretty careful not to step on the device tree; it marks the
> area as reserved, and moves it if it really has to. The only scenario I
> think would be problematic is if the kernel is started somewhere other
> than zero, and has to relocate itself, and the relocation clobbers the
> device tree. That's easily avoided by making sure the device tree is at
> a higher address than the kernel -- and is really not much different
> than the old bd_t mechanism, which didn't use a user provided address
> AFAIK.
That is good to know, makes things much easier.
>> I'm assuming your boot wedge has the advantage of being able to use
>> linux's malloc() and thus don't have to worry about coordinating with
>> linux on memory allocation.
>
> No, it uses its own malloc.
>
>> With the current u-boot fdt command, you can resize the blob, and this
>> can be done in a script with all the (somewhat limited) capabilities
>> of the u-boot shell (an adaptation of hush).
>
> OK, I'm just going by the behavior of the default boot commands on (at
> least some of) our boards, which just give you an error if the blob
> isn't already enlarged.
>
> Maybe I should just poke Kim et al. about fixing our default environment
> -- though I'm guessing it'd still have to know from the script how much
> to enlarge the blob.
Currently it is a manual thing, my point was that it is potentially
scriptable (but would probably take a genius or 3 days of
experimentation to make the script work ;-). If we can settle on a safe
way to expand the blob automatically, I'm all for that.
>> In the u-boot world, we fixate on memory maps and putting things in
>> specific places.
>
> I've noticed. :-)
>
> -Scott
Yeah, I had a ruder term than "fixate" but changed it for public
consumption. ;-)
Best regards,
gvb
^ 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