Dear Wolfram Sang,
In message 20091028152324.gc3...@pengutronix.de you wrote:
my MPC5121e (Rev2) has PVR/SVR: 0x8086_2010/0x8018_0020 (as mentioned in the
manual)
...
Does someone here have a Rev1 and can ultimately confirm and/or supply the
complete PVR/SVR for Rev1? Couldn't find any
* Paul Mackerras pau...@samba.org wrote:
Here is a series of patches from Anton Blanchard that implement some
nice tracing and perf_event features on powerpc. One of them is
generic perf_event stuff (adding software events for alignment faults
and instruction emulation faults).
Since
2009/10/29 Andrew Morton a...@linux-foundation.org:
Why were these patches resent? What changed?
Everybody who is going to review these patches has already reviewed
them and now they need to review them all again?
I resent the patches because the iommu-helper change was not correct
and I
On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
How can I get that pointer? Unfortunately I cannot simply
use
the
address of the flash. Is there some magical function call
that
gives me access to that portion of the memory space?
$ man 2
On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
How can I get that pointer? Unfortunately I cannot simply
use
the
address of the flash. Is there some magical function call
that
gives me access to that portion of the memory space?
On Thu, 2009-10-29 at 10:00 +0100, Joakim Tjernlund wrote:
On Tue, Oct 27, 2009 at 04:24:53PM -0600, Jonathan Haws wrote:
How can I get that pointer? Unfortunately I cannot simply
use
the
address of the flash. Is there some magical function call
that
On Tue, 27 Oct 2009, Benjamin Herrenschmidt wrote:
Kumar Gala (7):
powerpc: Add a Book-3E 64-bit defconfig
powerpc: Fix compile errors found by new ppc64e_defconfig
powerpc: Limit hugetlbfs support to PPC64 Book-3S machines
This is incredibly ugly. Why should the generic
On Tue, Oct 27, 2009 at 04:52:40PM -0600, Jonathan Haws wrote:
Will the device respond to 0x1234 being written at offset zero? You
generally have to poke these things pretty specifically in order to
get
them to go into command mode.
It should because that is the first data location
On Tue, Oct 27, 2009 at 04:52:40PM -0600, Jonathan Haws wrote:
Will the device respond to 0x1234 being written at offset zero?
You
generally have to poke these things pretty specifically in order
to
get
them to go into command mode.
It should because that is the first data
fsl_udc_release() calls dma_free_coherent() with an inappropriate
device passed to it, and since the device has no dma_ops, the following
oops pops up:
Kernel BUG at d103ce9c [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
...
NIP [d103ce9c]
Does O_DIRECT help? (you may need to define _GNU_SOURCE before
#include)
Nope, O_DIRECT did not help - in fact it caused the application to crash. Why
that is I am not sure, but it crashed.
___
Linuxppc-dev mailing list
Anyway, to make a long story short, I inserted an msync() after
each
assignment to the flash. This resolved my problem and I can now
program my flash.
Ouch, this was news to me too. Calling msync() after every write
kills performance.
We use mmap(/dev/mem) to access HW and havn't
On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote:
BUILD_BUG_ON used to use the optimizer to do code elimination or fail
at link time; it was changed to first the size of a negative array (a
nicer compile time error), then (in
8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
Jonathan,
On 10/28/2009 03:45 PM, Jonathan Haws wrote:
Looking through our notes and talking with the engineer
who was performing the tests, it was exactly that - MTD was waiting
for a signal that was produced differently than the hardware
ready signal. By simply polling the flash until
Looking through our notes and talking with the engineer
who was performing the tests, it was exactly that - MTD was waiting
for a signal that was produced differently than the hardware
ready signal. By simply polling the flash until the hardware
ready signal toggled we were able to get a
Does anyone test freescale evaluation board ads5121ev with linux-2.6.30?
I know that freescale had released a lot of patch for linux-2.6.24.6 and it
works great for me.
But testing 2.6.30 usb doesn't work.
Thanks in advance,
devel81
___
On Wed, Oct 14, 2009 at 11:41 PM, Vishnu Suresh vis...@freescale.com wrote:
[..]
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index b08403d..343e578 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -192,6 +192,8 @@ config CRYPTO_DEV_TALITOS
select
On Thu, 2009-10-29 at 09:14 -0700, Linus Torvalds wrote:
On Tue, 27 Oct 2009, Benjamin Herrenschmidt wrote:
Kumar Gala (7):
powerpc: Add a Book-3E 64-bit defconfig
powerpc: Fix compile errors found by new ppc64e_defconfig
powerpc: Limit hugetlbfs support to PPC64
On Sat, Oct 17, 2009 at 02:01:38PM +0200, Joakim Tjernlund wrote:
Joakim Tjernlund/Transmode wrote on 17/10/2009 13:24:18:
Rex Feany rfe...@mrv.com wrote on 16/10/2009 22:25:41:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Right, it is the pte table walk that is
Scott Wood scottw...@freescale.com wrote on 30/10/2009 01:12:28:
On Sat, Oct 17, 2009 at 02:01:38PM +0200, Joakim Tjernlund wrote:
Joakim Tjernlund/Transmode wrote on 17/10/2009 13:24:18:
Rex Feany rfe...@mrv.com wrote on 16/10/2009 22:25:41:
Thus spake Joakim Tjernlund
On Thu, Oct 29, 2009 at 01:27:18PM +1100, David Gibson wrote:
Oops, there was one big, nasty, stupid bug in this patch. Corrected
patch below.
Ugh. And another, which broke compile on all 32-bit platforms. I'm
running out of brown paper bags :(.
Cleanup management of kmem_caches for
On Thu, 2009-10-29 at 09:14 -0700, Linus Torvalds wrote:
On Tue, 27 Oct 2009, Benjamin Herrenschmidt wrote:
Kumar Gala (7):
powerpc: Add a Book-3E 64-bit defconfig
powerpc: Fix compile errors found by new ppc64e_defconfig
powerpc: Limit hugetlbfs support to PPC64
On Fri, Oct 30, 2009 at 02:39:22PM +1100, David Gibson wrote:
On Thu, Oct 29, 2009 at 01:27:18PM +1100, David Gibson wrote:
Oops, there was one big, nasty, stupid bug in this patch. Corrected
patch below.
Ugh. And another, which broke compile on all 32-bit platforms. I'm
running out of
This patch provides an extended_cede_processor() helper function
which takes the cede latency hint as an argument. This hint is to be passed
on to the hypervisor to cede to the corresponding state on platforms
which support it.
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Signed-off-by: Arun R
When a CPU is offlined on POWER currently, we call rtas_stop_self() and hand
the CPU back to the resource pool. This path is used for DLPAR which will
cause a change in the LPAR configuration which will be visible outside.
This patch changes the default state a CPU is put into when it is
Currently the cpu-allocation/deallocation process comprises of two steps:
- Set the indicators and to update the device tree with DLPAR node
information.
- Online/offline the allocated/deallocated CPU.
This is achieved by writing to the sysfs tunables probe during allocation
and release during
This patch got apply-broken by the fixes to the earlier patch in the
series. Here's the fixed version.
Cleanup initialization of hugepages on powerpc
This patch simplifies the logic used to initialize hugepages on
powerpc. The somewhat oddly named set_huge_psize() is renamed to
27 matches
Mail list logo
