[Removed linux-mtd from cc:]
[*] It seems to me the longtrail workaround code in prom_init.c is
incorrect though: it will match any node with name "memory" that
doesn't have a device_type?
It only matches on children of the root node,
Oh okay, I misread that then.
...No, I did not. prom_n
From: Michael Ellerman <[EMAIL PROTECTED]>
Subject: [PATCH] Fix missed hardware breakpoints across multiple threads
There is a bug in the powerpc DABR (data access breakpoint) handling,
which can result in us missing breakpoints if several threads are trying
to break on the same address.
The circ
[*] It seems to me the longtrail workaround code in prom_init.c is
incorrect though: it will match any node with name "memory" that
doesn't have a device_type?
It only matches on children of the root node,
Oh okay, I misread that then.
and it's that way
because the /memory node in the longtr
Adrian Bunk writes:
> Back in November 2005, the PPC_PREP bits under arch/powerpc/ were marked
> as BROKEN due to not being working.
>
> It doesn't seem to make much sense to keep this rudimentary support even
> longer.
NAK - I have some patches that get ARCH=powerpc working on at least
some P
Segher Boessenkool writes:
> It's still the (platform) probe code its responsibility to figure
> out what (if anything) to do with any device. And "main memory"
> is probed differently (via /chosen/memory, for example) anyway.
> Well, actually, Linux searches for all nodes with device_type "memor
On Fri, Mar 28, 2008 at 05:47:25PM -0600, Grant Likely wrote:
> On Fri, Mar 28, 2008 at 5:42 PM, Dale Farnsworth <[EMAIL PROTECTED]> wrote:
> > From: Dale Farnsworth <[EMAIL PROTECTED]>
> >
> > Follow the convention that compatible names are prefixed by the
> > vendor's stock ticker symbol. For
Hello PPC SMP MM experts,
mmu_hash_lock (arch/powerpc/mm/hash_low_32.S) is a
(non-standard) spin lock that protects the CPU MMU
hashing table. It exists and used only with SMP
configurations.
In some scenarios, the spin lock is taken when
interrupts are *enabled* causing kernel deadlock at
the ne
Back in November 2005, the PPC_PREP bits under arch/powerpc/ were marked
as BROKEN due to not being working.
It doesn't seem to make much sense to keep this rudimentary support even
longer.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig|5 +---
ar
For RAMs we
need something to indicate that it's memory but intended for
secondary
storage, not as main memory.
How it is intended to be used is not a property of the hardware, so
that information doesn't belong in the device tree at all. The Linux
platform code should handle this, I imagine.
On Fri, 2008-03-28 at 09:23 -0700, Stephen Neuendorffer wrote:
> Added literal mapping support if no device-tree support. Added
> CONFIG_OF to guard device-tree parts, since literal support works for
> arch=ppc.
>
> Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
I'll let others decide
On Fri, 2008-03-28 at 09:23 -0700, Stephen Neuendorffer wrote:
> Previously, dcr support was configured at compile time to either using
> MMIO or native dcr instructions. Although this works for most
> platforms, it fails on FPGA platforms:
>
> 1) Systems may include more than one dcr bus.
> 2)
hash_page_sync() takes and releases the low level mmu hash
lock in order to sync with other processors disposing of page
tables. Because that lock can be needed to service hash misses
triggered by interrupt handler, taking it must be done with
interrupts off. However, hash_page_sync() appear to be
On Sun, 2008-03-30 at 14:28 -0700, Gaash Hazan wrote:
> To verify the theory, hash_page_sync() was wrapped
> with interrupts disabled code and problem never
> occurred again. Of course this is temporary workaround
> as there are several places needed to be fixed.
It is definitely a bug in hash_pa
(reposting)
Hello PPC SMP MM experts,
mmu_hash_lock (arch/powerpc/mm/hash_low_32.S) is a
(non-standard) spin lock that protects the CPU MMU
hashing table. It exists and used only with SMP
configurations.
In some scenarios, the spin lock is taken when
interrupts are *enabled* causing kernel deadl
Segher Boessenkool writes:
> > For RAMs we
> > need something to indicate that it's memory but intended for secondary
> > storage, not as main memory.
>
> How it is intended to be used is not a property of the hardware, so
> that information doesn't belong in the device tree at all. The Linux
>
Compatible names should refer to a specific version of the hardware,
without wildcards. Change each instance of mv64x60 to mv64360, which
is the oldest version we currently support.
Actually, it's normal to have more than one compatible field, from
specific to generic. So it should make sense t
Could we agree on a name ? I'd like to submit a new patch.
For ROMs I think just plain "rom" should be sufficient.
Yes.
For RAMs we
need something to indicate that it's memory but intended for secondary
storage, not as main memory.
How it is intended to be used is not a property of the har
"memory-mapped-memory" perhaps :-)
Or, just "memory". Although that one might play havoc with some
I'd suggest "ram" and "rom" then. Luckily the device trees don't
contain binding for the real RAM chips yet. :-)
not-quite-correct main memory probing code.
You mean the there's par
Here is updated patch with new linux,brightness OF property (needed for
MPC8349E-mITX board -- pwr led should be "on" by default).
p.s. I tend to do documentation as a separate patch: I don't want this
patch to depend on the booting-without-of.txt -- it may produce
conflicts easily.
We need to
On Sat, Mar 29, 2008 at 04:59:42PM -0500, Olof Johansson wrote:
> On Fri, Mar 28, 2008 at 04:49:00PM -0700, Dale Farnsworth wrote:
> > From: Mark A. Greer <[EMAIL PROTECTED]>
> >
> > Remove several unused (or software config only) properties.
> > Rename marvel node to "soc". Technically, it's not
20 matches
Mail list logo
