Hi Mike,
On Tuesday 02 December 2008 00:28:23 Mike Ditto wrote:
Laurent Pinchart [EMAIL PROTECTED] wrote:
Transmission timeout after one second. The first TX buffer descriptor
status hasn't been modified by the CPM. The CPM state dump shows that
processing of
...
This sounds very
On Tue, 2008-12-02 at 11:50 +0100, Laurent Pinchart wrote:
Hi Joakim,
On Tuesday 02 December 2008 09:39:59 Joakim Tjernlund wrote:
On Mon, 2008-12-01 at 15:28 -0800, Mike Ditto wrote:
Laurent Pinchart [EMAIL PROTECTED] wrote:
Transmission timeout after one second. The first TX buffer
On Thu 2008-11-20 17:05:56, Trent Piepho wrote:
On Mon, 17 Nov 2008, Richard Purdie wrote:
On Fri, 2008-10-24 at 16:09 -0700, Trent Piepho wrote:
+ if (template-keep_state)
+ state = !!gpio_get_value(led_dat-gpio) ^ led_dat-active_low;
+ else
+ state =
Hi Joakim,
On Tuesday 02 December 2008 09:39:59 Joakim Tjernlund wrote:
On Mon, 2008-12-01 at 15:28 -0800, Mike Ditto wrote:
Laurent Pinchart [EMAIL PROTECTED] wrote:
Transmission timeout after one second. The first TX buffer descriptor
status hasn't been modified by the CPM. The CPM
On Mon, 2008-12-01 at 15:28 -0800, Mike Ditto wrote:
Laurent Pinchart [EMAIL PROTECTED] wrote:
Transmission timeout after one second. The first TX buffer descriptor
status
hasn't been modified by the CPM. The CPM state dump shows that processing
of
...
This sounds very similar to
Nowadays, do many (PowerPC) embedded devices already risk omitting
NOR flash and use a NAND device solely for booting and storing images ?
I'm talking about systems with 10 years life-cycle (so no
MP3-players nor medical systems but somewhere in between).
We have a MPC8313E-RDB and I know
Paul,
Can you update to -rc7 or greater. Also can we look at picking up
outstanding patches.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Tue, 2008-12-02 at 01:36 -0600, Kumar Gala wrote:
#define CPU_FTRS_E200 (CPU_FTR_USE_TB | CPU_FTR_SPE_COMP | \
CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \
- CPU_FTR_UNIFIED_ID_CACHE)
+ CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE)
#define
With the latest flush error completion patch we introduced modulus operation
to calculate the next index within a qmap. Based on comments from other
mailing lists we decided to optimize this operation by using an addition and
an if-statement instead of modulus, even though this is in error path.
Kumar Gala wrote:
On Dec 1, 2008, at 12:01 AM, Benjamin Herrenschmidt wrote:
We were missing the CPU_FTR_NOEXECUTE bit in our cputable for all
these processors. The result is that update_mmu_cache() would flush
the cache for all pages mapped to userspace which is totally
unnecessary on
On Tue, 2008-12-02 at 12:02 +1100, Michael Ellerman wrote:
On Mon, 2008-12-01 at 16:18 -0800, Carl Love wrote:
This patch adds the SPU event profiling support for the IBM Cell
processor to the list of available events. The opcontrol script
patches include a test to see if there is a new
In the CONFIG_SMP case the irq_choose_cpu() code was returning back
a logical cpu id not the physical id. We were writing that directly
into the HW register.
We need to be calling get_hard_smp_processor_id() so irq_choose_cpu()
always returns a physical cpu id.
Signed-off-by: Kumar Gala [EMAIL
Otherwise count 0 will fail
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
This was not tested. Is this how it should be fixed?
the locations where the failures occur are in the functions hv*_close, on:
vi drivers/char/hvcs.c +1251
vi drivers/char/hvsi.c +911
vi
On Tue, 2008-12-02 at 13:37 -0600, Kumar Gala wrote:
In the CONFIG_SMP case the irq_choose_cpu() code was returning back
a logical cpu id not the physical id. We were writing that directly
into the HW register.
We need to be calling get_hard_smp_processor_id() so irq_choose_cpu()
always
Disclaimer: I'm not running ppc these days
However, having no NOR flash means:
- NAND should be programmable via JTAG (BDI3000 doesn't support
this, Lauterbach/trace32 does)
My personal preference for bringing up a new board is placing u-boot
in RAM using the available information to
of_node_put is needed before discarding a value received from
of_find_node_by_name, eg in error handling code or when the device
node is no longer used.
The semantic match that catches the bug is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@r exists@
local idexpression struct
of_node_put is needed before discarding a value received from
of_find_node_by_name, eg in error handling code or when the device
node is no longer used.
The semantic match that catches the bug is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@r exists@
local idexpression struct
of_node_put is needed before discarding a value received from
of_find_node_by_name, eg in error handling code or when the device
node is no longer used.
The semantic match that catches the bug is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@r exists@
local idexpression struct
Hi,
Marvin wrote:
forward to a better place...
On Sunday 16 November 2008 23:44:50 Fabiano Manoel de Andrade wrote:
Hi I've compiled the latest version of linux kernel (2.6.27.6) in my
PS3 running debian and get a warning message listed here
Setting the system clock.
On Tue, 2 Dec 2008 14:34:46 +0100 Nicolas Palix [EMAIL PROTECTED] wrote:
of_node_put is needed before discarding a value received from
of_find_node_by_name, eg in error handling code or when the device
node is no longer used.
Signed-off-by: Nicolas Palix [EMAIL PROTECTED]
Signed-off-by:
On Dec 2, 2008, at 3:30 PM, Benjamin Herrenschmidt wrote:
On Tue, 2008-12-02 at 13:37 -0600, Kumar Gala wrote:
In the CONFIG_SMP case the irq_choose_cpu() code was returning back
a logical cpu id not the physical id. We were writing that directly
into the HW register.
We need to be calling
On Tue, 2 Dec 2008 14:38:55 +0100 Nicolas Palix [EMAIL PROTECTED] wrote:
of_node_put is needed before discarding a value received from
of_find_node_by_name, eg in error handling code or when the device
node is no longer used.
Signed-off-by: Nicolas Palix [EMAIL PROTECTED]
Signed-off-by:
Hi Nicolas,
Thanks for all this work.
I think this particular patch is also required against Linus' kernel (not
just linux-next).
On Tue, 2 Dec 2008 14:45:18 +0100 Nicolas Palix [EMAIL PROTECTED] wrote:
diff --git a/arch/powerpc/platforms/powermac/pci.c
Hi Nicolas,
On Wed, 3 Dec 2008 10:19:01 +1100 Stephen Rothwell [EMAIL PROTECTED] wrote:
I think this particular patch is also required against Linus' kernel (not
just linux-next).
In fact, I think all these patches can apply to Linus' current tree.
--
Cheers,
Stephen Rothwell
Benjamin Herrenschmidt wrote:
On Mon, 2008-12-01 at 15:30 -0600, Nathan Lynch wrote:
cpu_callin_map is used during secondary CPU bootstrap to notify the
waiting CPU that the new CPU is coming up. __cpu_up clears
cpu_callin_map[cpu] and then polls the same location, waiting for
Jocke,
The I2C_CHIP_ERRATA is mine and refers to mpc8xx, mpc860 in my case. The
driver was adapted by me some years ago in 2.4 and now someone has
ported it to 2.6 it seems.
Thanks for the background info. Any idea which particular errata it
was meant to fix? I took a quick look at MPC860
On Tue, 2 Dec 2008, Nathan Lynch wrote:
Apart from barriers (or lack thereof), the fact that __cpu_up gives up
after a more-or-less arbitrary period seems... well, arbitrary. If we
get to Processor X is stuck then something is seriously wrong:
there's either a kernel bug or a platform issue,
Removed __devexit from talitos_remove() since its also called from
talitos_probe().
WARNING: vmlinux.o(.text+0x28a008): Section mismatch in reference from the
function talitos_probe() to the function .devexit.text:talitos_remove()
The function talitos_probe() references a function in an exit
WARNING: vmlinux.o(.text+0x2aa): Section mismatch in reference from the
variable __secondary_start to the function .devinit.text:start_secondary()
The function __secondary_start() references
the function __devinit start_secondary().
start_secondary gets called by __secondary_start which is in
On Tue, 2008-12-02 at 20:16 -0600, Nathan Lynch wrote:
Apart from barriers (or lack thereof), the fact that __cpu_up gives up
after a more-or-less arbitrary period seems... well, arbitrary. If we
get to Processor X is stuck then something is seriously wrong:
there's either a kernel bug or a
Benjamin Herrenschmidt wrote:
On Tue, 2008-12-02 at 20:16 -0600, Nathan Lynch wrote:
Apart from barriers (or lack thereof), the fact that __cpu_up gives up
after a more-or-less arbitrary period seems... well, arbitrary. If we
get to Processor X is stuck then something is seriously wrong:
Kumar Gala wrote:
WARNING: vmlinux.o(.text+0x2aa): Section mismatch in reference from the
variable __secondary_start to the function .devinit.text:start_secondary()
The function __secondary_start() references
the function __devinit start_secondary().
start_secondary gets called by
On Wednesday 03 December 2008, Sean MacLennan wrote:
We use a 256M NAND on the PIKA Warp appliance and where unable to boot
u-boot from the NAND. It worked on a smaller 64M NAND.
Currently you need to define the page-size of the NAND used for booting (512
bytes vs. 2k). The 2k 4xx NAND booting
On Wed, 3 Dec 2008 06:48:57 +0100
Stefan Roese [EMAIL PROTECTED] wrote:
Currently you need to define the page-size of the NAND used for
booting (512 bytes vs. 2k). The 2k 4xx NAND booting support is was
done about 1/2 a year ago. So perhaps you tested this when this 2k
support was not
On Wed, 3 Dec 2008, Sean MacLennan wrote:
Yes, I would recommend to do it this way if possible. A small NOR for
U-Boot and environment and everything else in NAND. This makes things
much easier. But I understand that this is sometimes a problem with
space (2 FLASH chips) and costs.
Mainly
35 matches
Mail list logo
