On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>> @ -1125,7 +1128,10 @@ static struct of_device_id mpc85xx_mc_err_of_match[] =
>> {
>> { .compatible = "fsl,mpc8569-memory-controller", },
>> { .compatible = "fsl,mpc8572-memory-controller", },
>> { .compatible = "fsl,mpc8349-memory-c
On Thu, Oct 07, 2010 at 02:00:50AM -0500, Kumar Gala wrote:
>
> On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>
> >> @ -1125,7 +1128,10 @@ static struct of_device_id mpc85xx_mc_err_of_match[]
> >> = {
> >>{ .compatible = "fsl,mpc8569-memory-controller", },
> >>{ .compatible = "fsl,mpc857
On Thursday 07 October 2010 01:51:44 Benjamin Herrenschmidt wrote:
> On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> > UIC0 (32 IRQ sources) at DCR 0xc0
> > UIC1 (32 IRQ sources) at DCR 0xd0
>
> That looks bad. Your device-tree probably. Check the DCR bindings.
Why does this loo
On Wed, 2010-10-06 at 22:05 -0400, Albert Cahalan wrote:
> On Tue, Oct 5, 2010 at 11:31 AM, Segher Boessenkool
> wrote:
>
> > An OS shouldn't expect to have more than its own program image
> > RAM mapped, in general.
>
> Linux actually makes calls to allocate more. I'm thankful
> that Linux alwa
On Thu, 2010-10-07 at 09:32 +0200, Stefan Roese wrote:
> On Thursday 07 October 2010 01:51:44 Benjamin Herrenschmidt wrote:
> > On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> > > UIC0 (32 IRQ sources) at DCR 0xc0
> > > UIC1 (32 IRQ sources) at DCR 0xd0
> >
> > That looks bad. Yo
Dear Penguins,
SHORT:
There is a BUG in the current code design / Freescale P2020/85xx PCIe design
that prevent it from registering to the PCIe AER... or that I have missed
something :) ..
LESS SHORT:
I am in the process of a Freescale P2020 based board bring up. P2020 is
basically two 85xx p
On Oct 7, 2010, at 2:12 AM, Anton Vorontsov wrote:
> On Thu, Oct 07, 2010 at 02:00:50AM -0500, Kumar Gala wrote:
>>
>> On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>>
@ -1125,7 +1128,10 @@ static struct of_device_id mpc85xx_mc_err_of_match[]
= {
{ .compatible = "fsl,mpc8569-
Hi,
I try to run ath9k on a P1020RDB Freescale board.
I run into the problem similar to the Bug/Patch here:
http://patchwork.ozlabs.org/patch/52137/
I get irq 16: nobody cared
I tried to fix the dts file in the same manner but this does not help.
Currently I am using 2.6.33.7
Any hints? Any
Hi Bastian,
Bastiaan Nijkamp wrote:
It seems i forgot to include the relevant TLB entries in U-Boot and the
Device Tree in the e-mail, so here they are:
The TLB entries in U-Boot:
The kernel maintains the TLB, you must not set those in U-boot. It might
cause conflicts when the kernel choose
On Oct 7, 2010, at 7:30 AM, Eran Liberty wrote:
> Dear Penguins,
>
> SHORT:
> There is a BUG in the current code design / Freescale P2020/85xx PCIe design
> that prevent it from registering to the PCIe AER... or that I have missed
> something :) ..
>
> LESS SHORT:
> I am in the process of a F
On Fri, Oct 1, 2010 at 3:03 PM, Olof Johansson wrote:
> On Sat, Oct 02, 2010 at 06:51:55AM +1000, Benjamin Herrenschmidt wrote:
>> On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
>> > I'm not against it, and I agree some of the patches seem like good
>> > clean up. I'm concerned about this b
On Aug 31, 2010, at 6:24 PM, Matthew McClintock wrote:
> First we check to see if we are the first core booting up. This
> is accomplished by comparing the boot_cpuid with -1, if it is we
> assume this is the first core coming up.
>
> Secondly, we need to update the initial thread info structure
Reaching way back into the past
John, did you ever solve your issue here? Comments below.
On Tue, Feb 9, 2010 at 8:21 PM, John Williams
wrote:
> Hi,
>
> Perhaps this is my misunderstanding, but I'm looking at the bit of
> code in of_irq_map_raw() that iterates the interrupt-map DTS node,
>
The device tree for Freescale's P1022DS reference board is missing the node
for the ngPIXIS FPGA.
Signed-off-by: Timur Tabi
---
arch/powerpc/boot/dts/p1022ds.dts | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts
b/arch/powerpc/
The Freescale P1022DS has an on-chip video controller called the DIU, and a
driver for this device already exists. Update the platform file for the
P1022DS reference board to enable the driver, and update the defconfig for
Freescale MPC85xx boards to add the driver.
Signed-off-by: Timur Tabi
---
- Add Clock Power Management (CPM) node to dts tree
- Add idle-doze entry in CPM node
- Add standby entry in CPM node
- Add PM and SUSPEND support by default in defconfig
- Add NO_HZ and CONFIG_HIGH_RES_TIMERS support by
default in defconfig
Signed-off-by: Victor Gallardo
---
arch/powerpc/boot
- Add Clock Power Management (CPM) node to dts tree
- Add idle-doze entry in CPM node
- Add standby entry in CPM node
- Add PM and SUSPEND support by default in defconfig
- Remove UART2 and UART3 as they are unused, this will
CPM to put unused-units (UART2 and UART3) to sleep.
Signed-off-by: Vic
Add suspend/resume support for all 4xx compatible CPUs.
See /sys/power/state for available power states configured in.
Add two different idle states (idle-wait and idle-doze)
controlled via sysfs. Default is idle-wait.
cat /sys/devices/system/cpu/cpu0/idle
[wait] doze
To save addi
> On Tue, 21 Sep 2010 17:37:15 -0400
> The MPIC interrupt numberspace in the device tree (which is not
> virtual; it is a private numberspace to MPIC) is based on the offset of
> the registers for that interrupt source. External interrupts start at
> zero (which is valid), internal at 16, and speci
On Thu, 7 Oct 2010 15:12:26 -0500
wrote:
> > On Tue, 21 Sep 2010 17:37:15 -0400
> > The MPIC interrupt numberspace in the device tree (which is not
> > virtual; it is a private numberspace to MPIC) is based on the offset of
> > the registers for that interrupt source. External interrupts start at
> On Thu, 7 Oct 2010 15:12:26 -0500.
>
> BTW, the MSIs are already described in an msi node in the device tree.
As far as I can tell, ONLY in root complex mode, not in endpoint mode,
which is what I am working with.
What I want is a means by which the system root complex can generate one
or more i
Hi Greg:
We have obtained GPL 2 only header from Synopsis. We have also identified all
parties that contributed to the code base and contacted them regarding
license change.
Any party that we could not reach, we will remove the patch from the submission.
Let me know if this is sufficient for resub
On Thu, Oct 07, 2010 at 03:01:33PM -0700, Feng Kan wrote:
> Hi Greg:
>
> We have obtained GPL 2 only header from Synopsis. We have also identified all
> parties that contributed to the code base and contacted them regarding
> license change.
> Any party that we could not reach, we will remove the
On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie
>
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree
On Tue, 2010-10-05 at 10:18 -0700, Anirban Chakraborty wrote:
> Hi All,
>
> I am trying to test qlcnic driver (for 10Gb QLogic network adapter) on a
> Power 6 system
> (IBM P 520, System type 8203) with upstream kernel and I do see that the
> kernel is
> not able to allocate any MSI-X vectors.
On Mon, 2010-10-04 at 13:24 +0200, Jean-Mickael Guerin wrote:
> Hello,
> I'm stepping into ppc world and I'd like to know how to read this call trace,
> I enabled debug options but I'm not able to track the origin of this bug, I
> mean
> what happens before handle_page_fault():
>
> Unable to hand
On Tue, 2010-10-05 at 07:21 +0200, Jean-Mickael Guerin wrote:
> SLUB is turned on, and the oops does not seem to happen when SLAB replaces
> SLUB.
> I just got lucky with SLAB, or does it sound familiar on ppc?
Nope, they should both work fine. Try enabling SLAB_DEBUG or SLUB_DEBUG
maybe ? You mi
On Mon, 2010-10-04 at 15:37 -0500, Scott Wood wrote:
> [Updated with Nick's current address; previous one bounced]
>
> On Mon, 4 Oct 2010 15:22:59 -0500
> Scott Wood wrote:
>
> > I'm seeing the in_atomic() check in page_cache_get_speculative()
> > (linux/pagemap.h:138) fail when running e500 KVM
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Thursday, September 30, 2010 6:46 PM
> To: linuxppc-...@ozlabs.org; spi-devel-gene...@lists.sourceforge.net; linux-
> m...@lists.infradead.org; Hu Mingkai-B21284
> Cc: Gala Kumar-B11780; Zang Roy-R61911; Hu M
> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Thursday, September 30, 2010 11:07 PM
> To: Grant Likely
> Cc: David Brownell; linuxppc-...@ozlabs.org; Hu Mingkai-B21284; linux-
> m...@lists.infradead.org; Gala Kumar-B11780; spi-devel-
> gene...@lists.
> -Original Message-
> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
> Likely
> Sent: Friday, October 01, 2010 5:35 AM
> To: Hu Mingkai-B21284
> Cc: linuxppc-...@ozlabs.org; spi-devel-gene...@lists.sourceforge.net; linux-
> m...@lists.infradead.org; Gala Kuma
I seem to be running into a problem getting a Mellanox Infinihost
Infiniband adapter working on my IBM p550 (a 9113-550). I'm using
Debian squeeze, and tried upgrading to the 2.6.35.7 kernel without any
help.
I get the following messages in dmesg:
[4.972548] ib_mthca: Mellanox InfiniBand
I seem to be running into a problem getting a Mellanox Infinihost
Infiniband adapter working on my IBM p550 (a 9113-550). I'm using
Debian squeeze, and tried upgrading to the 2.6.35.7 kernel without any
help.
I get the following messages in dmesg:
[4.972548] ib_mthca: Mellanox InfiniBand
On Thu, 2010-10-07 at 23:24 -0400, Patrick Finnegan wrote:
> I seem to be running into a problem getting a Mellanox Infinihost
> Infiniband adapter working on my IBM p550 (a 9113-550). I'm using
> Debian squeeze, and tried upgrading to the 2.6.35.7 kernel without any
> help.
>
> I get the fol
> Ok, so from what I can tell, the driver is unhappy because either BAR 0
> hasn't been assigned a memory resource or the size doesn't match what
> the driver expects.
>
Ooops, accidentally sent too quickly...
>From your OF log I see:
reg 00c1
On Oct 7, 2010, at 9:15 PM, Hu Mingkai-B21284 wrote:
Yes, I agree with David on this. If large transfers don't work,
then it is the SPI master driver that is buggy.
>>>
>>> By the way, does this fix your problem?
>>>
>>> https://patchwork.kernel.org/patch/184752/
>>
>> It shouldn't.
> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Friday, October 01, 2010 7:22 PM
> To: Hu Mingkai-B21284
> Cc: linuxppc-...@ozlabs.org; spi-devel-gene...@lists.sourceforge.net; linux-
> m...@lists.infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH
> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Friday, October 01, 2010 7:22 PM
> To: Hu Mingkai-B21284
> Cc: linuxppc-...@ozlabs.org; spi-devel-gene...@lists.sourceforge.net; linux-
> m...@lists.infradead.org; Gala Kumar-B11780; Zang Roy-R61911
> Sub
38 matches
Mail list logo
