2009/7/24 Richard Lary :
> Linas Vepstas wrote on 07/23/2009 07:44:33 AM:
>
>> 2009/7/15 Mike Mason :
>> > By default, EEH does what's known as a "hot reset" during error recovery
>> > of
>> > a PCI Express device. We've found a case where the device needs a
>> > "fundamental reset" to recover pr
Linas Vepstas wrote on 07/23/2009 07:44:33 AM:
> 2009/7/15 Mike Mason :
> > By default, EEH does what's known as a "hot reset" during error
recovery of
> > a PCI Express device. We've found a case where the device needs a
> > "fundamental reset" to recover properly. The current PCI error
reco
Since commit 8dfd0374be84793360db7fff2e635d2cd3bbcb21 ("MMC core: limit
minimum initialization frequency to 400kHz") MMC core checks for minimum
frequency, and that causes following messages flood when using eSDHC
controllers:
...
mmc0: Minimum clock frequency too high for identification mode
Actually, the support is already there, but it requires newer U-Boots
(to fill-in clock-frequency, and setup pin multiplexing).
Though, it appears that on RDB boards USBB pins aren't multiplexed
between USB and eSDHC (unlike MDS boards, where USB and eSDHC share
pctl and pwrfault pins).
So, for R
MPC8377E-WLAN are basically RDB boards except:
- RAM extended to 512 MB;
- NAND flash removed, NOR flash extended to 64 MB;
- Vitesse VSC7385 5-port switch removed, RTL8211B PHY added;
- Power management MCU removed;
- PCI slot removed, another mini-PCI slot added (IRQ routing changed);
- USB3300
On Fri, Jul 24, 2009 at 12:10:30PM -0400, Solomon Peachy wrote:
>On Fri, Jul 24, 2009 at 11:59:48AM -0400, Josh Boyer wrote:
>> Is this one different from the one you sent out yesterday? I plan to review
>> this support soon, but now I'm slightly confused :)
>
>Crap, sorry -- I didn't see it show
On Fri, Jul 24, 2009 at 11:59:48AM -0400, Josh Boyer wrote:
> Is this one different from the one you sent out yesterday? I plan to review
> this support soon, but now I'm slightly confused :)
Crap, sorry -- I didn't see it show up in the mailing list archives so I
thought it got dropped into the
On Fri, Jul 24, 2009 at 11:21:56AM -0400, Solomon Peachy wrote:
>This patch adds support for the ESTeem 195E Hotfoot SBC.
Is this one different from the one you sent out yesterday? I plan to review
this support soon, but now I'm slightly confused :)
josh
_
This patch adds support for the ESTeem 195E Hotfoot SBC.
I've been maintaining this out-of-tree for some time now for
older kernels, but recently I ported it to the new unified powerpc
tree with the intent of pushing it upstream.
The 195E boards use ancient versions of u-boot and a slightly mangl
Hello Ben,
Thank you for your reply.
> On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote:
>> I tried the latest 2.6.31-rc3-git3 (without any other patch).
>> However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
>> but the mesh_abort messages).
> Would it be possible for you t
> I'm not aware of a maintainer for the "generic nvram" driver. As
> mentioned in my other email, I'm fairly confident that this driver
> (/drivers/char/generic_nvram.c) is only used on PowerPC. I'm beginning
> to enter what is for me uncharted territory :-) How should I proceed?
> Are you hap
Benjamin Herrenschmidt wrote:
On Thu, 2009-07-02 at 17:12 +0100, Martyn Welch wrote:
The following series allows the generic NVRAM driver to access MMIO
based NVRAMs. In addition it enables support for NVRAMs of sizes
differing from those found on PowerPC Macs (providing a safe
fallback). Pat
This contains all the bits that didn't fit in previous patches :-) This
includes the actual exception handlers assembly, the changes to the
kernel entry, other misc bits and wiring it all up in Kconfig.
Signed-off-by: Benjamin Herrenschmidt
---
v2. Rebased due to changes in previous patches
ar
The base TLB support didn't include support for SPARSEMEM_VMEMMAP, though
we did carve out some virtual space for it, the necessary support code
wasn't there. This implements it by using 16M pages for now, though the
page size could easily be changed at runtime if necessary.
Signed-off-by: Benjami
This adds the TLB miss handler assembly, the low level TLB flush routines
along with the necessary hook for dealing with our virtual page tables
or indirect TLB entries that need to be flushes when PTE pages are freed.
There is currently no support for hugetlbfs
Signed-off-by: Benjamin Herrenschm
The definition for the global structure mmu_gathers, used by generic code,
is currently defined in multiple places not including anything used by
64-bit Book3E. This changes it by moving to one place common to all
processors.
Signed-off-by: Benjamin Herrenschmidt
---
v2. Fix issues due to change
This adds various fields in the PACA that are for use specifically
by Book3E processors, such as exception save areas, current pgd
pointer, special exceptions kernel stacks etc...
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/paca.h | 23 ---
arch/po
This adds various definitions and macros used by the exception and TLB
miss handling on 64-bit BookE
It also adds the definitions of the SPRGs used for various exception types
Signed-off-by: Benjamin Herrenschmidt
---
v2. Change __EXCEPTION_64E_H__ to _ASM_POWERPC_EXCEPTION_64E_H
arch/powerpc
This adds the PTE and pgtable format definitions, along with changes
to the kernel memory map and other definitions related to implementing
support for 64-bit Book3E. This also shields some asm-offset bits that
are currently only relevant on 32-bit
We also move the definition of the "linux" page s
This adds various SPRs defined on 64-bit BookE, along with changes
to the definition of the base MSR values to add the values needed
for 64-bit Book3E.
Signed-off-by: Benjamin Herrenschmidt
---
v2. Remove trailing whitespace and add comments about the EPCR bits
Don't break 8xx due to missing
That patch used to just add a hook to page table flushing but
pulling that string brought out a whole bunch of issues, so it
now does that and more:
- We now make the RCU batching of page freeing SMP only, as I
believe it was intended initially. We make a few more things compile
to nothing on !CO
Those definitions are currently declared extern in the .c file where
they are used, move them to a header file instead.
Signed-off-by: Benjamin Herrenschmidt
--
v2. Move more definitions to the header and update more call sites
arch/powerpc/include/asm/smp.h|9 +
arch/p
Currently, a single ifdef covers SLB related bits and more generic ppc64
related bits, split this in two separate ifdef's since 64-bit BookE will
need one but not the other.
Signed-off-by: Benjamin Herrenschmidt
Acked-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/process.c |2 ++
1 fi
Our 64-bit hash context handling has no init function, but 64-bit Book3E
will use the common mmu_context_nohash.c code which does, so define an
empty inline mmu_context_init() for 64-bit server and call it from
our 64-bit setup_arch()
Signed-off-by: Benjamin Herrenschmidt
Acked-by: Kumar Gala
--
We need to pass down whether the page is direct or indirect and we'll
need to pass the page size to _tlbil_va and _tlbivax_bcast
We also add a new low level _tlbil_pid_noind() which does a TLB flush
by PID but avoids flushing indirect entries if possible
This implements those new prototypes but d
The way I intend to use tophys/tovirt on 64-bit BookE is different
from the "trick" that we currently play for 32-bit BookE so change
the condition of definition of these macros to make it so.
Also, make sure we only use rfid and mtmsrd instead of rfi and mtmsr
for 64-bit server processors, not al
This adds some code to do early ioremap's using page tables instead of
bolting entries in the hash table. This will be used by the upcoming
64-bits BookE port.
The patch also changes the test for early vs. late ioremap to use
slab_is_available() instead of our old hackish mem_init_done.
Signed-of
This adds various additional bit definitions for various MMU related
SPRs used on Book3E.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/mmu-book3e.h | 168 --
1 file changed, 119 insertions(+), 49 deletions(-)
--- linux-work.orig/arch/power
This adds the opcode definitions to ppc-opcode.h for the two instructions
tlbivax and tlbsrx. as defined by Book3E 2.06
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/ppc-opcode.h |6 ++
1 file changed, 6 insertions(+)
--- linux-work.orig/arch/powerpc/include/asm/pp
The current "no hash" MMU context management code is written with
the assumption that one CPU == one TLB. This is not the case on
implementations that support HW multithreading, where several
linux CPUs can share the same TLB.
This adds some basic support for this to our context management
and our
enter_prom() used to save and restore registers such as CTR, XER etc..
which are volatile, or SRR0,1... which we don't care about. This
removes a bunch of useless code and while at it turns an mtmsrd into
an MTMSRD macro which will be useful to Book3E.
Signed-off-by: Benjamin Herrenschmidt
---
A misplaced #endif causes more definitions than intended to be
protected by #ifndef __ASSEMBLY__. This breaks upcoming 64-bit
BookE support patch when using 64k pages.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/pgtable-ppc64-64k.h |4 +---
1 file changed, 1 insertion
Here is a series of patches that implement some basic support
for 64-bit Book3E processors that comply to architecture 2.06.
There is no specific processor announced yet. The patches make
some shortcut which means they currently rely on an implementation
that supports MMU v2 with support for the "
On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote:
> I tried the latest 2.6.31-rc3-git3 (without any other patch).
> However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
> but the mesh_abort messages).
>
> Anybody knows what's going wrong, and how to fix it? I've read the
>
34 matches
Mail list logo
