On Thu, 23 Aug 2007 07:42:39 +0200 Olaf Hering [EMAIL PROTECTED] wrote:
On Thu, Aug 23, Stephen Rothwell wrote:
On Wed, 22 Aug 2007 19:51:21 +0200 Olaf Hering [EMAIL PROTECTED] wrote:
Does anyone know why dt_vdevices() creates a vscsi node on legacy iseries?
I'm sure only
Hi,
I applied the patch(13066). After that i got following error.
arch/powerpc/kernel/vmlinux.lds:59: parse error
I added the following lines in the vmlinux.lds file
ALIGN_FUNCTION();
*(.text.head)
Then i removed the ALIGN_FUNCTION() in the vmlinux.lds file. The parse error
was
On Wed, 2007-08-22 at 06:57 +0200, Nick Piggin wrote:
It doesn't seem like this primary function of mmiowb has anything to do
with a write barrier that we are used to (it may have a seconary semantic
of a wmb as well, but let's ignore that for now). A write barrier will
never provide you with
Of course, the normal memory barrier would usually be a spin_unlock() or
something like that, not a wmb(). In fact, I don't think the powerpc
implementation (as an example of this) will actually synchronize with
anything *but* a spin_unlock().
We are even more sneaky in the sense that we
On Thu, 2007-08-23 at 13:56 +1000, David Gibson wrote:
Jeff, I've discussed this with BenH, and although there are some
problems with the driver still, we think it's good enough to merge in
2.6.24, the warts can be fixed up later. Please apply...
Or to be more precise:
This driver will
Hi,
I am using 8641D processor and the silicon revision is 2.0.
Part : MPC8641D
Revision: 2.0
e600 Core Revision: 2.2
DeviceMarking: B
Processor Version Register Value: 0x8004_0202
System Version Register Value: 0x8090_0120
by
Sivaji
Hai,
I am using the kernel
On Wed, 22 Aug 2007, Kumar Gala wrote:
On Aug 22, 2007, at 10:33 PM, David Gibson wrote:
On Wed, Aug 22, 2007 at 10:33:55PM -0500, Kumar Gala wrote:
On Aug 22, 2007, at 10:19 AM, Kumar Gala wrote:
I was wondering if I could get your help with looking at the
following lists and determining
On Thu, Aug 23, 2007 at 01:24:21PM +1000, Stephen Rothwell wrote:
Hi Anton,
On Wed, 22 Aug 2007 18:57:32 +0400 Anton Vorontsov [EMAIL PROTECTED] wrote:
+ sysclk = *(u32 *)of_get_property(np, bus-frequency, NULL);
I just cringe everytime I see someone dereference a pointer they got
This is needed to configure and control QE pario pins from the kernel.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
include/asm-powerpc/qe.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 87 +
arch/powerpc/sysdev/fsl_soc.h |7 +++
2 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing spidev
with mmc_spi.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc832x_rdb.dts |2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 46
On Aug 23, 2007, at 1:13 AM, Stephen Rothwell wrote:
On Wed, 22 Aug 2007 22:26:35 -0500 Kumar Gala
[EMAIL PROTECTED] wrote:
+#ifdef CONFIG_PPC64
+ DEFINE(PGD_TABLE_SIZE, PGD_TABLE_SIZE);
+#endif
Why limit this to ppc64? The cleanup should be reasonable for all
ppc.
Because
On Thu, 23 Aug 2007, Nick Piggin wrote:
OK, but we'd have some kind of functions that are called not to
serialise the CPUs, but to serialise the IO. It would be up to
the calling code to already provide CPU synchronisation.
serialize_io(); / unserialize_io(); / a nicer name
We could
On Thu, 23 Aug 2007, Nick Piggin wrote:
Also, FWIW, there are some advantages of deferring the mmiowb thingy
until the point of unlock.
And that is exactly what ppc64 does.
But you're missing a big point: for 99.9% of all hardware, mmiowb() is a
total no-op. So when you talk about
On Thu, 2007-08-23 at 09:16 -0700, Linus Torvalds wrote:
On Thu, 23 Aug 2007, Nick Piggin wrote:
Also, FWIW, there are some advantages of deferring the mmiowb thingy
until the point of unlock.
And that is exactly what ppc64 does.
But you're missing a big point: for 99.9% of all
On Thursday, August 23, 2007 12:27 am Benjamin Herrenschmidt wrote:
Of course, the normal memory barrier would usually be a
spin_unlock() or something like that, not a wmb(). In fact, I
don't think the powerpc implementation (as an example of this) will
actually synchronize with anything
On Thursday 23 August 2007, [EMAIL PROTECTED] wrote:
Please check unit-id if physical-id doesn't exist. Because Celleb
uses unit-id to provide spe_id.
Ok, I need to discuss this with Christian then, to make sure we get to
a version that works everywhere. Paul, please ignore this patch for now.
Yeah, they keep threatening to use this instead, but I'm not sure
how easy it would be. Also they may have more devices/drivers to
worry about than sn2, so maybe changing over would mean too much
driver debugging (well auditing really since it's not that hard to
know where to put them).
On Thu, Aug 23, 2007 at 12:47:57PM +1000, David Gibson wrote:
./drivers/mtd/maps/tqm834x.c:#include asm/ppcboot.h
./drivers/mtd/maps/pq2fads.c:#include asm/ppcboot.h
Although these both have an extern of type bd_t (defined in
ppcboot.h), afaict they don't actually use it, so these should
The powerpc kernel needs to have full sync insns in every I/O
accessor in order to enforce all the ordering rules Linux demands.
It's a bloody shame, but the alternative would be to make the
barriers lots more expensive. A third alternative would be to
Well lots more expensive compared to
Drivers are definitely using these __raw_ accessors, and from a quick
look, they do appear to be hoping that *mb() is going to order access
for
them.
Which drivers?
There are maybe a dozen that use the raw accessors, and use non-smp_
memory barriers. I just looked at
On Aug 23, 2007, at 12:33 PM, Scott Wood wrote:
On Thu, Aug 23, 2007 at 12:47:57PM +1000, David Gibson wrote:
./drivers/mtd/maps/tqm834x.c:#include asm/ppcboot.h
./drivers/mtd/maps/pq2fads.c:#include asm/ppcboot.h
Although these both have an extern of type bd_t (defined in
ppcboot.h),
On Thu, Aug 23, 2007 at 10:31:03AM +1000, Stephen Rothwell wrote:
On Wed, 22 Aug 2007 09:12:48 -0500 Olof Johansson [EMAIL PROTECTED] wrote:
-static unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned int reg)
+static inline unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned
Move away from using the pci config access functions for simple register
access. Our device has all of the registers in the config space (hey,
from the hardware point of view it looks reasonable :-), so we need to
somehow get to it. Newer firmwares have it in the device tree such that
we can just
On Fri, 2007-07-27 at 13:23, Jon Loeliger wrote:
This patch series removes lingering jiffies initialization
code from several platforms. Note that the first patch in
this series for the 86xx has been rebased to current top of
Paul's repository and replaces an earlier version.
On Aug 23, 2007, at 3:23 PM, Jon Loeliger wrote:
On Fri, 2007-07-27 at 13:23, Jon Loeliger wrote:
This patch series removes lingering jiffies initialization
code from several platforms. Note that the first patch in
this series for the 86xx has been rebased to current top of
Paul's
Hi,
I was hunting an ugly problem in the NuBus PowerMac port of Linux [1]
for a while now (that platform isn't included in mainline kernel and
still is based on 2.4 kernel series).
Linux was successfully built using gcc-3.3.5/binutils-2.15 so far.
Later toolchain versions (e.g.
On Wed, Aug 22, 2007 at 11:16:03PM -0500, Kumar Gala wrote:
On Aug 22, 2007, at 10:33 PM, David Gibson wrote:
My analysis of asm/bootinfo.h usage:
./drivers/macintosh/adb-iop.c:#include asm/bootinfo.h remove
./drivers/char/vme_scc.c:#include asm/bootinfo.h 68k only
Andreas Schwab writes:
That didn't change anything visibly.
OK, please try this one and let me know if it fixes it.
Paul.
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index a73d2d7..1ca87eb 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -89,7 +89,7 @@ void
On Thu Aug 23 13:27:31 EST 2007, Kumar Gala wrote:
On Aug 22, 2007, at 10:09 PM, Stephen Rothwell wrote:
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 0028fe6..dc85005 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -60,6 +60,8 @@
kmalloc() returns a void pointer so there is absolutely no need to
cast it in ibmebus_chomp().
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
arch/powerpc/kernel/ibmebus.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c
On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote:
On Wed, 22 Aug 2007, Olof Johansson wrote:
With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
initcall is now called before I/O space is setup, but it's dependent on
it being available.
Since
On Thu, Aug 23, 2007 at 12:48:30PM -0500, Scott Wood wrote:
David Gibson wrote:
Actually, no - sorry, that's the other problem with this, which I
forgot to mention. On real OF, the name property contains the
node's name *without the unit address*; that is, only the portion
before the
On Thu, Aug 23, 2007 at 07:57:20PM +0200, Segher Boessenkool wrote:
The powerpc kernel needs to have full sync insns in every I/O
accessor in order to enforce all the ordering rules Linux demands.
It's a bloody shame, but the alternative would be to make the
barriers lots more expensive. A
On Thu, Aug 23, 2007 at 09:16:42AM -0700, Linus Torvalds wrote:
On Thu, 23 Aug 2007, Nick Piggin wrote:
Also, FWIW, there are some advantages of deferring the mmiowb thingy
until the point of unlock.
And that is exactly what ppc64 does.
But you're missing a big point: for 99.9%
On Thu, Aug 23, 2007 at 09:56:16AM -0700, Jesse Barnes wrote:
On Thursday, August 23, 2007 12:27 am Benjamin Herrenschmidt wrote:
Of course, the normal memory barrier would usually be a
spin_unlock() or something like that, not a wmb(). In fact, I
don't think the powerpc implementation
On Thu, Aug 23, 2007 at 06:27:42PM +0200, Benjamin Herrenschmidt wrote:
On Thu, 2007-08-23 at 09:16 -0700, Linus Torvalds wrote:
On Thu, 23 Aug 2007, Nick Piggin wrote:
Also, FWIW, there are some advantages of deferring the mmiowb thingy
until the point of unlock.
And that is
On Thu, 23 Aug 2007 13:13:10 -0500 Olof Johansson [EMAIL PROTECTED] wrote:
out:
- pci_dev_put(mac-iob_pdev);
-out_put_dma_pdev:
- pci_dev_put(mac-dma_pdev);
-out_free_netdev:
+ if (mac-iob_pdev)
+ pci_dev_put(mac-iob_pdev);
+ if (mac-dma_pdev)
+
On Thu, 2007-08-23 at 18:15 -0500, Olof Johansson wrote:
On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote:
On Wed, 22 Aug 2007, Olof Johansson wrote:
With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
initcall is now called before I/O space is
39 matches
Mail list logo
