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 w
> 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 t
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 wi
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 2.
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 an
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
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 9d304b1..ad23
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 b/arch/powerpc/sysdev/fsl_s
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
>>
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 coul
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 "adva
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%
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
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 fo
> > 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 p
On Thu, Aug 23, 2007 at 12:47:57PM +1000, David Gibson wrote:
> > ./drivers/mtd/maps/tqm834x.c:#include
> > ./drivers/mtd/maps/pq2fads.c:#include
>
> Although these both have an extern of type bd_t (defined in
> ppcboot.h), afaict they don't actually use it, so these should be
> removable.
They
>> 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 comp
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 '@'. So your getprop change does not match real OF
> behaviour
>>> 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 dri
> Actually, in any case, I don't think we want to implement get_path()
> this way for real OF. Better to have get_path() itself as a callback:
> on real OF I believe we can directly ask for the full path to a given
> phandle,
Yes. "package-to-path" from the client interface.
Segher
__
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
>>> ./drivers/mtd/maps/pq2fads.c:#include
>>
>> Although these both have an extern of type bd_t (defined in
>> ppcboot.h), afaict they don't
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, u
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.
>
>
> arch
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
On Thu, 2007-08-23 at 15:47, Kumar Gala wrote:
> > Any reason why patches 1/5 and 2/5, for 86xx and 85xx respectively,
> > did not get applied and ushered upstream with the others?
>
> No, I'm glad you said something cause I assumed paul grabbed them all.
>
> I'll grab them in my tree once I bea
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. gcc-3.4.5/binutils
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 usage:
> >>
> >> ./drivers/macintosh/adb-iop.c:#include remove
> >> ./drivers/char/vme_scc.c:#include 68k only
> >> ./drivers/char/serial167.c:#include
Whitespace cleanup: badly indented lines.
Typo in comment.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
---
Yeah, OK, so the patch is lame. Stuff caught my eye while reading code.
arch/powerpc/kernel/prom_init.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Index: li
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 there's no way to make dependencies between initcalls, we'll just
> have t
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 slb
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
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 b/arch/powerpc/k
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.
> >
> kmalloc() returns a void pointer so there is absolutely no need to
> cast it in ibmebus_chomp().
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Acked-By: Joachim Fenkes <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
htt
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
> > befo
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 expen
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:
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 imp
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.
> >
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
On Fri, Aug 24, 2007 at 06:59:38AM +0200, Benjamin Herrenschmidt wrote:
> 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
After talking to an IBM POWER hypervisor design and development (PHYP)
guy, there seems to be no need for memory barriers when updating the SLB
shadow buffer provided we only update it from the current CPU, which we
do.
Also, these guys see no need in the future for these barriers.
Signed-off-by:
45 matches
Mail list logo
