Kumar Gala writes:
> Please pull from 'for_paulus' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus
Unfortunately with those commits I get this when compiling for a
64-bit target:
{standard input}: Assembler messages:
{standard input}:668: Error: Unre
[EMAIL PROTECTED] writes:
> +config PPC_CPU_SELECTION
> + bool "Advanced CPU selection"
Please provide some reasonable help for this option. As it is at the
moment, I get asked whether I want "Advanced CPU selection" - whatever
that is - and as a user I have no clue whether I want it or not.
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus
to receive the following updates:
arch/powerpc/Kconfig |6
arch/powerpc/Makefile | 19
arch/powerpc/boot/dts/mp
Hi, Segher,
> > +- #address-cells : Address representation for
> "rapidio" devices.
> > + This field represents the number of cells needed to represent
> > + the RapidIO address of the registers. For
> supporting more than
> > + 32-bits RapidIO address, this field should be
On Fri, 2007-06-29 at 00:38 +0100, Matt Sealey wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
> >> Hi,
> >>
> >> Trying to change PCI IO window base for 52xx target I found that
> >> we are pretty much limited to a "0" offset only.
> >
> > We
Benjamin Herrenschmidt wrote:
> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
>> Hi,
>>
>> Trying to change PCI IO window base for 52xx target I found that
>> we are pretty much limited to a "0" offset only.
>
> We just fixed that for 64 bits but 32 bits still has the limitation.
>
On Thu, 28 Jun 2007, Paul Mackerras wrote:
> Guennadi Liakhovetski writes:
>
> > These two i2c patches:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
> >
> > also would be nice to get in, although, they
> Of course, looking at the device tree, rapidio is a device, not a bus,
> because it does not have a device_type and it does not have any
> children
> of its own.
It's a device _of course_, but it's also a bus parent, since
it has a "#address-cells" not equal to zero (and, if this used
real OF,
a small update:
> 8245: 2.4.34
> 8237e: 2.6.21.1
I've tried the following setup:
multicast stream @8192 kbps, one process taking in and dumping the data
on each board [1].
a) 8245/2.4.34/e100: 2.3.43-k1, @400 MHz
b) 8245/2.6.17/e100: 2.3.43-k1 [2] @350 MHz
c) 8347e/2.6.21.1/gianfar @400 Mhz
c) X
On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
> Hi,
>
> Trying to change PCI IO window base for 52xx target I found that
> we are pretty much limited to a "0" offset only.
>
> pci_process_bridge_OF_ranges() will not process any IO range that has
> addresses set to anything else.
>
This one doesn't break 32-bit build by simply disabling irqtrace for
32-bit.
---
arch/powerpc/Kconfig|9 ++
arch/powerpc/kernel/Makefile|1
arch/powerpc/kernel/entry_64.S | 24 +
arch/powerpc/kernel/head_64.S | 54 +++
On Thursday 28 June 2007, Zhang Wei-r63237 wrote:
> > > +static __init int mpc86xx_of_device_init(void)
> > > +{
> > > + return of_platform_bus_probe(NULL, mpc86xx_of_ids, NULL);
> > > +}
> >
> > This will add any devices below the "fsl,rapidio-delta" device
> > as an of_device. Is that what
I have just pushed some more patches to the for-2.6.23 branch of
powerpc.git. There are still more to go, of course. :)
If anyone has a patch that was posted more than a couple of weeks ago
that they want to go in and that isn't in, it would be a good idea to
remind me (or Kumar for 8xxx stuff, o
From: Christian Krafft <[EMAIL PROTECTED]>
The pmi driver got simplified by removing support for multiple devices.
As there is no more than one pmi device per maschine, there is no need to
specify the device for listening and sending messages.
This way the caller (cbe_cpufreq) doesn't need to sca
Subject: cbe_cpufreq: fix build error
From: Christian Krafft <[EMAIL PROTECTED]>
The cbe_cpufreq driver should build without PMI
interface. The code that deals with PMI has been
#ifdef'ed out. This is not the optimal solution for now.
A later version of the cpufreq driver has been cleaned out
fro
On Thu, 2007-06-28 at 14:47 +0400, Vladislav Buzov wrote:
>
> I've looked through cache.S and see it contains a dcbf loop over 4Mb
> along with L2, L3 HW cache flushing. The comments says 'Due to a bug
> with the HW flush on some CPU revs, we occasionally experience data
> corruption...'. Could
Benjamin Herrenschmidt wrote:
>>>The erratum says nothing about any HW bugs with L3 cache flush. I just
>>>mentioned that the L3 cache flush operation described in MPC7450
>>>Reference manual is similar to the L2 using the L3 cache hardware
>>>flushing mechanism. For instance, it requires a com
Hi,
Trying to change PCI IO window base for 52xx target I found that
we are pretty much limited to a "0" offset only.
pci_process_bridge_OF_ranges() will not process any IO range that has
addresses set to anything else.
956: case 1: /* I/O space */
957: if (ranges[2]
On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > Here is an implementation to allow PReP systems to boot under the
> > arch/powerpc codebase, one of the few remaining platforms supported in
> > arch/ppc but not so far in arch/powerpc.
>
> > Too big for the list, the patch is
Here's a somewhat cleaned-up version that also works with preempt, still
64-bit only, still breaks 32-bit compile (I think, untested).
Works fine on my quad G5 and I've actually made a patch to lockdep to
support flagging my workqueue deadlock, that works too. And the XFS
report I had previously w
> A strict reading of the flattened device tree format defined in
> booting-without-of.txt does in fact require that all the tags defining
> properties for a node go before any definitions of subnodes, however
> it's not particularly emphasised. Although allowing intermingled
> properties and subn
>> + k) RapidIO
>> +
>> + Required properties:
>
> Should probably recommend a name for the node here, as well. "srio" I
> guess, from the example below.
I would prefer "rapidio", being more generic and more
readable. What would parallel RapidIO be, "prio"? No
thanks :-)
Segher
_
> +- #address-cells : Address representation for "rapidio" devices.
> + This field represents the number of cells needed to represent
> + the RapidIO address of the registers. For supporting more than
> + 32-bits RapidIO address, this field should be <2>.
> + See 1) above f
>>> This can't be right, and I suspect it will break any kernel access to
>>> the first 0x1000 bytes of the CCSR_BAR space. reg should actually
>>> describe the register space of the SOC. If ranges needs to specify
>>> that, too, they should be able to be redundant. But this looks like
>>> a big
- ranges = <0 f800 0010>;
- reg = ; // CCSRBAR 1M
+ ranges = <1000 f8001000 000ff000
+ reg = ; // CCSRBAR
>>
There is "BAR" in the name, so it is a movable range? Where
is the ba
> > The erratum says nothing about any HW bugs with L3 cache flush. I just
> > mentioned that the L3 cache flush operation described in MPC7450
> > Reference manual is similar to the L2 using the L3 cache hardware
> > flushing mechanism. For instance, it requires a complete L3 locking
> > befo
> Here is an implementation to allow PReP systems to boot under the
> arch/powerpc codebase, one of the few remaining platforms supported in
> arch/ppc but not so far in arch/powerpc.
> Too big for the list, the patch is at:
> http://ozlabs.org/~dgibson/home/prep-support
Too lazy to split t
> Commit 2e6016133755eb3cc44e8efab92573d23ed75888 split up
> arch/powerpc/boot/of.c so that some OF functions can be used on
> platforms that don't want to use the overall OF platform boot code.
> This is useful on things like PReP which can have an OF implementation
> which is useful for debugging
>>> First, I'm looking for a help and advice why the current _set_L2CR()
>>> implementation may not work for MPC7450 (namely 7448 with 1Mb L2
>>> cache
>>> installed). Is it a bug in _set_L2CR() or a hardware problem.
>>
>> I think that if anyone here could answer this straight
>> away, the sourc
>>> Note that 745x processors have L3 cache installed and may have the
>>> same
>>> problem requiring similar code modifications to use L3 hardware
>>> flushing
>>> mechanism.
>>
>> What does the erratum say?
>
> The erratum says nothing about any HW bugs with L3 cache flush. I just
> mentioned
30 matches
Mail list logo
