On Oct 13, 2010, at 2:19 PM, Timur Tabi wrote:
The PowerPC Book-E watchdog driver (booke_wdt.c) defines a default timeout
value in the code based on whether it's a Freescale Book-E part of not.
Instead of having hard-coded values in the driver, make it a Kconfig option.
As newer chips gets
On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote:
Add some comments to make sRIO registers map better readable.
Signed-off-by: Shaohui Xie b21...@freescale.com
---
arch/powerpc/sysdev/fsl_rio.c | 65 +
1 files changed, 40 insertions(+), 25
On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote:
From: Li Yang le...@freescale.com
The access to HID1 register is only legitimate for e500 v1/v2 cores.
Also fixes magic number.
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Shaohui Xie b21...@freescale.com
---
On Oct 14, 2010, at 1:14 AM, Kumar Gala wrote:
On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote:
From: Li Yang le...@freescale.com
The access to HID1 register is only legitimate for e500 v1/v2 cores.
Also fixes magic number.
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by:
[ should fix the compile issue and pulled in 2 other minor patches ]
The following changes since commit 4108d9ba9091c55cfb968d42dd7dcae9a098b876:
powerpc/Makefiles: Change to new flag variables (2010-10-13 16:19:22 +1100)
are available in the git repository at:
-Original Message-
From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
Sent: Monday, September 20, 2010 23:37 PM
To: Zang Roy-R61911
Cc: linux-...@lists.infradead.org; dw...@infradead.org; dedeki...@gmail.com;
a...@linux-foundation.org; Lan Chunhe-B25806; Wood Scott-B07421; Gala
Subject: Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote:
From: Li Yang le...@freescale.com
The access to HID1 register is only legitimate for e500 v1/v2 cores.
Also fixes magic number.
Signed-off-by: Li Yang
Oct 13, 2010 at 8:00 PM, harninder@freescale.com wrote:
From: Harninder Rai harninder@freescale.com
It adds cache-sram support in P1/P2 QorIQ platforms as under:
* A small abstraction over powerpc's remote heap allocator
* Exports mpc85xx_cache_sram_alloc()/free() APIs
*
On Thu, Oct 14, 2010 at 11:56:15AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2010-10-13 at 09:16 -0400, Josh Boyer wrote:
On Tue, Sep 28, 2010 at 09:09:41AM -0400, Josh Boyer wrote:
Hi Ben,
A few small updates for the next branch. A new board/SoC from AMCC, and
some 476 changes from
On Oct 14, 2010, at 2:10 AM, Li Yang-R58472 wrote:
Subject: Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote:
From: Li Yang le...@freescale.com
The access to HID1 register is only legitimate for e500 v1/v2 cores.
Also
On Thu, Oct 14, 2010 at 8:25 AM, Kumar Gala ga...@kernel.crashing.org wrote:
+CONFIG_MATH_EMULATION=y
Don't these chips have hardware FP?
+CONFIG_E1000=y
+CONFIG_E1000E=y
Are you sure you want these on by default? We may use the E1000 cards
in-house, but I don't know if our customers do.
We get the following when building on ppc64 due to lack of include of
asm/io.h:
In file included from drivers/spi/spi_fsl_espi.c:25:0:
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function
'out_be32'
From 8435e5876fc3d629406c63b85bff82c25fc4bf75 Mon Sep 17 00:00:00 2001
From: Srikanth Krishnakar skris...@mvista.com
Date: Fri, 8 Oct 2010 18:07:06 +0530
Subject: [PATCH] RTC: rtc-cmos.c: Fix warning on PowerPC
The following warning is seen while compilation of PowerPC kernel:
CC
On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
We get the following when building on ppc64 due to lack of include of
asm/io.h:
Is this an immediate problem (merge for .36), or is it a linux-next thing?
g.
In file included from drivers/spi/spi_fsl_espi.c:25:0:
On Oct 14, 2010, at 9:12 AM, Grant Likely wrote:
On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
We get the following when building on ppc64 due to lack of include of
asm/io.h:
Is this an immediate problem (merge for .36), or is it a linux-next thing?
g.
.37 / next is fine.
On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
We get the following when building on ppc64 due to lack of include of
asm/io.h:
Applied.
g.
In file included from drivers/spi/spi_fsl_espi.c:25:0:
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
Hello,
(apologies for writing such a long e-mail, hope you can bother to read it all ☺
)
I have some difficulties with the eSDHC controller driver used on a MPC8308
evaluation board with kernel 2.6.36-rc7, and hope that some of you may be able
to help me with the debugging.
The driver is
Hi Grant,
On Wed, 15 Sep 2010 22:12:57 +0200
Anatolij Gustschin ag...@denx.de wrote:
Enabling the MPC8xxx GPIO driver with MPC512x GPIO extension
breaks touch screen support on this board since the GPIO
interrupt will be mapped to 8xxx GPIO irq host resulting in
a not requestable interrupt
On Thu, 14 Oct 2010 11:27:09 +0800
tiejun.chen tiejun.c...@windriver.com wrote:
tiejun.chen wrote:
Scott Wood wrote:
On Wed, 13 Oct 2010 09:17:01 +0800
tiejun.chen tiejun.c...@windriver.com wrote:
Scott Wood wrote:
The crash is happening somewhere in mpic_set_irq_type():
Agreed.
I may have a clue (you might not think so, but...):
I've configured the init thusly:
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN ,
0, 256,
MPIC );
Which, as I read the code, should disable the ISU stuff.
I've seeing this on
On Wed, 13 Oct 2010 20:09:02 -0700
Zang Roy-R61911 r61...@freescale.com wrote:
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
No need for = NULL.
Any harm? Or just personal habit or style? Can you explain about
why?
Besides not wanting superfluous code on general
On Thu, 14 Oct 2010 11:22:45 -0500
david.hag...@gmail.com wrote:
As I read the code:
/* Read feature register, calculate num CPUs and, for non-ISU
* MPICs, num sources as well. On ISU MPICs, sources are counted
* as ISUs are added
*/
greg_feature =
Hallelujah and Huzzah! I finally got my vector!
I back-ported the MPIC_BROKEN_FRR_NIRQS flag and code to our kernel, and
the kernel is now letting me have my vector! Now I can actually see if the
dang thing works!
THANK YOU EVERYBODY for putting up with me on this!
It comes from FRR[NIRQ]. It
These files undef DEBUG, but I think they were added before the ability
to control this from Kconfig. It's really annoying to only get some of
the debug messages!
Signed-off-by: Nishanth Aravamudan n...@us.ibm.com
---
Because the lpar and pci_dlpar code is pretty low-level verbose,
perhaps it
On Thu, 14 Oct 2010 12:20:55 -0500
david.hag...@gmail.com wrote:
It comes from FRR[NIRQ]. It seems that this chip takes a
less-than-useful interpretation of what that field means -- it gives
the actual number of sources, not the size of the sparsely populated
array.
Perhaps you might
On Oct 13, 2010, at 8:39 PM, Tabi Timur-B04825 wrote:
Kumar Gala wrote:
arch/powerpc/configs/mpc85xx_defconfig |3 +
arch/powerpc/configs/mpc85xx_smp_defconfig |3 +
arch/powerpc/platforms/85xx/p1022_ds.c | 213
+++-
3 files changed, 217
Mark, can you pick up this patch for us? Because it depends on
powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support, it
will break the build if we apply to powerpc-next.
You can grab the patch from http://patchwork.ozlabs.org/patch/67095/
On Thu, Oct 7, 2010 at 2:36 PM, Timur Tabi
Well, it was a coworker who added the workaround, so I assume we're
already aware of the issue.
The description of NIRQ is vague enough that it's hard to argue that
Linux's expectations of what it means are justified.
Well, I now can actually interrupt the PPC from my host processor!
Fix the warnings genereted by arch/powerpc/include/asm/immap_qe.h when
CONFIG_PHYS_ADDR_T_64BIT is defined:
immap_qe.h: In function 'immrbar_virt_to_phys':
immap_qe.h:472:8: warning: cast from pointer to integer of different size
immap_qe.h:472:24: warning: cast from pointer to integer of
Hi, all,
I am looking at the kernel source of 2.6.32. It appears to me that kernel stack
can be easily getting overflowed in case of fast interrupts. Here is my
observation, any comments? Thanks,
Let's assume task A triggers the fast interrupts, and task B was running when
the fast interrupt
divya dipra...@linux.vnet.ibm.com writes:
While running systemtap tests on the p6 machine , against the kernel
version 2.6.36-rc7-git3 Oops occured , here are the call trace
Did the oops happen during a systemtap module startup vs. operation
vs. shutdown? stap -V version string?
BUG:
On Thu, Oct 14, 2010 at 01:21:33PM -0500, Timur Tabi wrote:
Mark, can you pick up this patch for us? Because it depends on
powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support, it
will break the build if we apply to powerpc-next.
You can grab the patch from
On Thu, 2010-10-14 at 13:45 -0700, Rick Tao wrote:
Hi, all,
.../...
In the context of task A
a. NIP would point to the instruction after switch_to().
b. MSR_EE is enabled in the call trace (finish_task_switch
--finish_lock_switch--spin_unlock_irq)
c. do something that would trigger an
Hi,
I am trying to resubmit a patch for MSI support for ppc4xx devices. One of
the review feedback was not to use the bit map as it is only for the devices
which don’t have hard wired mapping between interrupt controller interrupts
and MSI number. For example intr-ctrl0 interrupt 20 goes to
On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote:
These files undef DEBUG, but I think they were added before the ability
to control this from Kconfig.
Perhaps. Some people, *cough*, have a tendency to merge those back in
again from time to time :)
It's really annoying to only
On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote:
On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote:
These files undef DEBUG, but I think they were added before the ability
to control this from Kconfig.
Perhaps. Some people, *cough*, have a tendency to merge those back in
On Thu, 2010-10-14 at 15:56 -0700, Tirumala Marri wrote:
Hi,
I am trying to resubmit a patch for MSI support for ppc4xx devices.
One of the review feedback was not to use the bit map as it is only
for the devices which don’t have hard wired mapping between interrupt
controller interrupts
On Thu, 2010-10-14 at 17:23 -0700, Nishanth Aravamudan wrote:
On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote:
On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote:
Because the lpar and pci_dlpar code is pretty low-level verbose,
perhaps it makes sense to add another
eeh and pci_dlpar #undef DEBUG, but I think they were added before the
ability to control this from Kconfig. It's really annoying to only get
some of the debug messages from these files. Leave the lpar.c #undef
alone as it produces so much output as to make the kernel unusable.
Update the Kconfig
Scott Wood wrote:
On Thu, 14 Oct 2010 11:27:09 +0800
tiejun.chen tiejun.c...@windriver.com wrote:
tiejun.chen wrote:
Scott Wood wrote:
On Wed, 13 Oct 2010 09:17:01 +0800
tiejun.chen tiejun.c...@windriver.com wrote:
Scott Wood wrote:
The crash is happening somewhere in
On 14 October 2010 12:48, Nishanth Aravamudan n...@us.ibm.com wrote:
These files undef DEBUG, but I think they were added before the ability
to control this from Kconfig.
Right.
It's really annoying to only get some of
the debug messages!
I don't get the big picture. Will there be some
On 14 October 2010 19:48, Nishanth Aravamudan n...@us.ibm.com wrote:
eeh and pci_dlpar #undef DEBUG, but I think they were added before the
ability to control this from Kconfig. It's really annoying to only get
some of the debug messages from these files. Leave the lpar.c #undef
alone as it
-Original Message-
From: Wood Scott-B07421
Sent: Friday, October 15, 2010 0:01 AM
To: Zang Roy-R61911
Cc: Wood Scott-B07421; Anton Vorontsov; linux-...@lists.infradead.org;
dw...@infradead.org; dedeki...@gmail.com; a...@linux-foundation.org;
Lan
Chunhe-B25806; Gala Kumar-B11780;
On Thu, 2010-10-14 at 20:54 -0500, Linas Vepstas wrote:
On 14 October 2010 19:48, Nishanth Aravamudan n...@us.ibm.com wrote:
eeh and pci_dlpar #undef DEBUG, but I think they were added before the
ability to control this from Kconfig. It's really annoying to only get
some of the debug
On Wed, 2010-10-13 at 11:52 +1100, Michael Neuling wrote:
In message 1286855108.14049.8.ca...@flin.austin.ibm.com you wrote:
icswx is a PowerPC co-processor instruction to send data to a
co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
the owning process are registered
-Original Message-
From: Wood Scott-B07421
Sent: Friday, October 15, 2010 0:03 AM
To: Zang Roy-R61911
Cc: Anton Vorontsov; linux-...@lists.infradead.org;
dw...@infradead.org;
dedeki...@gmail.com; a...@linux-foundation.org; Lan Chunhe-B25806;
Wood Scott-
B07421; Gala Kumar-B11780;
46 matches
Mail list logo
