On Wed, May 20, 2009 at 7:48 PM, patel rajendra wrote:
> Hi Members of linuxppc,
[...]
> What I understood from above message is that there is a problem in
> registering the device in function xilinx_ml403_led_setup( ).
>
> Anyone can help me out to solve this problem?
You really need to post you
On Wed, May 20, 2009 at 6:46 PM, Wolfram Sang wrote:
>> > + name = of_get_property(op->node, "name", NULL);
>> > + if (!name) {
>> > + ret = -ENOENT;
>> > + dev_dbg(&op->dev, "could not get node name\n");
>> > + goto bad1;
>> > + }
>
> Ca
Hi Members of linuxppc,
I'm working on XUPV2P board with Virtex II Pro FPGA device.
I written a kernel module for LED device. I got that module run successfuly on
ML403 board having Virtex 4 FPGA.I have not make any change in my source code,
because I don't feel any change is required.
On X
Hi,
my processor is MPC8247, on Linux 2.6.11
in MPC8247 manual reference, the interrupt of DMA unit belonged PCI bridge.
that is different from SDMA and IDMA. through i do not know what 's the
different. heard SDMA is used to transfer between CPM and 60x. DMA is used
to transfer between 60x bus
thank you dave for your reply
my processor is MPC8247, on Linux 2.6.11
in MPC8247 manual reference, the interrupt of DMA unit belonged PCI bridge.
that is different from SDMA and IDMA. through i do not know what 's the
different. heard SDMA is used to transfer between CPM and 60x. DMA is used
Hello Grant,
as I am just working on V2 (fixed even some additional things), two more
questions came up:
On Tue, May 19, 2009 at 08:57:15AM -0600, Grant Likely wrote:
> On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang wrote:
> > Create an of-aware driver using the now exported generic functions fr
With regards to your Oops: we sometimes find that, although a switch may
report a port being active, whenever
we try to discover what lies behind it, transfer errors occur that are
non-recoverable.
As a solution, on Freescale MPC8641D, we use a DMA transfer to perform a
simple MAINT read on a new
All,
First off, we turned SPE off completely in our build - so we
could debug a much deeper problem that seems to be occurring
in our application (before we try to find a potential test
case for corruption of GPR registers).
We have had this problem for 3 weeks, and just recently have
come do
Add a node for the i2c eeprom and delete the superflous gpio-example.
Signed-off-by: Wolfram Sang
Cc: Grant Likely
Cc: linuxppc-dev@ozlabs.org
---
Changes since V1: use vendor name in eeprom-node
arch/powerpc/boot/dts/pcm030.dts | 26 --
1 files changed, 4 insertions
On Wed, 2009-05-20 at 15:41 -0700, David Miller wrote:
> This is exactly what sparc64 does as well, I took the powerpc code. :)
>
> It also avoids a bunch of bugs that get unearthed as a result of
> scanning the entire hierarchy with PCI config access "pokes". Some
> PCI controllers hang when cer
From: Benjamin Herrenschmidt
Date: Thu, 21 May 2009 07:59:42 +1000
> On ppc64, we have code that can "create" the pci_bus & pci_dev hierarchy
> from the OF tree (avoiding the config space probing entirely). This is
> very efficient and has some advantages such as avoiding touching the
> BARs for
On Wed, May 20, 2009 at 3:59 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2009-05-20 at 14:06 -0600, Grant Likely wrote:
>> On Wed, May 20, 2009 at 1:24 PM, David Miller wrote:
>> >> What do you mean by fully resolve ? IE. The issue above is specific to
>> >> IO space, which you can resolve both a
On Wed, 2009-05-20 at 14:06 -0600, Grant Likely wrote:
> On Wed, May 20, 2009 at 1:24 PM, David Miller wrote:
> >> What do you mean by fully resolve ? IE. The issue above is specific to
> >> IO space, which you can resolve both as MMIO, or as "IO" which in linux
> >> means going through the specia
> I mean that all OF devices have fully resolved MMIO resources. So
> very early serial devices that sit in I/O space on sparc64 end
> up being OF device drivers. See for example, drivers/net/sunsu.c
> which is simply a 8250 chip that sits behind Sun's I/O space bus
> that sits on PCI and provid
On Wed, May 20, 2009 at 1:24 PM, David Miller wrote:
>> What do you mean by fully resolve ? IE. The issue above is specific to
>> IO space, which you can resolve both as MMIO, or as "IO" which in linux
>> means going through the special mapping for IO which allows the use of
>> the inX/outX instru
> For the test I created a "pattern file" which is filled with the unsigned
> long 0x0055aaff. Using the Abatron BDI3000, I can write the pattern file to
> the ram and re-read it without problems. The same applies to u-boot (write
> ram via tftp, dump contents).
Does it work with byte, word and
Albrecht Dreà wrote:
> Am 20.05.09 16:23 schrieb(en) Gary Thomas:
>> > In Linux, when I write the file to /dev/mtdx, the last dword of each
>> block is broken, e.g. when running "dd if=pattern of=/dev/mtd5 bs=512"
>> the dword's at offset 0x1fc, 0x3fc, ... are 0x (instead of
>> 0x0055aaff)
Am 20.05.09 16:23 schrieb(en) Gary Thomas:
> In Linux, when I write the file to /dev/mtdx, the last dword of
each block is broken, e.g. when running "dd if=pattern of=/dev/mtd5
bs=512" the dword's at offset 0x1fc, 0x3fc, ... are 0x
(instead of 0x0055aaff), if I use bs=1024 the dwords
From: Alexander Beregalov
Date: Wed, 20 May 2009 16:18:22 +0400
> Fix this build error:
> drivers/built-in.o: In function `phy_state_machine':
> drivers/net/phy/phy.c:893: undefined reference to 'netif_carrier_off'
> drivers/net/phy/phy.c:854: undefined reference to 'netif_carrier_on'
>
> Signed
From: Benjamin Herrenschmidt
Date: Wed, 20 May 2009 16:51:07 +1000
> On Tue, 2009-05-19 at 22:51 -0700, David Miller wrote:
>> From: Benjamin Herrenschmidt
>> Date: Wed, 20 May 2009 13:01:30 +1000
>>
>> > For example, some of the OF parsing bits may fail to convert memory
>> > addresses to IO a
> Yes, that sounds familiar. Most likely, the value of the MDIO bus
> control register got clobbered and not reset when the FEC was reset.
I recall that I wondered about the RFIFO-error case back then. The manual states
===
Receive FIFO Error - indicates error occurred within the RX FIFO. When
[ed: quoting repaired]
On Wed, May 20, 2009 at 11:26 AM, Eric Millbrandt
wrote:
> Grant Likely wrote:
> > Yes, that sounds familiar. Most likely, the value of the MDIO bus
> > control register got clobbered and not reset when the FEC was reset.
> > Try adding this line to the beginning of mpc52xx
I have ported Linux-2-6-29 to my MPC8272 based board, very similar to the
MPC8272ADS. I am using a cuImage.
Things seem to be working ok except that I am not getting any FEC interrupts
(on IRQ5).
I see that I am transmitting ok.
Any ideas where the problem could be?
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Wednesday, May 20, 2009 12:49
To: Eric Millbrandt
Cc: Jon Smirl; Wolfram Sang; linuxppc-dev@ozlabs.org
Subject: Re: mpc5200 fec error
On Wed, May 20, 2009 at 10:41 AM, Eric Millbrandt
wrote:
> It looks like th
This patch adds a generic driver for SJA1000 chips on the OpenFirmware
platform bus found on embedded PowerPC systems. You need a SJA1000 node
definition in your flattened device tree source (DTS) file similar to:
c...@3,100 {
compatible = "philips,sja1000";
reg = <3 0x100
On Wed, May 20, 2009 at 10:41 AM, Eric Millbrandt
wrote:
> It looks like the phy is never getting reset properly after the
> FEC_IEVENT_RFIFO_ERROR. I threw some printk's into the fec mdio driver
Yes, that sounds familiar. Most likely, the value of the MDIO bus
control register got clobbered a
> On Wed, May 20, 2009 at 9:42 AM, Eric Millbrandt
> wrote:
>>> > I am able to reproduce the error using 2.6.29.2-rt11. I was able to
>>> > mitigate the problem by raising the priority of the transmit irq.
>>> > However when running an NFS server on the pcm030 under high cpu load I
>>> > now get
On Wed, May 20, 2009 at 10:25 AM, Grant Likely
wrote:
> On Wed, May 20, 2009 at 10:15 AM, Wolfram Sang wrote:
>> On Wed, May 20, 2009 at 12:10:59PM -0400, Jon Smirl wrote:
>>> On Wed, May 20, 2009 at 11:53 AM, Wolfram Sang
>>> wrote:
>>> >> > - /* FIXME: EEPROM */
>>> >> >
On Wed, May 20, 2009 at 10:15 AM, Wolfram Sang wrote:
> On Wed, May 20, 2009 at 12:10:59PM -0400, Jon Smirl wrote:
>> On Wed, May 20, 2009 at 11:53 AM, Wolfram Sang wrote:
>> >> > - /* FIXME: EEPROM */
>> >> > + eep...@52 {
>> >> > +
On Wed, May 20, 2009 at 12:10:59PM -0400, Jon Smirl wrote:
> On Wed, May 20, 2009 at 11:53 AM, Wolfram Sang wrote:
> >> > - /* FIXME: EEPROM */
> >> > + eep...@52 {
> >> > + compatible = "at24,24c32";
> >> > +
On Wed, May 20, 2009 at 11:53 AM, Wolfram Sang wrote:
>> > - /* FIXME: EEPROM */
>> > + eep...@52 {
>> > + compatible = "at24,24c32";
>> > + reg = <0x52>;
>> > + };
>>
>> G
> > - /* FIXME: EEPROM */
> > + eep...@52 {
> > + compatible = "at24,24c32";
> > + reg = <0x52>;
> > + };
>
> Grant suggested this earlier...
> eep...
On Friday 15 May 2009 22:40:07 Andrey Gusev wrote:
> On Wed, 13 May 2009 20:46:33 +0200
> Bartlomiej Zolnierkiewicz wrote:
>
> > On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote:
> > > On Wed, 13 May 2009 15:28:26 +0200
> > > Bartlomiej Zolnierkiewicz wrote:
> > >
> > > > On Tuesday 12 May
On Wed, May 20, 2009 at 11:28 AM, Eric Millbrandt
wrote:
> -Original Message-
> From: Jon Smirl [mailto:jonsm...@gmail.com]
> Sent: Wednesday, May 20, 2009 11:15
> To: Eric Millbrandt
> Cc: Wolfram Sang; Grant Likely; linuxppc-dev@ozlabs.org
> Subject: Re: mpc5200 fec error
>
> On Wed, May
Recently , I'm busy with a project based on the main board - MPC8349EA. We use
a pcf8574 connected I2C bus. Now my task is programming to test I2C bus. I find
that file system contains the chip(pcf8574) module .And I add this module into
the kernel. But I find that system only registers the driv
-Original Message-
From: Jon Smirl [mailto:jonsm...@gmail.com]
Sent: Wednesday, May 20, 2009 11:15
To: Eric Millbrandt
Cc: Wolfram Sang; Grant Likely; linuxppc-dev@ozlabs.org
Subject: Re: mpc5200 fec error
On Wed, May 20, 2009 at 9:42 AM, Eric Millbrandt
wrote:
>> > I am able to reproduc
On Wed, May 20, 2009 at 4:07 AM, Wolfram Sang wrote:
> Add a node for the i2c eeprom and delete the superflous gpio-example.
>
> Signed-off-by: Wolfram Sang
> Cc: Grant Likely
> Cc: linuxppc-dev@ozlabs.org
> ---
> arch/powerpc/boot/dts/pcm030.dts | 26 --
> 1 files cha
On Wed, May 20, 2009 at 9:42 AM, Eric Millbrandt
wrote:
>> > I am able to reproduce the error using 2.6.29.2-rt11. I was able to
>> > mitigate the problem by raising the priority of the transmit irq.
>> > However when running an NFS server on the pcm030 under high cpu load I
>> > now get
>> >
>>
Kumar Gala wrote:
Scott, any feedback if our boards have 8M or 32M flash modules?
According to the manual, it comes with 8 but can be expanded to 32. I
don't think we swapped out the flash SIMM that came with the board.
As I wrote earlier in the thread, I don't see any way a current u-boot
Albrecht Dreà wrote:
> Hi all,
>
> I ran into a weird problem when I tried to access a static (NV) ram attached
> to the localbus of a '5200 using Wolfram's mtd-ram OF driver (on a stock
> 2.6.29.1 kernel). The 512k ram chip is connected in 16-bit mode to cs1. the
> of entry reads
>
> nv...
Hi all,
I ran into a weird problem when I tried to access a static (NV) ram attached to
the localbus of a '5200 using Wolfram's mtd-ram OF driver (on a stock 2.6.29.1
kernel). The 512k ram chip is connected in 16-bit mode to cs1. the of entry
reads
nv...@1,0 {
compatible = "mtd-ram";
> > I am able to reproduce the error using 2.6.29.2-rt11. I was able to
> > mitigate the problem by raising the priority of the transmit irq.
> > However when running an NFS server on the pcm030 under high cpu load I
> > now get
> >
> > [ 132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
> > [ 132.89
On May 13, 2009, at 2:42 PM, Wolfgang Denk wrote:
Dear Li Yang,
In message <2a27d3730905130328m27743852w2d68a62ebc32c...@mail.gmail.com
> you wrote:
Although 8MB seems to be the common size used. It can be very easy
changed as a pluggable module. It might be better to make the code
workin
On May 20, 2009, at 7:27 AM, Geert Uytterhoeven wrote:
On Wed, 20 May 2009, Alexander Beregalov wrote:
Fix this build error:
drivers/built-in.o: In function `phy_state_machine':
drivers/net/phy/phy.c:893: undefined reference to 'netif_carrier_off'
drivers/net/phy/phy.c:854: undefined reference
On Wed, 20 May 2009, Alexander Beregalov wrote:
> Fix this build error:
> drivers/built-in.o: In function `phy_state_machine':
> drivers/net/phy/phy.c:893: undefined reference to 'netif_carrier_off'
> drivers/net/phy/phy.c:854: undefined reference to 'netif_carrier_on'
>
> Signed-off-by: Alexander
Fix this build error:
drivers/built-in.o: In function `phy_state_machine':
drivers/net/phy/phy.c:893: undefined reference to 'netif_carrier_off'
drivers/net/phy/phy.c:854: undefined reference to 'netif_carrier_on'
Signed-off-by: Alexander Beregalov
---
arch/powerpc/platforms/82xx/Kconfig |3
While booting 2.6.30-rc6-git5 kernel came across this badness message.
ftrace: allocating 18134 entries in 107 pages
[ cut here ]
Badness at kernel/trace/ftrace.c:444
NIP: c011e754 LR: c01210fc CTR:
REGS: c0edba40 TRAP: 0700 Not t
Hi all,
we are using u-boot 2009.01, linux-2.6.25-rc2, 1GB DDR2 memory(2Gbit * 4,
1 rank), AMCC powerpc 405ex, both 1G and 512MB memory works fine under
u-boot, but linux boot fails in 1G memory, if we limit mem=512M, linux could
boot. Could anyone pls help us how to find the root cause? thanks
Add a node for the i2c eeprom and delete the superflous gpio-example.
Signed-off-by: Wolfram Sang
Cc: Grant Likely
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/boot/dts/pcm030.dts | 26 --
1 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/boo
On Wed, May 20, 2009 at 02:28:52AM +0200, Roel Kluin wrote:
> Do not go beyond ARRAY_SIZE of mpc52xx_uart_{ports,nodes}
>
> Signed-off-by: Roel Kluin
Acked-by: Wolfram Sang
> ---
> diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
> index 7f72f8c..b3feb61 100644
> --- a
On Wed, 2009-05-20 at 00:57 -0500, Kumar Gala wrote:
> Ben,
>
> Comments on the pmac case?
Not yet :-) Give me a day. Was tracking a bug today.
Cheers,
Ben.
> - k
>
> On Apr 29, 2009, at 3:49 PM, Kumar Gala wrote:
>
> > Signed-off-by: Kumar Gala
> > ---
> >
> > Ben,
> >
> > My question is if
On Tue, 2009-05-19 at 22:51 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Wed, 20 May 2009 13:01:30 +1000
>
> > For example, some of the OF parsing bits may fail to convert memory
> > addresses to IO addresses if the PCI host bridges have not been
> > discovered yet, potential
n Fri, 2009-05-15 at 15:56 +0800, ext Li Yang wrote:
> On Fri, May 15, 2009 at 3:33 PM, Jan Neskudla
> wrote:
> > On Wed, 2009-05-13 at 18:57 +0800, ext Li Yang wrote:
> >> cc'ed LKML
> >>
> >> On Tue, May 12, 2009 at 5:17 PM, Jan Neskudla
> >> wrote:
> >> > Hallo
> >> >
> >> > we'd likes to us
53 matches
Mail list logo
