Sachin Sant wrote:
Today's next failed to boot on a powerpc box
(Power6 blade IBM,7998-61X) with following recursive locking message.
=
[ INFO: possible recursive locking detected ]
2.6.29-next-20090325 #1
After bisecting the failure seems
> >Signed-off-by: Josh Boyer
>
> Ben, this should look familiar. It's based on your current -next branch.
>
> If you agree, I can send it to the -stable team for .27, .28 and .29.
Patch looks good. I'll review more closely tomorrow morning and put it
in my -next branch, which I'll then ask Li
On Wed, Mar 25, 2009 at 2:48 PM, Wolfgang Grandegger
wrote:
> Grant Likely wrote:
>> For the chip offset, it's not clear what the meaning is. First, does
>> the UPM controller support access of multiple chips simultaneously?
>
> The offset drives the corresponding address lines, which are used t
Dear Mr. Brian Behlendorf,
I have read your post about improving module load time in the following
site and
Found it very helpful.
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
I have the similar issue with Linux 2.6.14 for PPC platform. Since I
cannot find
the original patch f
Hi All,
I'll try to be as accurate as I can.
Yesterday I downloaded ELDK 4.2 from DENX site and Installed it.
I want to build a Xenomai enabled kernel.
I saw that my kernel is 2.6.24-xenomai and that's what I'm trying to build.
My target is freescale quicc II (MPC8248) and I want to start by build
On Wed, 2009-03-25 at 11:39 -0500, Scott Wood wrote:
> Simon Kagstrom wrote:
> > There are no other versions yet, but I suppose there will be (it's
> > implemented in a FPGA after all!). So what is the general handling of
> > versions, should it be something like
> >
> > compatible = "ericsson,i
On Mon, 2009-03-23 at 23:53 +0300, Anton Vorontsov wrote:
> It took me approx. 4 hours to factor out the code and make a
> proof-of-concept FDT support for a little-endian ARM platform. ;-)
> (The device tree was only describing a cpu and a nor flash, though.
> No support for interrupt- and gpio-co
David Miller wrote on 25/03/2009 22:40:41:
>
> From: Eric Dumazet
> Date: Wed, 25 Mar 2009 15:04:26 +0100
>
> > Joakim Tjernlund a écrit :
> > > + /* Tx event processing */
> > > + spin_lock(&ugeth->lock);
> > > + for (i = 0; i < ug_info->numQueuesTx; i++) {
> > > + ucc_geth_tx(ugeth
From: Joakim Tjernlund
Date: Wed, 25 Mar 2009 16:16:24 +0100
> UCC_GETH_DEV_WEIGHT needs to be a bit bigger than the number of RX
> HW buffers avaliable, otherwise one won't be able to drain the whole
> queue in one go. Changing weight to something bigger made a big
> difference.
You're not supp
From: Eric Dumazet
Date: Wed, 25 Mar 2009 15:04:26 +0100
> Joakim Tjernlund a écrit :
> > + /* Tx event processing */
> > + spin_lock(&ugeth->lock);
> > + for (i = 0; i < ug_info->numQueuesTx; i++) {
> > + ucc_geth_tx(ugeth->dev, i);
> > + }
> > + spin_unlock(&ugeth->lock);
>
From: Joakim Tjernlund
Date: Wed, 25 Mar 2009 14:30:49 +0100
> >From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund
> Date: Tue, 24 Mar 2009 10:19:27 +0100
> Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> Also increase NAPI w
Grant Likely wrote:
> (cc'ing devicetree-discuss)
>
> On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger
> wrote:
>> This patch adds documentation for the new NAND FSL UPM bindings for:
>>
>> NAND: FSL-UPM: add multi chip support
>> NAND: FSL-UPM: Add wait flags to support board/chip specifi
I was validating some code dealing with /proc//maps on 2.6.29 and
was surprised when it failed. It turns out that at least on my ppc64 G5
machine the offset value for the last entry is strange--it shows up as a
64-bit value even though the process itself is only 32-bit.
This behaviour also
Grant Likely wrote:
> (cc'ing the devicetree-discuss mailing list)
>
> On Wed, Mar 18, 2009 at 1:56 PM, Wolfgang Grandegger
> wrote:
>> The I2C driver for the MPC still uses a fixed clock divider hard-coded
>> into the driver. This issue has already been discussed twice:
>>
>> http://www.mail-a
On Wed 2009-03-25 11:31:57, Scott Wood wrote:
> Pavel Machek wrote:
>>> Pavel, what's the preferred way for current PM sub-system?
>>
>> If you have single sleep state, use "mem" > /sys/power/state.
>>
>> If you have two, use mem and standby. Do you have more?
>
> Some of our chips have two, and s
(cc'ing the devicetree-discuss mailing list)
On Wed, Mar 18, 2009 at 1:56 PM, Wolfgang Grandegger
wrote:
> The I2C driver for the MPC still uses a fixed clock divider hard-coded
> into the driver. This issue has already been discussed twice:
>
> http://www.mail-archive.com/linuxppc-dev@ozlabs.o
Anton Vorontsov wrote on 25/03/2009 15:25:40:
> On Wed, Mar 25, 2009 at 02:30:49PM +0100, Joakim Tjernlund wrote:
> > >>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00
2001
> > From: Joakim Tjernlund
> > Date: Tue, 24 Mar 2009 10:19:27 +0100
> > Subject: [PATCH] ucc_geth: Move
(cc'ing devicetree-discuss)
On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger
wrote:
> This patch adds documentation for the new NAND FSL UPM bindings for:
>
> NAND: FSL-UPM: add multi chip support
> NAND: FSL-UPM: Add wait flags to support board/chip specific delays
>
> Signed-off-by: Wolf
On Wed, Mar 25, 2009 at 7:43 AM, Wolfgang Grandegger
wrote:
> Grant Likely wrote:
>> On Wed, Mar 25, 2009 at 7:31 AM, Grant Likely
>> wrote:
>>> On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger
>>> wrote:
This patch adds support for multi-chip NAND devices to the FSL-UPM
driver.
Simon Kagstrom wrote:
There are no other versions yet, but I suppose there will be (it's
implemented in a FPGA after all!). So what is the general handling of
versions, should it be something like
compatible = "ericsson,isf-pic", "ericsson,isf-pic-v2"
etc if we'd make new revisions of the dev
Pavel Machek wrote:
Pavel, what's the preferred way for current PM sub-system?
If you have single sleep state, use "mem" > /sys/power/state.
If you have two, use mem and standby. Do you have more?
Some of our chips have two, and some have one. However, the sleep state
of the chips that h
On Wed, Mar 25, 2009 at 12:23:59PM -0400, Josh Boyer wrote:
>On powerpc64 machines running 32-bit userspace, we can get garbage bits in the
>stack pointer passed into the kernel. Most places handle this correctly, but
>the signal handling code uses the passed value directly for allocating signal
>
On powerpc64 machines running 32-bit userspace, we can get garbage bits in the
stack pointer passed into the kernel. Most places handle this correctly, but
the signal handling code uses the passed value directly for allocating signal
stack frames.
This fixes the issue by introducing a get_clean_s
Hello,
I am working with the xilinx ML403 evaluation board which has a
Virtex4 FPGA and one powerpc405 processor is integrated.
I am trying to develop a linux driver for FSL link for powerpc405. I
developed one first version (with the referce of the microblaze fsl
driver developped by Mr. John Wi
Hi Anton,
Anton Vorontsov wrote:
> Hi Wolfgang,
>
> On Wed, Mar 25, 2009 at 11:08:18AM +0100, Wolfgang Grandegger wrote:
>> This patch adds support for multi-chip NAND devices to the FSL-UPM
>> driver. This requires support for multiple GPIOs for the RNB pins.
>> The NAND chips are selected throu
Anton Vorontsov wrote on 25/03/2009 15:25:40:
>
> On Wed, Mar 25, 2009 at 02:30:49PM +0100, Joakim Tjernlund wrote:
> > >>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00
2001
> > From: Joakim Tjernlund
> > Date: Tue, 24 Mar 2009 10:19:27 +0100
> > Subject: [PATCH] ucc_geth: Mo
Eric Dumazet wrote on 25/03/2009 15:04:26:
> Joakim Tjernlund a écrit :
> >>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
> > From: Joakim Tjernlund
> > Date: Tue, 24 Mar 2009 10:19:27 +0100
> > Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> > A
On Wed, Mar 25, 2009 at 11:08:20AM +0100, Wolfgang Grandegger wrote:
> This patch adds documentation for the new NAND FSL UPM bindings for:
>
> NAND: FSL-UPM: add multi chip support
> NAND: FSL-UPM: Add wait flags to support board/chip specific delays
>
> Signed-off-by: Wolfgang Grandegger
> -
On Wed, Mar 25, 2009 at 11:08:19AM +0100, Wolfgang Grandegger wrote:
> The NAND flash on the TQM8548_BE modules requires a short delay after
> running the UPM pattern. The TQM8548_BE requires a further short delay
> after writing out a buffer. Normally the R/B pin should be checked, but
> it's not
Hi Wolfgang,
On Wed, Mar 25, 2009 at 11:08:18AM +0100, Wolfgang Grandegger wrote:
> This patch adds support for multi-chip NAND devices to the FSL-UPM
> driver. This requires support for multiple GPIOs for the RNB pins.
> The NAND chips are selected through address lines defined by the
> FDT prope
Hi Scott!
Thanks a lot for all your help with the device tree! As you suspected,
I'm writing for a fairly old kernel (2.6.21, WindRiver). I know, I know.
On Tue, 24 Mar 2009 10:55:45 -0500
Scott Wood wrote:
> Add compatible = "simple-bus". This lets children of this node be probed
> by of_plat
On Wed, Mar 25, 2009 at 02:30:49PM +0100, Joakim Tjernlund wrote:
> >>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund
> Date: Tue, 24 Mar 2009 10:19:27 +0100
> Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> Also increase NA
Joakim Tjernlund a écrit :
>>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund
> Date: Tue, 24 Mar 2009 10:19:27 +0100
> Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> Also increase NAPI weight somewhat.
> This will make the
On Wednesday 25 March 2009, Grant Likely wrote:
> >> This case really does sound like a driver bug and that the existing
> >> cfi-flash binding is sufficient to describe the hardware. IIUC, when
> >> all the flash chips are of the same type the physmap_of driver should
> >> be smart enough to dete
On Tue, Mar 24, 2009 at 8:12 PM, Kumar Gala wrote:
>
> On Mar 24, 2009, at 4:13 PM, Johns Daniel wrote:
>
>>
>> On Tue, Mar 24, 2009 at 3:54 PM, Kumar Gala
>> wrote:
>>
>> On Mar 24, 2009, at 3:24 PM, Johns Daniel wrote:
>>
>> Could somebody please explain the declaration of the PCIe interrupts
Grant Likely wrote:
> On Wed, Mar 25, 2009 at 7:31 AM, Grant Likely
> wrote:
>> On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger
>> wrote:
>>> This patch adds support for multi-chip NAND devices to the FSL-UPM
>>> driver. This requires support for multiple GPIOs for the RNB pins.
>>> The NA
On Wed, Mar 25, 2009 at 7:31 AM, Grant Likely wrote:
> On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger
> wrote:
>> This patch adds support for multi-chip NAND devices to the FSL-UPM
>> driver. This requires support for multiple GPIOs for the RNB pins.
>> The NAND chips are selected through
On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger
wrote:
> This patch adds support for multi-chip NAND devices to the FSL-UPM
> driver. This requires support for multiple GPIOs for the RNB pins.
> The NAND chips are selected through address lines defined by the
> FDT property "chip-offset".
>
>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund
Date: Tue, 24 Mar 2009 10:19:27 +0100
Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
Also increase NAPI weight somewhat.
This will make the system alot more responsive while
pi
On Wed, Mar 25, 2009 at 3:35 AM, Stefan Roese wrote:
> On Tuesday 24 March 2009, Grant Likely wrote:
>> > OK, in the example above such a spanning partition is not so likely. But
>> > think about my original example, the Intel P30 with two different cfi
>> > compatible chips on one die. Here a par
> +static void fun_select_chip(struct mtd_info *mtd, int chip_nr)
> +{
> + struct nand_chip *chip = mtd->priv;
> + struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
> +
> + if (chip_nr == -1) {
> + chip->cmd_ctrl(mtd, NAND_CMD_NONE, 0 |
> NAND_CTRL_CHANGE);
> +
On Wed 2009-03-25 18:42:41, Li Yang wrote:
> On Tue, Mar 24, 2009 at 12:54 AM, Scott Wood wrote:
> > On Sun, Mar 22, 2009 at 10:45:23PM -0700, Li Yang-R58472 wrote:
> >> > I don't think so, in this case. The user is not asking for
> >> > "sleep" or deep sleep"; they are asking for a power state
>
Singh, Vimal wrote:
>> +static void fun_select_chip(struct mtd_info *mtd, int chip_nr)
>> +{
>> + struct nand_chip *chip = mtd->priv;
>> + struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
>> +
>> + if (chip_nr == -1) {
>> + chip->cmd_ctrl(mtd, NAND_CMD_NONE, 0 |
>>
On Tue, Mar 24, 2009 at 12:54 AM, Scott Wood wrote:
> On Sun, Mar 22, 2009 at 10:45:23PM -0700, Li Yang-R58472 wrote:
>> > I don't think so, in this case. The user is not asking for
>> > "sleep" or deep sleep"; they are asking for a power state
>> > that meets the definition of "standby" (which s
This patch adds support for multi-chip NAND devices to the FSL-UPM
driver. This requires support for multiple GPIOs for the RNB pins.
The NAND chips are selected through address lines defined by the
FDT property "chip-offset".
Signed-off-by: Wolfgang Grandegger
---
arch/powerpc/sysdev/fsl_lbc.c
This patch adds multi-chip support for the Micron MT29F8G08FAB NAND
flash memory on the TQM8548 modules.
Signed-off-by: Wolfgang Grandegger
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts |6 +-
arch/powerpc/boot/dts/tqm8548.dts |6 +-
2 files changed, 10 insertions(+), 2
The NAND flash on the TQM8548_BE modules requires a short delay after
running the UPM pattern. The TQM8548_BE requires a further short delay
after writing out a buffer. Normally the R/B pin should be checked, but
it's not connected on the TQM8548_BE. The existing driver uses similar
fixed delay poi
This patch adds documentation for the new NAND FSL UPM bindings for:
NAND: FSL-UPM: add multi chip support
NAND: FSL-UPM: Add wait flags to support board/chip specific delays
Signed-off-by: Wolfgang Grandegger
---
.../powerpc/dts-bindings/fsl/upm-nand.txt | 39 +++-
This is my third version of the patch series adding generic support
for multi-chip NAND devices to the FSL-UPM driver and support for
the Micron MT29F8G08FAB NAND flash memory on the TQM8548 modules.
It addresses the issues reported on the mailing list, e.g. the new
bindings are now documented as w
On Tuesday 24 March 2009, Grant Likely wrote:
> > OK, in the example above such a spanning partition is not so likely. But
> > think about my original example, the Intel P30 with two different cfi
> > compatible chips on one die. Here a partition spanning over both devices
> > is very likely.
>
> I
Can you post your lspci -vvv dump .
From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org on behalf of rizwan ahmad
Sent: Mon 3/23/2009 1:07 AM
To: linuxppc-dev@ozlabs.org
Subject: sata device failed to IDENTIFY...
BM/AMCC PowerPC 440 GR Rev. B
Board: AMCC Y
51 matches
Mail list logo