* 2.6.22-ppc8xx fec.c bugs
From: raul.moreno @ 2008-01-10 15:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF9B97E7E0.352B883F-ONC12573CA.0058283E-C12573CA.005AFC5C@abengoa.com>
Hello everyone,
I don't know who the maintainer of the FEC (Fast Ethernet Controller) i=
n
the ppc8xx achitecture is, so I am writing this email here.
After spending some time working withy kernel 2.6.15 for the ppc8xx
architecture, I've recently started to port to the 2.6.22. Doing so I h=
ave
found some bugs in the code managing the FEC (fec.c).
First I found (and cleared) some compilation errors due to inconsistent=
changes in function prototypes (i.e. INIT_WORK). Moreover, if the "MDIO=
for
PHY" configuration is used (in my case for an LXT971 fec) the kernel
couldn't manage to finish booting and was caught in an infinite loop
waiting for fec intialization.
I've seen that some bugs were fixed in the latest kernel but others hav=
en't
been addressed (possibly undetected yet). The following is a diff with
corrections I made to the 2.6.22 'fec.c' file (currently seems to work
fine).
883a884
> #ifdef PHY_INTERRUPT
884a886,888
> #else
> fep->link =3D 1; /* If PHY_INTERRUPT is not defined, fep->link=
must
be also put to 1 */
> #endif
1077c1082
< #endif /* CONFIG_FEC_LXT970 */
---
> #endif /* CONFIG_FEC_LXT971 */
1281c1286
< container_of(work, struct fec_enet_private, phy_task);
---
> container_of(work, struct fec_enet_private, phy_task2);
/* use phy_task2 -->config */
1660c1665,1666
< cbd_base =3D (cbd_t *)dma_alloc_coherent(dev->class_dev.dev, PAGE=
_SIZE,
---
> /* The first parameter has changed */
> cbd_base =3D (cbd_t *)dma_alloc_coherent(&dev->dev, PAGE_SIZE,
1676,1678c1682,1684
< ba =3D (unsigned char *)dma_alloc_coherent(dev->class_dev.d=
ev,
---
> /* The first parameter has changed */
> ba =3D (unsigned char *)dma_alloc_coherent(&dev->dev,
1814,1816c1821,1824
< #ifdef CONFIG_USE_MDIO
< INIT_WORK(&fep->phy_task, mii_relink, (void *)dev);
< INIT_WORK(&fep->phy_task2, mii_display_config, (void *)dev);
---
> #ifdef CONFIG_USE_MDIO /* INIT_WORK has only two parameter=
since 2.6.20 */
> INIT_WORK(&fep->phy_task, mii_relink);
> INIT_WORK(&fep->phy_task2, mii_display_config);
I hope this helps.
Best regards,
Ra=FAl Moreno=
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-10 16:01 UTC (permalink / raw)
To: Timur Tabi; +Cc: alsa-devel, Liam Girdwood, linuxppc-dev, Olof Johansson, david
In-Reply-To: <47863C31.50309@freescale.com>
On 1/10/08, Timur Tabi <timur@freescale.com> wrote:
> Liam Girdwood wrote:
>
> > I think we are probably looking at submission in the next 8 - 10 weeks.
> > Currently most of the core code is complete, however some platforms and
> > codecs still need porting.
>
> With that in mind, can I get some kind of consensus from the PPC side as to
> whether this ASoC V1 driver is okay? I want to get it into 2.6.25.
>
> Keep in mind:
>
> 1) ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1
> PowerPC driver "100% correct".
The driver doesn't need to be 100% correct. Drivers are easy to
change if they aren't quite right. There are no long term
consequences.
However, the device tree issues must be addressed before it is merged
and deployed. Otherwise we end up having to support poorly designed
trees over the long term.
So, I'm okay with merging the driver *minus* the .dts and
booting-without-of.txt changes.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Please pull linux-2.6-mpc52xx for-2.6.24
From: Grant Likely @ 2008-01-10 16:04 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
Paul,
Can you please pull this tree to get an Efika boot fix into 2.6.24.
Without this fix, Ethernet on the Efika will not work without the user
jumping through all kinds of hoops.
Thanks,
g.
The following changes since commit fd0b45dfd1858c6b49d06355a460bcf36d654c06:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.24
Olaf Hering (1):
[POWERPC] efika: add phy-handle property for fec_mpc52xx
arch/powerpc/kernel/prom_init.c | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-10 16:03 UTC (permalink / raw)
To: Grant Likely
Cc: alsa-devel, Liam Girdwood, linuxppc-dev, Olof Johansson, david
In-Reply-To: <fa686aa40801100801p3da98eecn44401b17fe652da8@mail.gmail.com>
Grant Likely wrote:
> The driver doesn't need to be 100% correct. Drivers are easy to
> change if they aren't quite right. There are no long term
> consequences.
>
> However, the device tree issues must be addressed before it is merged
> and deployed. Otherwise we end up having to support poorly designed
> trees over the long term.
I agree. Correct me if I'm wrong, but I think the only device tree "issue" is
the definition of the 'codec' node under the SSI node. If so, I'm not sure what
other changes need to be mode.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Olof Johansson @ 2008-01-10 16:21 UTC (permalink / raw)
To: Linas Vepstas; +Cc: mahuja, linuxppc-dev, lkessler, Nathan Lynch, strosake
In-Reply-To: <3ae3aa420801092012m5e47cbd7lc7a5f91842074af7@mail.gmail.com>
On Wed, Jan 09, 2008 at 10:12:13PM -0600, Linas Vepstas wrote:
> On 09/01/2008, Olof Johansson <olof@lixom.net> wrote:
> > On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote:
> >
> > > Heh. That's the elbow-grease of this thing. The easy part is to get
> > > the core function working. The hard part is to test these various configs,
> > > and when they don't work, figure out what went wrong. That will take
> > > perseverence and brains.
> >
> > This just sounds like a whole lot of extra work to get a feature that
> > already exists.
>
> Well, no. kexec is horribly ill-behaved with respect to PCI. The
> kexec kernel starts running with PCI devices in some random
> state; maybe they're DMA'ing or who knows what. kexec tries
> real hard to whack a few needed pci devices into submission
> but it has been hit-n-miss, and the source of 90% of the kexec
> headaches and debugging effort. Its not pretty.
It surprises me that this hasn't been possible to resolve with less than
architecting a completely new interface, given that the platform has
all this fancy support for isolating and resetting adapters. After all,
the exact same thing has to be done by the hypervisor before rebooting
the partition.
> If all pci-host bridges could shut-down or settle the bus, and
> raise the #RST line high, and then if all BIOS'es supported
> this, you'd be right. But they can't ....
This argument doesn't hold. We're not talking about some generic PC with
a crappy BIOS here, we're specifically talking about POWER6 PHYP. It
certainly already has ways to reset adapters in it, or EEH wouldn't
work. Actually, the whole phyp dump feature wouldn't work either, since
it's exactly what the firmware has to do under the covers as well.
-Olof
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Linas Vepstas @ 2008-01-10 16:34 UTC (permalink / raw)
To: Olof Johansson; +Cc: mahuja, linuxppc-dev, lkessler, Nathan Lynch, strosake
In-Reply-To: <20080110162120.GA4831@lixom.net>
On 10/01/2008, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Jan 09, 2008 at 10:12:13PM -0600, Linas Vepstas wrote:
> > On 09/01/2008, Olof Johansson <olof@lixom.net> wrote:
> > > On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote:
> > >
> > > > Heh. That's the elbow-grease of this thing. The easy part is to get
> > > > the core function working. The hard part is to test these various configs,
> > > > and when they don't work, figure out what went wrong. That will take
> > > > perseverence and brains.
> > >
> > > This just sounds like a whole lot of extra work to get a feature that
> > > already exists.
> >
> > Well, no. kexec is horribly ill-behaved with respect to PCI. The
> > kexec kernel starts running with PCI devices in some random
> > state; maybe they're DMA'ing or who knows what. kexec tries
> > real hard to whack a few needed pci devices into submission
> > but it has been hit-n-miss, and the source of 90% of the kexec
> > headaches and debugging effort. Its not pretty.
>
> It surprises me that this hasn't been possible to resolve with less than
> architecting a completely new interface, given that the platform has
> all this fancy support for isolating and resetting adapters. After all,
> the exact same thing has to be done by the hypervisor before rebooting
> the partition.
OK, point taken.
-- The phyp interfaces are there for AIX, which I guess must
not have kexec-like ability. So this is a case of Linux leveraging
a feature architected for AIX.
-- There's also this idea, somewhat weak, that the crash may
have corrupted the ram where the kexec kernel sits.
For someone who is used to seeing crashes due to
null pointer deref's, this seems fairly unlikely. But perhaps
crashes in production systems are more mind-bending.
(we did have a case where a USB stick used for boot
continued to scribble on memory long after it was
supposed to be quiet and unused. This resulted in
a very hard to debug crash.)
A solution to a corrupted
kexec kernel would be to disable memory access to
where kexec sits, e.g un-mapping or making r/o the
pages where it lies. This begs the questions of "who
unhides the kexec kernel", and "what if this 'who' gets
corrupted"?
In short, the kexec kernel does not boot
exactly the same as a cold boot, and so this opens
a can of worms about "well, what's different, how do
we minimize these differences, etc." and I think that
lead AIX to punt, and say "lets just use one single,
well-known boot loader/ boot sequence instead of
inventing a new one", thus leading to the phyp design.
But that's just my guess.. :-)
--linas
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] Update MPC8610 HPCD to support audio drivers
From: Grant Likely @ 2008-01-10 16:35 UTC (permalink / raw)
To: Timur Tabi; +Cc: liam.girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <1199732204578-git-send-email-timur@freescale.com>
On 1/7/08, Timur Tabi <timur@freescale.com> wrote:
> Update the MPC8610 HPCD files to support the audio driver. Update
> booting-without-of.txt with information on the SSI device.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> Updated based on comments from mailing lists. Split the patch into two parts.
>
> This patch applies on top of
> git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git.
>
> Documentation/powerpc/booting-without-of.txt | 40 ++++++
> arch/powerpc/boot/dts/mpc8610_hpcd.dts | 110 ++++++++++++++++-
> arch/powerpc/configs/mpc8610_hpcd_defconfig | 171 +++++++++++++++++++++++++-
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 18 +++
> 4 files changed, 335 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..826af91 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -53,6 +53,7 @@ Table of Contents
> j) CFI or JEDEC memory-mapped NOR flash
> k) Global Utilities Block
> l) Xilinx IP cores
> + p) Freescale Synchronous Serial Interface
>
> VII - Specifying interrupt information for devices
> 1) interrupts property
> @@ -2514,6 +2515,45 @@ platforms are moved over to use the flattened-device-tree model.
> Requred properties:
> - current-speed : Baud rate of uartlite
>
> + p) Freescale Synchronous Serial Interface
> +
> + The SSI is a serial device that communicates with audio codecs. It can
> + be programmed in AC97, I2S, left-justified, or right-justified modes.
> +
> + Required properties:
> + - compatible : compatible list, containing "fsl,ssi"
> + - cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on
> + - reg : offset and length of the register set for the device
> + - interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and
> + level information for the interrupt. This should be
> + encoded based on the information in section 2)
> + depending on the type of interrupt controller you
> + have.
> + - interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> + - fsl,mode : the operating mode for the SSI interface
> + "i2s-slave" - I2S mode, SSI is clock slave
> + "i2s-master" - I2S mode, SSI is clock master
> + "lj-slave" - left-justified mode, SSI is clock slave
> + "lj-master" - l.j. mode, SSI is clock master
> + "rj-slave" - right-justified mode, SSI is clock slave
> + "rj-master" - r.j., SSI is clock master
> + "ac97-slave" - AC97 mode, SSI is clock slave
> + "ac97-master" - AC97 mode, SSI is clock master
> +
> + Optional properties:
> + - codec : child node that defines an audio codec connected
> + to this SSI
> +
> + Child 'codec' node required properties:
> + - compatible : compatible list, contains the name of the codec
> +
> + Child 'codec' node optional properties:
> + - bus-frequency : The frequency of the input clock, which typically
> + comes from an on-board dedicated oscillator.
> +
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
> diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
> index 966edf1..fda0ace 100644
> --- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
> +++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
> @@ -1,7 +1,7 @@
> /*
> * MPC8610 HPCD Device Tree Source
> *
> - * Copyright 2007 Freescale Semiconductor Inc.
> + * Copyright 2007-2008 Freescale Semiconductor Inc.
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License Version 2 as published
> @@ -42,6 +42,7 @@
> #size-cells = <1>;
> #interrupt-cells = <2>;
> device_type = "soc";
> + compatible = "fsl,mpc8610";
Something like "fsl,mpc8610-immr" might be a better choice here. This
node doesn't actually describe the entire chip (for example, the PPC
cores are in the cpus node); but it does describe the internally
memory mapped registers.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/5] Version 17, series to add device tree naming to i2c
From: Jean Delvare @ 2008-01-10 16:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c
In-Reply-To: <9e4733910801100614y7522a573qb2af41a714b08d5@mail.gmail.com>
On Thu, 10 Jan 2008 09:14:26 -0500, Jon Smirl wrote:
> What is the review status of this series, should I post it again?
No please! /o\
I'll go through your numerous past posts now, stay tuned.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 3/3] Return a non-zero exit code if an error occurs during dts parsing.
From: Scott Wood @ 2008-01-10 17:22 UTC (permalink / raw)
To: Scott Wood, jdl, linuxppc-dev
In-Reply-To: <20080110035609.GL17816@localhost.localdomain>
David Gibson wrote:
> On Sun, Jan 06, 2008 at 04:55:09PM -0600, Scott Wood wrote:
>> On Fri, Jan 04, 2008 at 03:30:33PM +1100, David Gibson wrote:
>>> This is unequivocally wrong. boot_info should have information about
>>> the contents of the blob, not state information like the error.
>> "This blob is invalid" *is* information about the contents of the blob.
>>
>>> If you're going to use an ugly global, then use it everywhere.
>> Why go out of our way to make the code even less library-able/thread-safe?
>
> It doesn't make it any less thread-safe. A global variable used some
> places is just as bad as a global variable used everywhere from that
> point of view, and is more complicated.
But the knowledge of the fact that the boot_info struct is a global is
isolated to the treesource code. I don't see any reason to add another
global at the *interface* level, much less that not doing so is
"unequivocally wrong".
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
From: Scott Wood @ 2008-01-10 17:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <354E8B44-78B4-49DF-8DCF-5E70BB982E86@kernel.crashing.org>
Kumar Gala wrote:
>
> On Jan 9, 2008, at 1:52 PM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>> I'm thinking I'll add something like:
>>> if (addr < total_lowmem)
>>> reserve_bootmem(lmb.reserved.region[i].base,
>>> lmb_size_bytes(&lmb.reserved,
>>> i));
>>> + else if (lmb.reserved.region[i].base > total_lowmem) {
>>
>> less than, surely?
>
> damn, why didn't I see your email before a spent 20 minutes debugging
> this ;)
Because, as happens all too often lately, Freescale's mail servers
needed to chew on it for an hour and a half before sending it on. :-P
-Scott
^ permalink raw reply
* Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
From: Scott Wood @ 2008-01-10 17:27 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev, Jeff Garzik
In-Reply-To: <4785E014.4040709@denx.de>
Heiko Schocher wrote:
> diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> index f2a4d39..f432a18 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -810,6 +810,10 @@ static int fs_enet_open(struct net_device *dev)
> if (fep->fpi->use_napi)
> napi_enable(&fep->napi);
>
> + /* to initialize the fep->cur_rx,... */
> + /* not doing this, will cause a crash in fs_enet_rx_napi */
> + fs_init_bds(fep->ndev);
We should do this just before napi_enable() rather than just after, to
eliminate any chance of a race window.
Looks good otherwise.
-Scott
^ permalink raw reply
* Re: 2.6.22-ppc8xx fec.c bugs
From: Scott Wood @ 2008-01-10 17:48 UTC (permalink / raw)
To: raul.moreno; +Cc: linuxppc-embedded
In-Reply-To: <OF7BC7CA29.9B371169-ONC12573CC.00553A44-C12573CC.0057BA09@abengoa.com>
raul.moreno@telvent.abengoa.com wrote:
> Hello everyone,
>
> I don't know who the maintainer of the FEC (Fast Ethernet Controller) in
> the ppc8xx achitecture is, so I am writing this email here.
arch/ppc is deprecated, and arch/ppc/8xx_io especially so.
Please use drivers/net/fs_enet (and also note that arch/ppc will be
going away in a few months).
> I've seen that some bugs were fixed in the latest kernel but others haven't
> been addressed (possibly undetected yet). The following is a diff with
> corrections I made to the 2.6.22 'fec.c' file (currently seems to work
> fine).
Please post patches against the latest head-of-tree, and in unified diff
format (diff -u).
-Scott
^ permalink raw reply
* Re: Help with device tree binding for SMC serial
From: Scott Wood @ 2008-01-10 17:53 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03D58C20@ismail.innsys.innovsys.com>
On Wed, Jan 09, 2008 at 05:07:23PM -0600, Rune Torgersen wrote:
> > From: Scott Wood [mailto:scottwood@freescale.com]
> > Rune Torgersen wrote:
> > > Did that, now we get e checkstop resert. Time to hook up the
> > > BDI-2000.... Is there a way to have the bootwrapper use the u-boot
> > > serial for a while (like a early srial port) for debugging?
> >
> > If you mean calling into u-boot for a console, no, there's no
> > code for that.
> >
> > What do your cpm and muram nodes look like?
[snip tree]
The tree looks OK. The checkstop may be from erratum SIU18;
I had this issue on the ep8248e board.
Try clearing BCR[PLDP].
-Scott
^ permalink raw reply
* ibm4xx_quiesce_eth?
From: Sean MacLennan @ 2008-01-10 18:38 UTC (permalink / raw)
To: 'linuxppc-dev'
What exactly does this function do?
/* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't
* do this for us
*/
On the taco, with the 440EP, it doesn't seem to make any difference if I
call this or not. Since I am using u-boot, is it not needed?
Cheers,
Sean
^ permalink raw reply
* Re: ibm4xx_quiesce_eth?
From: Josh Boyer @ 2008-01-10 18:24 UTC (permalink / raw)
To: Sean MacLennan; +Cc: 'linuxppc-dev'
In-Reply-To: <47866614.3010203@pikatech.com>
On Thu, 10 Jan 2008 13:38:12 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> What exactly does this function do?
>
> /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't
> * do this for us
> */
>
> On the taco, with the 440EP, it doesn't seem to make any difference if I
> call this or not. Since I am using u-boot, is it not needed?
There are firmwares that do not reset the EMAC and MAL before passing
control to the client program (Linux in our case). This can cause
weird things to happen, like spurious interrupts or DMAs from the
hardware overwriting kernel memory. So we quiesce the hardware really
early on those.
I don't believe U-Boot has that problem. If it does, it should be
fixed :)
josh
^ permalink raw reply
* Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
From: Heiko Schocher @ 2008-01-10 18:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Jeff Garzik
In-Reply-To: <4786556C.8040108@freescale.com>
Hello Scott,
Scott Wood wrote:
> Heiko Schocher wrote:
>> diff --git a/drivers/net/fs_enet/fs_enet-main.c
>> b/drivers/net/fs_enet/fs_enet-main.c
>> index f2a4d39..f432a18 100644
>> --- a/drivers/net/fs_enet/fs_enet-main.c
>> +++ b/drivers/net/fs_enet/fs_enet-main.c
>> @@ -810,6 +810,10 @@ static int fs_enet_open(struct net_device *dev)
>> if (fep->fpi->use_napi)
>> napi_enable(&fep->napi);
>>
>> + /* to initialize the fep->cur_rx,... */
>> + /* not doing this, will cause a crash in fs_enet_rx_napi */
>> + fs_init_bds(fep->ndev);
>
> We should do this just before napi_enable() rather than just after, to
> eliminate any chance of a race window.
Yes, you are right.
Here is the new patch:
>From 3b8db4261199f0115d8e0188b6bffbc9f5e7673d Mon Sep 17 00:00:00 2001
From: Heiko Schocher <hs@denx.de>
Date: Thu, 10 Jan 2008 19:28:18 +0100
Subject: [PATCH] [POWERPC] Fix Ethernet over SCC on a CPM2,
also Fix crash in fs_enet_rx_napi()
Signed-off-by: Heiko Schocher <hs@denx.de>
---
drivers/net/fs_enet/fs_enet-main.c | 10 +++++++++-
drivers/net/fs_enet/mac-scc.c | 8 +++++++-
include/asm-powerpc/cpm2.h | 5 +++++
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..70a0319 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -807,6 +807,10 @@ static int fs_enet_open(struct net_device *dev)
int r;
int err;
+ /* to initialize the fep->cur_rx,... */
+ /* not doing this, will cause a crash in fs_enet_rx_napi */
+ fs_init_bds(fep->ndev);
+
if (fep->fpi->use_napi)
napi_enable(&fep->napi);
@@ -982,6 +986,7 @@ static struct net_device *fs_init_instance(struct device *dev,
fep = netdev_priv(ndev);
fep->dev = dev;
+ fep->ndev = ndev;
dev_set_drvdata(dev, ndev);
fep->fpi = fpi;
if (fpi->init_ioports)
@@ -1085,7 +1090,6 @@ static struct net_device *fs_init_instance(struct device *dev,
}
registered = 1;
-
return ndev;
err:
@@ -1347,6 +1351,10 @@ static struct of_device_id fs_enet_match[] = {
.compatible = "fsl,cpm1-scc-enet",
.data = (void *)&fs_scc_ops,
},
+ {
+ .compatible = "fsl,cpm2-scc-enet",
+ .data = (void *)&fs_scc_ops,
+ },
#endif
#ifdef CONFIG_FS_ENET_HAS_FCC
{
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index fe3d8a6..3889271 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -50,7 +50,6 @@
#include "fs_enet.h"
/*************************************************/
-
#if defined(CONFIG_CPM1)
/* for a 8xx __raw_xxx's are sufficient */
#define __fs_out32(addr, x) __raw_writel(x, addr)
@@ -65,6 +64,8 @@
#define __fs_out16(addr, x) out_be16(addr, x)
#define __fs_in32(addr) in_be32(addr)
#define __fs_in16(addr) in_be16(addr)
+#define __fs_out8(addr, x) out_8(addr, x)
+#define __fs_in8(addr) in_8(addr)
#endif
/* write, read, set bits, clear bits */
@@ -297,8 +298,13 @@ static void restart(struct net_device *dev)
/* Initialize function code registers for big-endian.
*/
+#ifndef CONFIG_NOT_COHERENT_CACHE
+ W8(ep, sen_genscc.scc_rfcr, SCC_EB | SCC_GBL);
+ W8(ep, sen_genscc.scc_tfcr, SCC_EB | SCC_GBL);
+#else
W8(ep, sen_genscc.scc_rfcr, SCC_EB);
W8(ep, sen_genscc.scc_tfcr, SCC_EB);
+#endif
/* Set maximum bytes per receive buffer.
* This appears to be an Ethernet frame size, not the buffer
diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
index f1112c1..14c6496 100644
--- a/include/asm-powerpc/cpm2.h
+++ b/include/asm-powerpc/cpm2.h
@@ -375,6 +375,11 @@ typedef struct scc_param {
uint scc_tcrc; /* Internal */
} sccp_t;
+/* Function code bits.
+*/
+#define SCC_EB ((u_char) 0x10) /* Set big endian byte order */
+#define SCC_GBL ((u_char) 0x20) /* Snooping enabled */
+
/* CPM Ethernet through SCC1.
*/
typedef struct scc_enet {
--
1.5.2.2
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* RE: Help with device tree binding for SMC serial
From: Rune Torgersen @ 2008-01-10 19:10 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080110175348.GA4317@loki.buserror.net>
> From: Scott Wood
>=20
> The tree looks OK. The checkstop may be from erratum SIU18;
> I had this issue on the ep8248e board.
>=20
> Try clearing BCR[PLDP].
Not sure what was wrong. We took a step back, and redid some stuff, and
now we have serial output from the boot-wrapper.
THe checkstop came from the wrapper grying to access the bcsr and doing
the chip select fixup. We don';t have a bcsr on our board, and the cs
layout is different.
Now our problem is that the kernel doesn't want to output anything to
hte serial port.
^ permalink raw reply
* Re: Help with device tree binding for SMC serial
From: Scott Wood @ 2008-01-10 19:19 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03D99E60@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> Not sure what was wrong. We took a step back, and redid some stuff, and
> now we have serial output from the boot-wrapper.
> THe checkstop came from the wrapper grying to access the bcsr and doing
> the chip select fixup. We don';t have a bcsr on our board, and the cs
> layout is different.
There's no bcsr access in the upstream bootwrapper (the mention of bcsr
in cuboot-pq2.c is just one reason why some boards require us to do the
CS programming), and the CS programming is chip-level, not board-level
(it just requires that the device tree have a correct localbus node for
the board).
-Scott
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-10 20:10 UTC (permalink / raw)
To: Timur Tabi; +Cc: alsa-devel, Liam Girdwood, linuxppc-dev, Olof Johansson, david
In-Reply-To: <478641E3.5070404@freescale.com>
On 1/10/08, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > The driver doesn't need to be 100% correct. Drivers are easy to
> > change if they aren't quite right. There are no long term
> > consequences.
> >
> > However, the device tree issues must be addressed before it is merged
> > and deployed. Otherwise we end up having to support poorly designed
> > trees over the long term.
>
> I agree. Correct me if I'm wrong, but I think the only device tree "issue" is
> the definition of the 'codec' node under the SSI node. If so, I'm not sure what
> other changes need to be mode.
Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?
What about fsl,ssi being too generic for a compatible type?
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-10 20:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: alsa-devel, Liam Girdwood, linuxppc-dev, Olof Johansson, david
In-Reply-To: <9e4733910801101210w5846bb4ds38a603a489ef0522@mail.gmail.com>
Jon Smirl wrote:
> Isn't your codec is i2c controlled? Where does the main node for the
> code live, i2c bus or ssi bus? What does the link between the buses
> look like for pointing to the codec entry?
The CS4270 driver is "old style", which means it probes all possible I2C
addresses until it finds a hit, and then stops. This has all the obvious
drawbacks, but I'm stuck with that design for now.
> What about fsl,ssi being too generic for a compatible type?
Already fixed:
ssi@16000 {
compatible = "fsl,mpc8610-ssi";
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-10 20:24 UTC (permalink / raw)
To: Timur Tabi; +Cc: alsa-devel, Liam Girdwood, linuxppc-dev, Olof Johansson, david
In-Reply-To: <47867C80.4050408@freescale.com>
On 1/10/08, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > Isn't your codec is i2c controlled? Where does the main node for the
> > code live, i2c bus or ssi bus? What does the link between the buses
> > look like for pointing to the codec entry?
>
> The CS4270 driver is "old style", which means it probes all possible I2C
> addresses until it finds a hit, and then stops. This has all the obvious
> drawbacks, but I'm stuck with that design for now.
>
> > What about fsl,ssi being too generic for a compatible type?
>
> Already fixed:
>
> ssi@16000 {
> compatible = "fsl,mpc8610-ssi";
Nit: node name should be either i2s@16000 (the mode that it is in), or
sound@16000 (if you feel that this node encapsulates the concept of a
sound device enough).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-10 20:35 UTC (permalink / raw)
To: Grant Likely
Cc: alsa-devel, Liam Girdwood, linuxppc-dev, Olof Johansson, david
In-Reply-To: <fa686aa40801101224p298e60bcheb622324c80690ea@mail.gmail.com>
Grant Likely wrote:
> Nit: node name should be either i2s@16000 (the mode that it is in), or
> sound@16000 (if you feel that this node encapsulates the concept of a
> sound device enough).
Well, SSI stands for "Synchronous Serial Interface" (although it's capable of
asynchronous communication as well). From the manual:
"The SSI is a full-duplex, serial port that allows the chip to communicate with
a variety of serial devices. These serial devices can be standard CODer-DECoder
(CODECs), Digital Signal Processors (DSPs), microprocessors, peripherals, and
popular industry audio CODECs that implement the inter-IC sound bus standard
(I2S) and Intel AC97 standard."
It might an I2S device in this case, but it could be an AC97 device in some
other case. It all depends on how the board is wired. Do we really want to
change the name of an SOC device based on what it's connected to?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-10 20:39 UTC (permalink / raw)
To: Timur Tabi; +Cc: alsa-devel, Liam Girdwood, linuxppc-dev, Olof Johansson, david
In-Reply-To: <47867C80.4050408@freescale.com>
On 1/10/08, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > Isn't your codec is i2c controlled? Where does the main node for the
> > code live, i2c bus or ssi bus? What does the link between the buses
> > look like for pointing to the codec entry?
>
> The CS4270 driver is "old style", which means it probes all possible I2C
> addresses until it finds a hit, and then stops. This has all the obvious
> drawbacks, but I'm stuck with that design for now.
So the codec is controlled from the i2c bus and SSI is used to supply
it with data. Based on what has been said on this list, the device
tree node for the codec should be on the i2c bus with a link from the
ssi bus to it.
>
> > What about fsl,ssi being too generic for a compatible type?
>
> Already fixed:
>
> ssi@16000 {
> compatible = "fsl,mpc8610-ssi";
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-10 20:44 UTC (permalink / raw)
To: Jon Smirl; +Cc: alsa-devel, Liam Girdwood, linuxppc-dev, Olof Johansson, david
In-Reply-To: <9e4733910801101239n539507a8sb23d1a2177e69bd9@mail.gmail.com>
Jon Smirl wrote:
> So the codec is controlled from the i2c bus and SSI is used to supply
> it with data. Based on what has been said on this list, the device
> tree node for the codec should be on the i2c bus with a link from the
> ssi bus to it.
I'm working on that now. I'll have a new patch with this exact change this
afternoon.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* RE: In PowerPC's feature, are there any difference between ML410 and ML403?
From: Stephen Neuendorffer @ 2008-01-10 21:27 UTC (permalink / raw)
To: diak sim, linuxppc-embedded
In-Reply-To: <147365.85546.qm@web92009.mail.cnb.yahoo.com>
There shouldn't be a significant different in the cores themselves, =
however, there are many ways to get the FPGA design slightly wrong where =
it won't boot, or to get the kernel xparameters file out of synch with =
the FPGA design. This is most likely your problem.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org =
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of diak sim
> Sent: Thursday, January 10, 2008 5:56 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: In PowerPC's feature,are there any difference between ML410 =
and ML403?
>=20
> Hello everyone,
>=20
> I am using ML410 to port a Linux 2.6 kernel, but init_IRQ() doesn't =
pass.
> Porting Linux 2.6 to ML403 is successful? No such a problem?
> In PowerPC's feature, are there any difference between ML410 and =
ML403?
>=20
> Thanks.
>=20
>=20
> ________________________________
>=20
> =
=D1=C5=BB=A2=D3=CA=CF=E4=B4=AB=B5=DD=D0=C2=C4=EA=D7=A3=B8=A3=A3=AC=B8=F6=D0=
=D4=BA=D8=BF=A8=CB=CD=C7=D7=C5=F3=A3=A1 =
<http://cn.mail.yahoo.com/gc/index.html?entry=3D5&souce=3Dmail_mailletter=
_tagline>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox