* Re: MPC5200 ethernet communication stops unexpected
From: David Kanceruk @ 2007-05-15 15:03 UTC (permalink / raw)
To: Hans Thielemans; +Cc: linuxppc-embedded
In-Reply-To: <1179234357.1668.10.camel@pc-hans>
Hello Hans,
Our problem was with the FEC sending data with one or two
incorrect bytes when we switched from the MPC5200 to the MPC5200B. The
byte positions were always the same. The socket buffer has the correct
data before and after the DMA engine runs but the FEC TxFIFO does not
always match.
One solution to our problem was to make the following call prior to
starting the DMA:
flush_dcache_range((unsigned long)skb->data, (unsigned long)skb->data
+ skb->len);
The other solution was to set the BSDIS bit in the XLB config register
during initialization as follows:
xlb = (struct mpc52xx_xlb *)MPC5xxx_XLB;
out_be32(&xlb->config, in_be32(&xlb->config) | MPC52xx_XLB_CFG_BSDIS);
Either solution works for us. The BSDIS bit is a new feature in the
MPC5200B. The MPC5200 did not have this bit.
According to the Freescale documentation, (Application note AN3045,
for instance) setting this bit is supposed to "disable" BestComm bus
snooping. However, I have reason to believe the documentation is in
error. Everything I have observed seems to indicate that in the
MPC5200 BestComm bus snooping was always enabled or enabled via some
other means. In the MPC5200B it appears to be "disabled" at reset (not
"enabled" as the documentation states). This is why flushing the cache
manually is one solution. Since setting the BSDIS bit also fixes the
problem, it suggests that this actually "enables" BestComm bus
snooping instead of disabling it. In my mind, it could all boil down
to a simple documentation error.
Perhaps you are also experiencing a caching problem.
Best regards,
David Kanceruk
On 5/15/07, Hans Thielemans <hans.thielemans@metris.com> wrote:
> Hi David,
>
> I have a similar problem. I use the PSC for communication to a DSP.
> With the MPC5200 this has always worked. Now we got boards with the
> MCP5200B in place.
>
> The bestcomm dma seems to miss bits, bytes in the last word (32bit) of a
> dma block. Mostly it is one byte which becomes 0. The blocks are 256
> bytes and written/read by 32 bits.
> The behavior is influenced by cpu activity, bus priorities. So far I
> found no settings which have never errors.
>
> Did you have any further progress?
>
> Regards
>
> Hans Thielemans
>
--
David Kanceruk
"The generation of random numbers is far too important to be left to chance."
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Fix Section mismatch warnings
From: Kumar Gala @ 2007-05-15 14:06 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, Paul, Linux Kernel
In-Reply-To: <46484110.5020607@freescale.com>
On May 14, 2007, at 5:59 AM, Li Yang wrote:
> This patch fix the following Section mismatch warnings
> in powerpc code.
>
> WARNING: arch/powerpc/platforms/built-in.o - Section mismatch:
> reference to .init.data:mv643xx_eth_pd_devs from .text between
> 'mv643xx_eth_add_pds' (at offset 0x9ed2) and 'gg2_read_config'
> WARNING: arch/powerpc/platforms/built-in.o - Section mismatch:
> reference to .init.data:mv643xx_eth_pd_devs from .text between
> 'mv643xx_eth_add_pds' (at offset 0x9ed6) and 'gg2_read_config'
> WARNING: arch/powerpc/platforms/built-in.o - Section mismatch:
> reference to .init.text:note_scsi_host from __ksymtab between
> '__ksymtab_note_scsi_host' (at offset 0x8) and '__ksymtab_sys_ctrler'
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/chrp/pegasos_eth.c | 2 +-
> arch/powerpc/platforms/powermac/setup.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Did you change anything?
- k
> diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/
> powerpc/platforms/chrp/pegasos_eth.c
> index 7104567..5c9f135 100644
> --- a/arch/powerpc/platforms/chrp/pegasos_eth.c
> +++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
> @@ -169,7 +169,7 @@ static int Enable_SRAM(void)
>
> /***********/
> /***********/
> -int mv643xx_eth_add_pds(void)
> +int __init mv643xx_eth_add_pds(void)
> {
> int ret = 0;
> static struct pci_device_id pci_marvell_mv64360[] = {
> diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/
> platforms/powermac/setup.c
> index a410bc7..07b1c4e 100644
> --- a/arch/powerpc/platforms/powermac/setup.c
> +++ b/arch/powerpc/platforms/powermac/setup.c
> @@ -384,7 +384,7 @@ int boot_part;
> static dev_t boot_dev;
>
> #ifdef CONFIG_SCSI
> -void __init note_scsi_host(struct device_node *node, void *host)
> +void note_scsi_host(struct device_node *node, void *host)
> {
> int l;
> char *p;
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [i2c] [PATCH] Make i2c-mpc driver use i2c_add_numbered_adapter
From: Jean Delvare @ 2007-05-15 13:26 UTC (permalink / raw)
To: Grant Likely; +Cc: rtc-linux, James Chapman, David Brownell, linuxppc-dev, i2c
In-Reply-To: <20070514190545.32739.72083.stgit@trillian.secretlab.ca>
On Mon, 14 May 2007 13:11:23 -0600, Grant Likely wrote:
> Move the i2c-mpc driver over to using the new i2c infrastructure.
> Specifically, it now uses i2c_add_numberd_adapter so that the bus number
i2c_add_numbered_adapter (missing e)
> can be determined ahead of time and used to register i2c clients before
> the bus is instantiated.
>
> Tested on an MPC5200 based board
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Jean Delvare <khali@linux-fr.org>
> ---
> This patch will need to be tested to make sure it does not break any 8xxx
> board ports.
>
> Work still to be done (in another patch): support for pulling i2c client
> registrations out of the device tree.
>
> drivers/i2c/busses/i2c-mpc.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index c6b6898..a769efc 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -327,9 +327,10 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, i2c);
>
> i2c->adap = mpc_ops;
> + i2c->adap.nr = pdev->id;
> i2c_set_adapdata(&i2c->adap, i2c);
> i2c->adap.dev.parent = &pdev->dev;
> - if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
> + if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
> printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
> goto fail_add;
> }
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Fix IO space on PCI busses created from of_platform
From: Arnd Bergmann @ 2007-05-15 13:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20070515041656.41CE7DDECA@ozlabs.org>
On Tuesday 15 May 2007, Benjamin Herrenschmidt wrote:
> +=A0=A0=A0=A0=A0=A0=A0/* Setup IO space. We use the non-dynamic version o=
f that code here,
> +=A0=A0=A0=A0=A0=A0=A0 * which doesn't quite support unplugging. Next ker=
nel release will
> +=A0=A0=A0=A0=A0=A0=A0 * have a better fix for this.
> +=A0=A0=A0=A0=A0=A0=A0 * Note also that we don't do ISA, this will also b=
e fixed with a
> +=A0=A0=A0=A0=A0=A0=A0 * more massive rework.
> =A0=A0=A0=A0=A0=A0=A0=A0 */
> -=A0=A0=A0=A0=A0=A0=A0pci_setup_phb_io_dynamic(phb, 0);
> +=A0=A0=A0=A0=A0=A0=A0pci_setup_phb_io(phb, 0);
> =A0
I think this still needs some logic to make sure we have at least one
primary PHB in the system. On a board that has all phbs probed by
of_platform code, we never set the pci_io_base variable.
The easiest solution might be to statically initialize pci_io_base
to PHBS_IO_BASE. If it is different from that, we are already broken
because we would get _negative_ I/O port numbers for PHBs below
pci_io_base.
Arnd <><
^ permalink raw reply
* Re: [i2c] [patch/rft 4/4] rtc-ds1307 platform update, powerpc mpc834x_itx and mpc8313_rdb
From: Jean Delvare @ 2007-05-15 13:24 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, i2c, rtc-linux
In-Reply-To: <200705141149.27858.david-b@pacbell.net>
On Mon, 14 May 2007 11:49:27 -0700, David Brownell wrote:
>
> > > > @@ -329,7 +330,7 @@ static int fsl_i2c_probe(struct platform
> > > > i2c->adap = mpc_ops;
> > > > i2c_set_adapdata(&i2c->adap, i2c);
> > > > i2c->adap.dev.parent = &pdev->dev;
> > > > - if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
> > > > + if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
> > > > printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
> > > > goto fail_add;
> > > > }
> > >
> > > ...
> > >
> > > I think you need to add this line before the call to i2c_add_numbered_adapter:
> > >
> > > i2c->adap.nr = pdev->id;
> >
> > If these chips do have multiple instances of that adapter logic,
> > that would be an appropriate change. The only "gotcha" might be
> > that some platforms use the "pdev->id = -1" trick when there's
> > only a single instance ... that would probably map to zero.
> >
> > I'll hope that whoever makes all this work will resolve those
> > particular questions ...
>
> Oh, and by the way: patches updating I2C adapter drivers to work
> with new-style drivers look to be OK to get into 2.6.22 with just
> an Ack from Jean, via the MM tree. (Right, Jean?)
Correct. I will happily ack such patches, but I won't be pushing them
upstream - unless waiting until 2.6.23 is OK for you.
--
Jean Delvare
^ permalink raw reply
* RE: zImage.elf loads but does not start
From: Mead, Joseph @ 2007-05-15 13:12 UTC (permalink / raw)
To: Mirek23, linuxppc-embedded
In-Reply-To: <10621564.post@talk.nabble.com>
Hi Mirek,
If you think the networking might be the source of the problem maybe try
to make a very simple root file system using initramfs to see if you can
get the init program (or busybox) working. =20
Just create a file in that looks something like:
dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
nod /dev/ttyS0 644 0 0 c 4 64
dir /proc 755 0 0
dir /sys 755 0 0
file /init usr/busybox 755 0 0
and then tell the kernel about it General_Setup-> Initramfs source
file(s)
It will build the file system into the kernel image.
Also, thanks for the files.=20
Joe
=20
-----Original Message-----
From: linuxppc-embedded-bounces+mead=3Dbnl.gov@ozlabs.org
[mailto:linuxppc-embedded-bounces+mead=3Dbnl.gov@ozlabs.org] On Behalf =
Of
Mirek23
Sent: Tuesday, May 15, 2007 8:09 AM
To: linuxppc-embedded@ozlabs.org
Subject: RE: zImage.elf loads but does not start
>It seems to be that the console works fine and the root file system is
mounted properly via NFS.
>I do not however understand why eldk4.1 init does not work.
I have done some more investigations. My observation is as following:
The eldk4.1/ppc_4xx root file system has the init which is not
statically built. When I removed the lib directory on the NFS
server:/opt/eldk4.1/ppc_4xx/lib the kernel has booted up to the point:
[ 9.302101] VFS: Mounted root (nfs filesystem).
[ 9.357642] Freeing unused kernel memory: 96k init
[ 9.481509] Kernel panic - not syncing: No init found. Try passing
init=3D
option to kernel.
When the lib directory was present the last printed message was:
[ 9.357642] Freeing unused kernel memory: 96k init
I have observed the same behaviour with busybox accessed via NFS.
I have compiled busybox with crosstool-0.43 (gcc-4.0.2 glibc-2.3.2)
because
eldk4.1 crosscompilers failed to compile busybox. When using busybox
mounted via NFS I copied the lib directory from crosstool.
Unfortunately also this time the system hanged at init.
My own version of init which uses printf just to print the string to the
screen runs however fine.
Would somebody have some suggestion what might cause the problem to
properly launch the init command.
Best Regards
Mirek
--
View this message in context:
http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10
621564
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] viopath: use completion
From: Christoph Hellwig @ 2007-05-15 13:10 UTC (permalink / raw)
To: boutcher, linuxppc-dev
In-Reply-To: <20070513155027.GB9218@lst.de>
On Sun, May 13, 2007 at 05:50:27PM +0200, Christoph Hellwig wrote:
> Use a completion instead of abusing a semaphore for hypervisor event
> completion in viopath.
And some more of the same sort:
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6.20/arch/powerpc/platforms/iseries/viopath.c
===================================================================
--- linux-2.6.20.orig/arch/powerpc/platforms/iseries/viopath.c 2007-05-15 14:48:57.000000000 +0200
+++ linux-2.6.20/arch/powerpc/platforms/iseries/viopath.c 2007-05-15 14:51:36.000000000 +0200
@@ -81,7 +81,7 @@ static void handleMonitorEvent(struct Hv
* if system_state is not SYSTEM_RUNNING, then wait_atomic is used ...
*/
struct alloc_parms {
- struct semaphore sem;
+ struct completion done;
int number;
atomic_t wait_atomic;
int used_wait_atomic;
@@ -464,7 +464,7 @@ static void viopath_donealloc(void *parm
if (parmsp->used_wait_atomic)
atomic_set(&parmsp->wait_atomic, 0);
else
- up(&parmsp->sem);
+ complete(&parmsp->done);
}
static int allocateEvents(HvLpIndex remoteLp, int numEvents)
@@ -476,7 +476,7 @@ static int allocateEvents(HvLpIndex remo
atomic_set(&parms.wait_atomic, 1);
} else {
parms.used_wait_atomic = 0;
- init_MUTEX_LOCKED(&parms.sem);
+ init_completion(&parms.done);
}
mf_allocate_lp_events(remoteLp, HvLpEvent_Type_VirtualIo, 250, /* It would be nice to put a real number here! */
numEvents, &viopath_donealloc, &parms);
@@ -484,7 +484,7 @@ static int allocateEvents(HvLpIndex remo
while (atomic_read(&parms.wait_atomic))
mb();
} else
- down(&parms.sem);
+ wait_for_completion(&parms.done);
return parms.number;
}
@@ -585,10 +585,10 @@ int viopath_close(HvLpIndex remoteLp, in
spin_unlock_irqrestore(&statuslock, flags);
parms.used_wait_atomic = 0;
- init_MUTEX_LOCKED(&parms.sem);
+ init_completion(&parms.done);
mf_deallocate_lp_events(remoteLp, HvLpEvent_Type_VirtualIo,
numReq, &viopath_donealloc, &parms);
- down(&parms.sem);
+ wait_for_completion(&parms.done);
spin_lock_irqsave(&statuslock, flags);
for (i = 0, numOpen = 0; i < VIO_MAX_SUBTYPES; i++)
^ permalink raw reply
* Re: [PATCH 3/3] Fixes to allow use of Ebony's flash chips through physmap_of
From: Josh Boyer @ 2007-05-15 13:10 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070515045415.98889DDED7@ozlabs.org>
On Tue, 2007-05-15 at 14:54 +1000, David Gibson wrote:
> void ebony_init(void *mac0, void *mac1)
> Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:45:56.000000000 +1000
> +++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:45:58.000000000 +1000
> @@ -176,6 +176,7 @@
> fpga@7,0 {
> compatible = "Ebony-FPGA";
> reg = <7 0 10>;
> + virtual-reg = <e8300000>;
That's the mapping for OpenBios. What happens if someone is using
U-Boot?
If the mapping isn't the same, you might want to pass the address from
the individual firmware wrapper parts to ebony_flashsel_fixup similar to
how you've done it for dt_fixup_mac_addresses.
josh
^ permalink raw reply
* [PATCH] fix celleb link failure
From: Christoph Hellwig @ 2007-05-15 13:09 UTC (permalink / raw)
To: kou.ishizaki; +Cc: linuxppc-dev, cbe-oss-dev
txx9_serial_init calls early_serial_txx9_setup which is only available
if CONFIG_SERIAL_TXX9_CONSOLE is define. From looking at scc_sio.c
it seems like the whole file is only needed for
CONFIG_SERIAL_TXX9_CONSOLE=y, so we should only build it for that case.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6.20/arch/powerpc/platforms/celleb/Makefile
===================================================================
--- linux-2.6.20.orig/arch/powerpc/platforms/celleb/Makefile 2007-05-15 14:42:15.000000000 +0200
+++ linux-2.6.20/arch/powerpc/platforms/celleb/Makefile 2007-05-15 14:42:31.000000000 +0200
@@ -4,5 +4,5 @@ obj-y += interrupt.o iommu.o setup.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_PPC_UDBG_BEAT) += udbg_beat.o
-obj-$(CONFIG_HAS_TXX9_SERIAL) += scc_sio.o
+obj-$(CONFIG_SERIAL_TXX9_CONSOLE) += scc_sio.o
obj-$(CONFIG_SPU_BASE) += spu_priv1.o
Index: linux-2.6.20/arch/powerpc/platforms/celleb/scc_sio.c
===================================================================
--- linux-2.6.20.orig/arch/powerpc/platforms/celleb/scc_sio.c 2007-05-15 14:40:49.000000000 +0200
+++ linux-2.6.20/arch/powerpc/platforms/celleb/scc_sio.c 2007-05-15 14:42:47.000000000 +0200
@@ -65,9 +65,7 @@ static int txx9_serial_init(void)
req.line = i;
req.iotype = UPIO_MEM;
req.mapbase = res.start + txx9_scc_tab[i].offset;
-#ifdef CONFIG_SERIAL_TXX9_CONSOLE
req.membase = ioremap(req.mapbase, 0x24);
-#endif
req.irq = irq_create_of_mapping(irq.controller,
irq.specifier, irq.size);
req.flags |= UPF_IOREMAP | UPF_BUGGY_UART /*HAVE_CTS_LINE*/;
^ permalink raw reply
* Re: [PATCH 2/3] Derive ebc ranges property from EBC registers
From: Josh Boyer @ 2007-05-15 12:59 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070515045415.5B05ADDECE@ozlabs.org>
On Tue, 2007-05-15 at 14:54 +1000, David Gibson wrote:
> void ebony_init(void *mac0, void *mac1)
> Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:38:39.000000000 +1000
> +++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:45:56.000000000 +1000
> @@ -136,11 +136,9 @@
> #address-cells = <2>;
> #size-cells = <1>;
> clock-frequency = <0>; // Filled in by zImage
> - ranges = <0 00000000 fff00000 100000
> - 1 00000000 48000000 100000
> - 2 00000000 ff800000 400000
> - 3 00000000 48200000 100000
> - 7 00000000 48300000 100000>;
> + // ranges property is supplied by zImage
> + // based on firmware's configuration of the
> + // EBC bridge
Do we want a "ranges;" here as a placeholder? I don't see where it's
absolutely required, but it makes me feel better for some reason...
> +
> +/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
> + * banks into the OPB address space */
> +void ibm4xx_fixup_ebc_ranges(const char *ebc)
> +{
> + void *devp;
> + u32 bxcr;
> + u32 ranges[EBC_NUM_BANKS*4];
> + u32 *p = ranges;
> + int i;
> +
> + for (i = 0; i < EBC_NUM_BANKS; i++) {
> + mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
> + bxcr = mfdcr(DCRN_EBC0_CFGDATA);
> +
> + if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
> + *p++ = i;
> + *p++ = 0;
> + *p++ = bxcr & EBC_BXCR_BAS;
> + *p++ = EBC_BXCR_BANK_SIZE(bxcr);
> + }
> + }
> +
> + devp = finddevice(ebc);
> + if (! devp)
> + fatal("Couldn't locate EBC node %s\n\r", ebc);
> +
> + setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
> +}
So this sets the ranges for the EBC bus, but not the "regs" properties
of the child nodes. Without that, the child nodes will not be mapped to
the correct addresses...
Did you have a plan on how to fixup the child "regs" properties so that
when the DIP switches are flipped around, the children show up
correctly?
josh
^ permalink raw reply
* Re: zImage.elf loads but does not start
From: Miroslaw Dach @ 2007-05-15 12:45 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <4649A7AC.1050503@ru.mvista.com>
> > [ 9.357642] Freeing unused kernel memory: 96k init
>
> Any NFS timeouts after reaching this point? Any network activity at all?
> (NFS timeout is quite long, so waiting few minutes would make sense)
I have monitored the network activity on the NFS server with program
ethereal. It seems to be that the root file system is mounted. There are
packet sent from a to my xilinx board. The /var/log/messages contains also
the entry that mount was done successfully. When init is executed the
ethereal show only individual packets which are sent (in fixed interval of
time - once per 20 seconds) from the NFS server to the client but client
seem to be dead. Even ping does not reach my xilinx board when kernel
executes the init.
I think that the best prove that the rootfile system is properly mounted
is the fact that my own test init function (which substitutes the real
init) which simply prints the string to the console does that what is
expected to do. The real init unfortunately does not print anything to the
console.
Best Regards
Mirek
^ permalink raw reply
* Re: [PATCH 1/3] Factor zImage's 44x reset code out of ebony.c
From: Josh Boyer @ 2007-05-15 12:47 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070515045415.544B6DDED5@ozlabs.org>
On Tue, 2007-05-15 at 14:54 +1000, David Gibson wrote:
> The ebony_exit() function which resets the Ebony board should in fact
> be common to most if not all 44x boards. This patch moves the
> function out into 44x.c, renaming it, so it can be used by other 44x
> platforms.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested on my ebony board. Will work nicely for 440EP as well.
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
^ permalink raw reply
* [PATCH v4] 83xx USB platform code rework
From: Li Yang @ 2007-05-14 11:14 UTC (permalink / raw)
To: Paul; +Cc: linuxppc-dev
Add 831x USB platform setup code and rework 834x USB
platform setup code. Move USB platform code to usb.c
for different boards with CPU of the same series to share
the USB initialization code.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
Address comments from Stephen Rothwell.
arch/powerpc/platforms/83xx/Kconfig | 2 +
arch/powerpc/platforms/83xx/Makefile | 2 +-
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 1 +
arch/powerpc/platforms/83xx/mpc834x_mds.c | 49 +-------
arch/powerpc/platforms/83xx/mpc83xx.h | 28 ++++-
arch/powerpc/platforms/83xx/usb.c | 181 +++++++++++++++++++++++++++++
6 files changed, 215 insertions(+), 48 deletions(-)
create mode 100644 arch/powerpc/platforms/83xx/usb.c
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 19cafdf..e2d4efa 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -56,6 +56,7 @@ config PPC_MPC831x
bool
select PPC_UDBG_16550
select PPC_INDIRECT_PCI
+ select USB_EHCI_FSL
default y if MPC8313_RDB
config PPC_MPC832x
@@ -68,6 +69,7 @@ config MPC834x
bool
select PPC_UDBG_16550
select PPC_INDIRECT_PCI
+ select USB_EHCI_FSL
default y if MPC834x_MDS || MPC834x_ITX
config PPC_MPC836x
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 31a91b5..5a98f88 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for the PowerPC 83xx linux kernel.
#
-obj-y := misc.o
+obj-y := misc.o usb.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_MPC8313_RDB) += mpc8313_rdb.o
obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o
diff --git a/arch/powerpc/platforms/83xx/mpc8313_rdb.c b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
index 32e9e94..2f5d89a 100644
--- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
@@ -51,6 +51,7 @@ static void __init mpc8313_rdb_setup_arch(void)
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
#endif
+ mpc831x_usb_cfg();
}
void __init mpc8313_rdb_init_IRQ(void)
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 10394b2..28b3840 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -44,55 +44,16 @@ unsigned long isa_mem_base = 0;
#endif
#define BCSR5_INT_USB 0x02
-/* Note: This is only for PB, not for PB+PIB
- * On PB only port0 is connected using ULPI */
-static int mpc834x_usb_cfg(void)
+static int mpc834xemds_usb_cfg(void)
{
- unsigned long sccr, sicrl;
- void __iomem *immap;
+ struct device_node *np;
void __iomem *bcsr_regs = NULL;
u8 bcsr5;
- struct device_node *np = NULL;
- int port0_is_dr = 0;
-
- if ((np = of_find_compatible_node(NULL, "usb", "fsl-usb2-dr")) != NULL)
- port0_is_dr = 1;
- if ((np = of_find_compatible_node(NULL, "usb", "fsl-usb2-mph")) != NULL){
- if (port0_is_dr) {
- printk(KERN_WARNING
- "There is only one USB port on PB board! \n");
- return -1;
- } else if (!port0_is_dr)
- /* No usb port enabled */
- return -1;
- }
-
- immap = ioremap(get_immrbase(), 0x1000);
- if (!immap)
- return -1;
-
- /* Configure clock */
- sccr = in_be32(immap + MPC83XX_SCCR_OFFS);
- if (port0_is_dr)
- sccr |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
- else
- sccr |= MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
- out_be32(immap + MPC83XX_SCCR_OFFS, sccr);
-
- /* Configure Pin */
- sicrl = in_be32(immap + MPC83XX_SICRL_OFFS);
- /* set port0 only */
- if (port0_is_dr)
- sicrl |= MPC83XX_SICRL_USB0;
- else
- sicrl &= ~(MPC83XX_SICRL_USB0);
- out_be32(immap + MPC83XX_SICRL_OFFS, sicrl);
-
- iounmap(immap);
+ mpc834x_usb_cfg();
/* Map BCSR area */
np = of_find_node_by_name(NULL, "bcsr");
- if (np != 0) {
+ if (np) {
struct resource res;
of_address_to_resource(np, 0, &res);
@@ -134,7 +95,7 @@ static void __init mpc834x_mds_setup_arch(void)
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
#endif
- mpc834x_usb_cfg();
+ mpc834xemds_usb_cfg();
}
static void __init mpc834x_mds_init_IRQ(void)
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index 9cd03b5..a44e5b1 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -6,6 +6,7 @@
/* System Clock Control Register */
#define MPC83XX_SCCR_OFFS 0xA08
+#define MPC83XX_SCCR_USB_MASK 0x00f00000
#define MPC83XX_SCCR_USB_MPHCM_11 0x00c00000
#define MPC83XX_SCCR_USB_MPHCM_01 0x00400000
#define MPC83XX_SCCR_USB_MPHCM_10 0x00800000
@@ -15,12 +16,31 @@
/* system i/o configuration register low */
#define MPC83XX_SICRL_OFFS 0x114
-#define MPC83XX_SICRL_USB0 0x40000000
-#define MPC83XX_SICRL_USB1 0x20000000
+#define MPC834X_SICRL_USB_MASK 0x60000000
+#define MPC834X_SICRL_USB0 0x40000000
+#define MPC834X_SICRL_USB1 0x20000000
+#define MPC831X_SICRL_USB_MASK 0x00000c00
+#define MPC831X_SICRL_USB_ULPI 0x00000800
/* system i/o configuration register high */
#define MPC83XX_SICRH_OFFS 0x118
-#define MPC83XX_SICRH_USB_UTMI 0x00020000
+#define MPC834X_SICRH_USB_UTMI 0x00020000
+#define MPC831X_SICRH_USB_MASK 0x000000e0
+#define MPC831X_SICRH_USB_ULPI 0x000000a0
+
+/* USB Control Register */
+#define FSL_USB2_CONTROL_OFFS 0x500
+#define CONTROL_UTMI_PHY_EN 0x00000200
+#define CONTROL_REFSEL_48MHZ 0x00000080
+#define CONTROL_PHY_CLK_SEL_ULPI 0x00000400
+#define CONTROL_OTG_PORT 0x00000020
+
+/* USB PORTSC Registers */
+#define FSL_USB2_PORTSC1_OFFS 0x184
+#define FSL_USB2_PORTSC2_OFFS 0x188
+#define PORTSCX_PTW_16BIT 0x10000000
+#define PORTSCX_PTS_UTMI 0x00000000
+#define PORTSCX_PTS_ULPI 0x80000000
/*
* Declaration for the various functions exported by the
@@ -31,5 +51,7 @@ extern int add_bridge(struct device_node *dev);
extern int mpc83xx_exclude_device(u_char bus, u_char devfn);
extern void mpc83xx_restart(char *cmd);
extern long mpc83xx_time_init(void);
+extern int mpc834x_usb_cfg(void);
+extern int mpc831x_usb_cfg(void);
#endif /* __MPC83XX_H__ */
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
new file mode 100644
index 0000000..e7fdf01
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -0,0 +1,181 @@
+/*
+ * Freescale 83xx USB SOC setup code
+ *
+ * Copyright (C) 2007 Freescale Semiconductor, Inc.
+ * Author: Li Yang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <sysdev/fsl_soc.h>
+
+#include "mpc83xx.h"
+
+
+#ifdef CONFIG_MPC834x
+int mpc834x_usb_cfg(void)
+{
+ unsigned long sccr, sicrl, sicrh;
+ void __iomem *immap;
+ struct device_node *np = NULL;
+ int port0_is_dr = 0, port1_is_dr = 0;
+ const void *prop, *dr_mode;
+
+ immap = ioremap(get_immrbase(), 0x1000);
+ if (!immap)
+ return -ENOMEM;
+
+ /* Read registers */
+ /* Note: DR and MPH must use the same clock setting in SCCR */
+ sccr = in_be32(immap + MPC83XX_SCCR_OFFS) & ~MPC83XX_SCCR_USB_MASK;
+ sicrl = in_be32(immap + MPC83XX_SICRL_OFFS) & ~MPC834X_SICRL_USB_MASK;
+ sicrh = in_be32(immap + MPC83XX_SICRH_OFFS) & ~MPC834X_SICRH_USB_UTMI;
+
+ np = of_find_compatible_node(NULL, "usb", "fsl-usb2-dr");
+ if (np) {
+ sccr |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
+
+ prop = of_get_property(np, "phy_type", NULL);
+ if (prop && (!strcmp(prop, "utmi") ||
+ !strcmp(prop, "utmi_wide"))) {
+ sicrl |= MPC834X_SICRL_USB0 | MPC834X_SICRL_USB1;
+ sicrh |= MPC834X_SICRH_USB_UTMI;
+ port1_is_dr = 1;
+ } else if (prop && !strcmp(prop, "serial")) {
+ dr_mode = of_get_property(np, "dr_mode", NULL);
+ if (dr_mode && !strcmp(dr_mode, "otg")) {
+ sicrl |= MPC834X_SICRL_USB0 | MPC834X_SICRL_USB1;
+ port1_is_dr = 1;
+ } else {
+ sicrl |= MPC834X_SICRL_USB0;
+ }
+ } else if (prop && !strcmp(prop, "ulpi")) {
+ sicrl |= MPC834X_SICRL_USB0;
+ } else {
+ printk(KERN_WARNING "834x USB PHY type not supported\n");
+ }
+ port0_is_dr = 1;
+ of_node_put(np);
+ }
+ np = of_find_compatible_node(NULL, "usb", "fsl-usb2-mph");
+ if (np) {
+ sccr |= MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
+
+ prop = of_get_property(np, "port0", NULL);
+ if (prop) {
+ if (port0_is_dr)
+ printk(KERN_WARNING
+ "834x USB port0 can't be used by both DR and MPH!\n");
+ sicrl |= MPC834X_SICRL_USB0;
+ }
+ prop = of_get_property(np, "port1", NULL);
+ if (prop) {
+ if (port1_is_dr)
+ printk(KERN_WARNING
+ "834x USB port1 can't be used by both DR and MPH!\n");
+ sicrl |= MPC834X_SICRL_USB1;
+ }
+ of_node_put(np);
+ }
+
+ /* Write back */
+ out_be32(immap + MPC83XX_SCCR_OFFS, sccr);
+ out_be32(immap + MPC83XX_SICRL_OFFS, sicrl);
+ out_be32(immap + MPC83XX_SICRH_OFFS, sicrh);
+
+ iounmap(immap);
+ return 0;
+}
+#endif /* CONFIG_MPC834x */
+
+#ifdef CONFIG_PPC_MPC831x
+int mpc831x_usb_cfg(void)
+{
+ u32 temp;
+ void __iomem *immap, *usb_regs;
+ struct device_node *np = NULL;
+ const void *prop;
+ struct resource res;
+ int ret = 0;
+#ifdef CONFIG_USB_OTG
+ const void *dr_mode;
+#endif
+
+ np = of_find_compatible_node(NULL, "usb", "fsl-usb2-dr");
+ if (!np)
+ return -ENODEV;
+ prop = of_get_property(np, "phy_type", NULL);
+
+ /* Map IMMR space for pin and clock settings */
+ immap = ioremap(get_immrbase(), 0x1000);
+ if (!immap) {
+ of_node_put(np);
+ return -ENOMEM;
+ }
+
+ /* Configure clock */
+ temp = in_be32(immap + MPC83XX_SCCR_OFFS);
+ temp &= ~MPC83XX_SCCR_USB_MASK;
+ temp |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
+ out_be32(immap + MPC83XX_SCCR_OFFS, temp);
+
+ /* Configure pin mux for ULPI. There is no pin mux for UTMI */
+ if (!strcmp(prop, "ulpi")) {
+ temp = in_be32(immap + MPC83XX_SICRL_OFFS);
+ temp &= ~MPC831X_SICRL_USB_MASK;
+ temp |= MPC831X_SICRL_USB_ULPI;
+ out_be32(immap + MPC83XX_SICRL_OFFS, temp);
+
+ temp = in_be32(immap + MPC83XX_SICRH_OFFS);
+ temp &= ~MPC831X_SICRH_USB_MASK;
+ temp |= MPC831X_SICRH_USB_ULPI;
+ out_be32(immap + MPC83XX_SICRH_OFFS, temp);
+ }
+
+ iounmap(immap);
+
+ /* Map USB SOC space */
+ ret = of_address_to_resource(np, 0, &res);
+ if (ret) {
+ of_node_put(np);
+ return ret;
+ }
+ usb_regs = ioremap(res.start, res.end - res.start + 1);
+
+ /* Using on-chip PHY */
+ if (!strcmp(prop, "utmi_wide") ||
+ !strcmp(prop, "utmi")) {
+ /* Set UTMI_PHY_EN, REFSEL to 48MHZ */
+ out_be32(usb_regs + FSL_USB2_CONTROL_OFFS,
+ CONTROL_UTMI_PHY_EN | CONTROL_REFSEL_48MHZ);
+ /* Using external UPLI PHY */
+ } else if (!strcmp(prop, "ulpi")) {
+ /* Set PHY_CLK_SEL to ULPI */
+ temp = CONTROL_PHY_CLK_SEL_ULPI;
+#ifdef CONFIG_USB_OTG
+ /* Set OTG_PORT */
+ dr_mode = of_get_property(np, "dr_mode", NULL);
+ if (dr_mode && !strcmp(dr_mode, "otg"))
+ temp |= CONTROL_OTG_PORT;
+#endif /* CONFIG_USB_OTG */
+ out_be32(usb_regs + FSL_USB2_CONTROL_OFFS, temp);
+ } else {
+ printk(KERN_WARNING "831x USB PHY type not supported\n");
+ ret = -EINVAL;
+ }
+
+ iounmap(usb_regs);
+ of_node_put(np);
+ return ret;
+}
+#endif /* CONFIG_PPC_MPC831x */
^ permalink raw reply related
* [PATCH 1/2] kbuild: Add "Section mismatch" warning whitelist for powerpc
From: Li Yang @ 2007-05-14 10:53 UTC (permalink / raw)
To: Linus, Andrew Morton, Linux Kernel; +Cc: linuxppc-dev, Sam Ravnborg
This patch fixes the following "Section mismatch" warnings when
build powerpc platforms.
-------------
WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to .init.text:early_get_page from .text between 'pte_alloc_one_kernel' (at offset 0xc68) and 'pte_alloc_one'
WARNING: mm/built-in.o - Section mismatch: reference to .init.text:set_up_list3s from .text between 'kmem_cache_create' (at offset 0x20300) and 'cache_reap'
-------------
Massive warnings represented by:
-------------
WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from prom_entry (offset 0x0)
WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.text:mpc8313_rdb_probe from .machine.desc after 'mach_mpc8313_rdb' (at offset 0x4)
-------------
Signed-off-by: Li Yang <leoli@freescale.com>
---
scripts/mod/modpost.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index c89cb71..aa3a881 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -649,9 +649,10 @@ static int strrcmp(const char *s, const char *sub)
* tosec = .init.text
*
* Pattern 10:
- * ia64 has machvec table for each platform. It is mixture of function
- * pointer of .init.text and .text.
- * fromsec = .machvec
+ * ia64 has machvec table and powerpc has machine desc table for each
+ * platform. It is mixture of function pointer of .init.text and .text.
+ * fromsec = .machvec | .machine.desc
+ *
**/
static int secref_whitelist(const char *modname, const char *tosec,
const char *fromsec, const char *atsym,
@@ -681,6 +682,8 @@ static int secref_whitelist(const char *modname, const char *tosec,
const char *pat4sym[] = {
"sparse_index_alloc",
"zone_wait_table_init",
+ "pte_alloc_one_kernel",
+ "kmem_cache_create",
NULL
};
@@ -750,7 +753,8 @@ static int secref_whitelist(const char *modname, const char *tosec,
return 1;
/* Check for pattern 10 */
- if (strcmp(fromsec, ".machvec") == 0)
+ if ((strcmp(fromsec, ".machvec") == 0) ||
+ (strcmp(fromsec, ".machine.desc") == 0))
return 1;
return 0;
@@ -883,6 +887,10 @@ static void warn_sec_mismatch(const char *modname, const char *fromsec,
secref_whitelist(modname, secname, fromsec,
elf->strtab + before->st_name, refsymname))
return;
+ /* fromsec whitelist - without a valid 'before' */
+ /* powerpc has a GOT table in .got2 section */
+ if (strcmp(fromsec, ".got2") == 0)
+ return;
if (before && after) {
warn("%s - Section mismatch: reference to %s:%s from %s "
^ permalink raw reply related
* Re: zImage.elf loads but does not start
From: Andrei Konovalov @ 2007-05-15 12:29 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <10621564.post@talk.nabble.com>
Hi Mirek,
Mirek23 wrote:
>> It seems to be that the console works fine and the root file system is
> mounted properly via NFS.
>> I do not however understand why eldk4.1 init does not work.
>
> I have done some more investigations. My observation is as following:
>
> The eldk4.1/ppc_4xx root file system has the init which is not statically
> built. When I removed the lib directory on the
> NFS server:/opt/eldk4.1/ppc_4xx/lib the kernel has booted up to the point:
>
> [ 9.302101] VFS: Mounted root (nfs filesystem).
> [ 9.357642] Freeing unused kernel memory: 96k init
> [ 9.481509] Kernel panic - not syncing: No init found. Try passing init=
> option to kernel.
>
>
> When the lib directory was present the last printed message was:
> [ 9.357642] Freeing unused kernel memory: 96k init
Any NFS timeouts after reaching this point? Any network activity at all?
(NFS timeout is quite long, so waiting few minutes would make sense)
Thanks,
Andrei
> I have observed the same behaviour with busybox accessed via NFS.
> I have compiled busybox with crosstool-0.43 (gcc-4.0.2 glibc-2.3.2) because
> eldk4.1 crosscompilers failed to compile busybox. When using busybox mounted
> via NFS I copied the lib directory from crosstool.
> Unfortunately also this time the system hanged at init.
>
> My own version of init which uses printf just to print the string to the
> screen runs however fine.
>
> Would somebody have some suggestion what might cause the problem to properly
> launch the init command.
>
> Best Regards
>
> Mirek
^ permalink raw reply
* RE: zImage.elf loads but does not start
From: Mirek23 @ 2007-05-15 12:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <10429898.post@talk.nabble.com>
>It seems to be that the console works fine and the root file system is
mounted properly via NFS.
>I do not however understand why eldk4.1 init does not work.
I have done some more investigations. My observation is as following:
The eldk4.1/ppc_4xx root file system has the init which is not statically
built. When I removed the lib directory on the
NFS server:/opt/eldk4.1/ppc_4xx/lib the kernel has booted up to the point:
[ 9.302101] VFS: Mounted root (nfs filesystem).
[ 9.357642] Freeing unused kernel memory: 96k init
[ 9.481509] Kernel panic - not syncing: No init found. Try passing init=
option to kernel.
When the lib directory was present the last printed message was:
[ 9.357642] Freeing unused kernel memory: 96k init
I have observed the same behaviour with busybox accessed via NFS.
I have compiled busybox with crosstool-0.43 (gcc-4.0.2 glibc-2.3.2) because
eldk4.1 crosscompilers failed to compile busybox. When using busybox mounted
via NFS I copied the lib directory from crosstool.
Unfortunately also this time the system hanged at init.
My own version of init which uses printf just to print the string to the
screen runs however fine.
Would somebody have some suggestion what might cause the problem to properly
launch the init command.
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10621564
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Fixed PHY and MPC832x based boards don't work
From: Joakim Tjernlund @ 2007-05-15 11:40 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <1179095103.20638.56.camel@gentoo-jocke.transmode.se>
On Mon, 2007-05-14 at 00:25 +0200, Joakim Tjernlund wrote:
> On Mon, 2007-05-14 at 00:36 +0400, Vitaly Bordug wrote:
> > On Sun, 13 May 2007 16:39:30 +0200
> > Joakim Tjernlund wrote:
> >
> > > Trying to make the Fixed PHY work under my 832x based board on current
> > > linus tree without success. Earlier kernels with custom PHY code for
> > > ucc_geth work without any special tricks.
> > >
> > > If I enable the FIXED_MII_100_FDX option I get:
> > > ls bus/mdio_bus/devices/
> > > fixed@100:1@
> > >
> > > but ucc_geth wants its PHYs under
> > > ls -l bus/of_platform/devices/*phy*
> > > lrwxrwxrwx 1 root root 0 May 12 17:32
> > > bus/of_platform/devices/ethernet-p hy.1
> > > -> ../../../devices/e0100000.qe/e0102320.mdio/ethernet-phy.1/
> > > lrwxrwxrwx 1 root root 0 May 12 17:32
> > > bus/of_platform/devices/ethernet-p hy.3
> > > -> ../../../devices/e0100000.qe/e0102320.mdio/ethernet-phy.3/
> > > lrwxrwxrwx 1 root root 0 May 12 17:32
> > > bus/of_platform/devices/fixed-phy. 2
> > > -> ../../../devices/e0100000.qe/e0102320.mdio/fixed-phy.2/ These are
> > > 3 PHYs I just added in the DTS tree:
> > >
> > > mdio@2320 {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > reg = <2320 18>;
> > > device_type = "mdio";
> > > compatible = "ucc_geth_phy";
> > >
> > > phy1: ethernet-phy@18 {
> > > linux,phandle = <212000>;
> > > reg = <18>; // 24
> > > device_type = "ethernet-phy";
> > > interface = <3>; //ENET_100_MII
> > > };
> > > phy2: fixed-phy@64 {
> > > linux,phandle = <212001>;
> > > reg = <d#100>;
> > > device_type = "ethernet-phy";
> > > };
> > > phy3: ethernet-phy@19 {
> > > linux,phandle = <212002>;
> > > interrupt-parent = <700>;
> > > interrupts = <12 2>;
> > > reg = <19>; // 25
> > > device_type = "ethernet-phy";
> > > interface = <3>; //ENET_100_MII
> > > };
> > > };
> > >
> > > How do I add a fixed PHY so that ucc_geth finds it?
> > >
> > well I guess ucc stuff follows gianfar trend in mdio bus specification for the phy.
> > So, it would look like %d:%d or something like that.
> >
> > Can you please dump the whole dts here?
>
> Sure, it look pretty much like the 832x_mds
> phy2 is my experiment to get hold of the fixed phy, but the others should also be converted into a fixed phy. Here goes my DTS:
Ping, any ideas how to make fixed PHY work?
This is a regression(sort of) compared with 2.6.20. The old PHY impl.
for ucc_geth did accept these PHYs, the Gen PHY driver would just report
a PHY id of ffffffff and move on.
Jocke
[SNIP DTS]
^ permalink raw reply
* [PATCH 2/2] powerpc: Fix Section mismatch warnings
From: Li Yang @ 2007-05-14 10:59 UTC (permalink / raw)
To: Paul; +Cc: linuxppc-dev, Linux Kernel
This patch fix the following Section mismatch warnings
in powerpc code.
WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:mv643xx_eth_pd_devs from .text between 'mv643xx_eth_add_pds' (at offset 0x9ed2) and 'gg2_read_config'
WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:mv643xx_eth_pd_devs from .text between 'mv643xx_eth_add_pds' (at offset 0x9ed6) and 'gg2_read_config'
WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.text:note_scsi_host from __ksymtab between '__ksymtab_note_scsi_host' (at offset 0x8) and '__ksymtab_sys_ctrler'
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/platforms/chrp/pegasos_eth.c | 2 +-
arch/powerpc/platforms/powermac/setup.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c
index 7104567..5c9f135 100644
--- a/arch/powerpc/platforms/chrp/pegasos_eth.c
+++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
@@ -169,7 +169,7 @@ static int Enable_SRAM(void)
/***********/
/***********/
-int mv643xx_eth_add_pds(void)
+int __init mv643xx_eth_add_pds(void)
{
int ret = 0;
static struct pci_device_id pci_marvell_mv64360[] = {
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index a410bc7..07b1c4e 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -384,7 +384,7 @@ int boot_part;
static dev_t boot_dev;
#ifdef CONFIG_SCSI
-void __init note_scsi_host(struct device_node *node, void *host)
+void note_scsi_host(struct device_node *node, void *host)
{
int l;
char *p;
^ permalink raw reply related
* MPC5200B memory performance
From: Daniel Schnell @ 2007-05-15 11:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]
Hi,
I am doing some memory performance measurements on our custom MPC5200B
board which runs on 396 MHz internally and is connected to DDR RAM. The
RAM is driven with 132 MHz.
With the attached program (compile with -lrt) I am testing the memcpy()
throughput. In theory the memory throughput should be the double of the
memcpy() throughput if source and destination buffers are same size and
inside the DDR-RAM.
So one could make the simple calculation:
132 MHz * 32 Bit (address width) * 2 (DDR) ~ 1GBytes/sec brutto memory
throughput.
For a memcpy this should be then ~500MB/second.
Of course in real world scenarios we cannot reach the theoretical limit,
but be about 30 % near I guess.
I get the following values on my board:
bash-2.05b# ./memcpy_perf
Test (10000) memcpy of sizes (1024) ....
10000 memcpy. Time per memcpy: 1567 [nsec] (653 MB/sec)
finished.
Test (10000) memcpy of sizes (2048) ....
10000 memcpy. Time per memcpy: 2939 [nsec] (696 MB/sec)
finished.
Test (10000) memcpy of sizes (4096) ....
10000 memcpy. Time per memcpy: 5706 [nsec] (717 MB/sec)
finished.
Test (10000) memcpy of sizes (8192) ....
10000 memcpy. Time per memcpy: 17077 [nsec] (479 MB/sec)
finished.
Test (10000) memcpy of sizes (16384) ....
10000 memcpy. Time per memcpy: 133314 [nsec] (122 MB/sec)
finished.
Test (1000) memcpy of sizes (32768) ....
1000 memcpy. Time per memcpy: 243417 [nsec] (134 MB/sec)
finished.
Test (1000) memcpy of sizes (51200) ....
1000 memcpy. Time per memcpy: 403455 [nsec] (126 MB/sec)
finished.
Test (1000) memcpy of sizes (102400) ....
1000 memcpy. Time per memcpy: 713316 [nsec] (143 MB/sec)
finished.
Test (100) memcpy of sizes (1048576) ....
100 memcpy. Time per memcpy: 7210570 [nsec] (145 MB/sec)
finished.
Test (10) memcpy of sizes (10485760) ....
10 memcpy. Time per memcpy: 78162400 [nsec] (134 MB/sec)
finished.
Test (5) memcpy of sizes (52428800) ....
5 memcpy. Time per memcpy: 425281800 [nsec] (123 MB/sec)
finished.
The first 4 values are because of the data cache. So here we are testing
cache performance. All other values will test the memory controller
interface.
All in all, I am not sure, why the memory access is so much slower than
I expected.
Which factors did I miss in my calculation ? Can anybody run this
program on its 5200B based board as a comparision ?
Best regards,
Daniel Schnell.
[-- Attachment #2: memcpy_perf.c --]
[-- Type: application/octet-stream, Size: 1979 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <pthread.h>
int osa_now_timespec(struct timespec* t)
{
return clock_gettime (CLOCK_REALTIME, t);
}
int osa_timediff(const struct timespec* t1, const struct timespec* t2, struct timespec* diff)
{
if (t1!=NULL && t2!=NULL && diff!=NULL)
{
unsigned long long a_nsec, b_nsec, diff_nsec;
// calculate difference time
a_nsec = t1->tv_sec*1000000000ULL + t1->tv_nsec;
b_nsec = t2->tv_sec*1000000000ULL + t2->tv_nsec;
diff_nsec = b_nsec - a_nsec;
diff->tv_sec = diff_nsec/1000000000ULL;
diff->tv_nsec = diff_nsec%1000000000ULL;
return 0;
}
return -1;
}
unsigned long long osa_to_ns(const struct timespec* t)
{
return (t->tv_sec*1000000000ULL + t->tv_nsec);
}
int testMemcpy(unsigned long num, size_t msgsize)
{
printf("Test (%ld) memcpy of sizes (%ld) ....\n",
num, msgsize);
unsigned long i;
unsigned long long nstime;
struct timespec t1, t2, t3;
char *buf1=malloc (msgsize);
char *buf2=malloc (msgsize);
// measure
osa_now_timespec(&t1);
for (i=0; i<num; i++)
{
memcpy (buf1, buf2, msgsize);
}
// measure
osa_now_timespec(&t2);
osa_timediff(&t1, &t2, &t3);
free (buf2);
free (buf1);
nstime = osa_to_ns(&t3)/(unsigned long long) i;
printf("%ld memcpy. Time per memcpy: %llu [nsec] (%llu MB/sec)\n",
i, nstime,
(1000ULL * (unsigned long long) msgsize)/(nstime)) ;
fflush (stdout);
printf(" finished.\n");
fflush (stdout);
}
int main()
{
testMemcpy(10000, 1*1024);
testMemcpy(10000, 2*1024);
testMemcpy(10000, 4*1024);
testMemcpy(10000, 8*1024);
testMemcpy(10000, 16*1024);
testMemcpy(1000 , 32*1024);
testMemcpy(1000 , 50*1024);
testMemcpy(1000 , 100*1024);
testMemcpy( 100 , 1024*1024);
testMemcpy( 10 ,10*1024*1024);
testMemcpy( 5 ,50*1024*1024);
return 0;
}
^ permalink raw reply
* Re: [PATCH 3/9] powerpc/ppc32: Update mpc52xx_psc structure with B revision changes
From: Raquel Velasco and Bill Buck @ 2007-05-15 10:59 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Linux PPC dev ML
In-Reply-To: <4647F359.1060403@246tNt.com>
Sylvain, thanks.
http://bbrv.blogspot.com/2007/05/not-waiting-for-world-to-change-ii.html
Read through the post. Your effort is being applied to good use.
R&B
On May 14, 2007, at 12:27 AM, Sylvain Munaut wrote:
> Matt Sealey wrote:
>> Would a note next to these new fields be worth it? "5200B only" or
>> "reserved on 5200" or even create a new PSC structure for the old
>> processor and recast it in drivers that really want to support both
>> revisions of the CPU?
>>
> A comment next to them yes, that looks a good idea.
> A new structure certainly not.
>> Real nitpick:
>>
>> Setting the CCR on the MPC5200 (not B) now means you need to left
>> shift your required CCR values by 16 bits before applying them into
>> the field for the desired effect.
>>
>> If you were being lazy and just wanted to set some low-order bits
>> in the CCR on the 5200, with the old structure that's fine. With
>> the new structure, it will be writing into previously reserved
>> space on the 5200. The 5200B might work fine, unless it's a driver
>> someone missed, and is programming a value that should be in the
>> upper 16 bits of the new CCR, in which case now you have to left
>> shift by 16 bits.. :)
> I know about the ccr that's annoying.
> I guess I could make ccr a union and have it contains ccr16 and ccr32.
>
> Note that old driver will still work ... then most likely do
> out_be16(&psc->ccr, ...) and the &psc->ccr address didn't change. They
> will just have a warning because ccr is a u32 so &psc->ccr is a
> u32* and
> they give it to out_be16 ...
>
>
> Sylvain
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
Raquel and Bill
http://bbrv.blogspot.com
^ permalink raw reply
* Re: [PATCH 1/2] kbuild: Add "Section mismatch" warning whitelist for powerpc
From: Stephen Rothwell @ 2007-05-15 10:56 UTC (permalink / raw)
To: Satyam Sharma
Cc: Andrew Morton, Linus, Linux Kernel, linuxppc-dev, Sam Ravnborg
In-Reply-To: <a781481a0705150303y587ea18dt435f2fc45a671226@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
On Tue, 15 May 2007 15:33:50 +0530 "Satyam Sharma" <satyam.sharma@gmail.com> wrote:
>
> But I have slightly different (reversed) semantics for __init_refok
> in mind. Basically, we use __init_refok to annotate _callees_
> and not _callers_. In short, __init_refok is a _type_ of __init
> section that other sections can freely reference to, without
> modpost complaining about this. [ had suggested this in some
> previous thread earlier ]
But lots of __init routines cannot be called from just anywhere, it is
the special circumstances of some of the callers that makes the call from
non-init to init ok. So you need to mark the callers specially.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Rewrite IO allocation & mapping on powerpc64
From: Christoph Hellwig @ 2007-05-15 10:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <20070514075415.7999BDDEC8@ozlabs.org>
Some comments:
- the comment above __iounmap_at needs some updates
- instead of the fake vm_struct in __iounmap_at just changed the
calling conventions for unmap_vm_area to take a start and len
value - there's only two callers including the powerpc ioremap
code for this. At the same time it might also get a better name.
^ permalink raw reply
* Re: [RFC] [patch 2/2] powerpc 2.6.21-rt1: fix kernel hang and/or panic
From: Benjamin Herrenschmidt @ 2007-05-15 10:09 UTC (permalink / raw)
To: Tsutomu OWA; +Cc: linuxppc-dev, mingo, tglx
In-Reply-To: <yyiirau5v8g.wl@toshiba.co.jp>
On Tue, 2007-05-15 at 17:47 +0900, Tsutomu OWA wrote:
> > It occurs on 2.6.21 + patch-2.6.21-rt1 + series of patches that I posted
> > yesterday.
>
> I encountered the following error when doing netperf from other machine
> to Celleb running RT kernel. PREEPT_NONE kernel works just fine as well.
Hrm... sounds a bit weird. I wonder if there's a locking bug in the
driver in the first place.
Linas, what's your take ?
Ben.
> Unable to handle kernel paging request for data at address 0x00000009
> Faulting instruction address: 0xc000000000295434
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT SMP NR_CPUS=2 NUMA
> Modules linked in:
> NIP: C000000000295434 LR: C000000000295420 CTR: 0000000000000000
> REGS: c0000000095d6e30 TRAP: 0300 Not tainted (2.6.21-rc5-rt7)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000482 XER: 20000000
> DAR: 0000000000000009, DSISR: 0000000040000000
> TASK = c000000001e7c440[626] 'netserver' THREAD: c0000000095d4000 CPU: 0
> GPR00: 0000000000000800 C0000000095D70B0 C0000000005D77B8 0000000000000001
> GPR04: 0000000000000001 0000000000000000 C0000000095D7080 0000000000000000
> GPR08: C0000000095D7030 0000000000000000 C0000000095D7040 0000000000000000
> GPR12: FC69925300080D5D C0000000004DE680 0000000000000000 0000000000422208
> GPR16: 0000000000400000 0000000000420D10 0000000000000000 C0000000095D7C88
> GPR20: C000000001E7C440 0000000000000000 0000000000000001 C000000008ACEAE0
> GPR24: 0000000000000020 C000000000E50C80 0000000081F84C5E C000000001C00BE0
> GPR28: C000000001C05430 C000000001C00B80 C000000000570F30 C000000001FD1720
> NIP [C000000000295434] .spider_net_xmit+0x1dc/0x448
> LR [C000000000295420] .spider_net_xmit+0x1c8/0x448
> Call Trace:
> [C0000000095D70B0] [C000000000295420] .spider_net_xmit+0x1c8/0x448 (unreliable)
> [C0000000095D7160] [C000000000327EE8] .dev_hard_start_xmit+0x238/0x300
> [C0000000095D7200] [C00000000033A7F4] .__qdisc_run+0xdc/0x2a4
> [C0000000095D72B0] [C00000000032A948] .dev_queue_xmit+0x1b0/0x2fc
> [C0000000095D7350] [C00000000034B470] .ip_output+0x280/0x2d8
> [C0000000095D73F0] [C00000000034C6CC] .ip_queue_xmit+0x448/0x4d8
> [C0000000095D74F0] [C00000000035F6D8] .tcp_transmit_skb+0x850/0x8c0
> [C0000000095D75C0] [C00000000035C394] .__tcp_ack_snd_check+0x84/0xc0
> [C0000000095D7650] [C00000000035E114] .tcp_rcv_established+0x4f0/0x8ac
> [C0000000095D7700] [C000000000365B24] .tcp_v4_do_rcv+0x5c/0x448
> [C0000000095D77D0] [C00000000031C2C4] .release_sock+0x94/0x11c
> [C0000000095D7870] [C000000000354E7C] .tcp_recvmsg+0x374/0x8d8
> [C0000000095D7960] [C00000000031B8A0] .sock_common_recvmsg+0x5c/0x84
> [C0000000095D79F0] [C00000000031921C] .sock_recvmsg+0x110/0x15c
> [C0000000095D7C00] [C00000000031AA50] .sys_recvfrom+0xf0/0x174
> [C0000000095D7D90] [C000000000339368] .compat_sys_socketcall+0x178/0x214
> [C0000000095D7E30] [C000000000008634] syscall_exit+0x0/0x40
> Instruction dump:
> 60000000 81790088 901f000c 913f0018 913f0008 917f0004 48132e8d 60000000
> a019009e 2f800800 409e0038 e9390038 <88690009> 2f830006 419e0010 2f830011
>
> I suspect spidernet expects spin_lock_irqsave()/restore() to disable/enable
> interrupts in vain on RT kernel.
>
> This patch works fine as far as I've tested, but I feel it's a kind of
> workaround. Any comments, suggestions, patches are welcome.
>
> Thanks in advance
>
> Signed-off-by: Tsutomu OWA <tsutomu.owa@toshiba.co.jp>
> -- owa
>
> diff -rup linux-2.6.21-rt1/drivers/net/spider_net.c rt/drivers/net/spider_net.c
> --- linux-2.6.21-rt1/drivers/net/spider_net.c 2007-04-26 12:08:32.000000000 +0900
> +++ rt/drivers/net/spider_net.c 2007-05-07 14:11:24.000000000 +0900
> @@ -688,7 +688,6 @@ spider_net_prepare_tx_descr(struct spide
> struct spider_net_descr *descr;
> struct spider_net_hw_descr *hwdescr;
> dma_addr_t buf;
> - unsigned long flags;
>
> buf = pci_map_single(card->pdev, skb->data, skb->len, PCI_DMA_TODEVICE);
> if (pci_dma_mapping_error(buf)) {
> @@ -699,10 +698,8 @@ spider_net_prepare_tx_descr(struct spide
> return -ENOMEM;
> }
>
> - spin_lock_irqsave(&chain->lock, flags);
> descr = card->tx_chain.head;
> if (descr->next == chain->tail->prev) {
> - spin_unlock_irqrestore(&chain->lock, flags);
> pci_unmap_single(card->pdev, buf, skb->len, PCI_DMA_TODEVICE);
> return -ENOMEM;
> }
> @@ -717,7 +714,6 @@ spider_net_prepare_tx_descr(struct spide
>
> hwdescr->dmac_cmd_status =
> SPIDER_NET_DESCR_CARDOWNED | SPIDER_NET_DMAC_NOCS;
> - spin_unlock_irqrestore(&chain->lock, flags);
>
> if (skb->protocol == htons(ETH_P_IP) && skb->ip_summed == CHECKSUM_PARTIAL)
> switch (skb->nh.iph->protocol) {
> @@ -742,7 +738,6 @@ spider_net_set_low_watermark(struct spid
> {
> struct spider_net_descr *descr = card->tx_chain.tail;
> struct spider_net_hw_descr *hwdescr;
> - unsigned long flags;
> int status;
> int cnt=0;
> int i;
> @@ -768,7 +763,6 @@ spider_net_set_low_watermark(struct spid
> descr = descr->next;
>
> /* Set the new watermark, clear the old watermark */
> - spin_lock_irqsave(&card->tx_chain.lock, flags);
> descr->hwdescr->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
> if (card->low_watermark && card->low_watermark != descr) {
> hwdescr = card->low_watermark->hwdescr;
> @@ -776,7 +770,7 @@ spider_net_set_low_watermark(struct spid
> hwdescr->dmac_cmd_status & ~SPIDER_NET_DESCR_TXDESFLG;
> }
> card->low_watermark = descr;
> - spin_unlock_irqrestore(&card->tx_chain.lock, flags);
> +
> return cnt;
> }
>
> @@ -784,6 +778,7 @@ spider_net_set_low_watermark(struct spid
> * spider_net_release_tx_chain - processes sent tx descriptors
> * @card: adapter structure
> * @brutal: if set, don't care about whether descriptor seems to be in use
> + * @locked: if set, tx_chain locked is held by caller.
> *
> * returns 0 if the tx ring is empty, otherwise 1.
> *
> @@ -793,7 +788,7 @@ spider_net_set_low_watermark(struct spid
> * scheduled again (if we were scheduled) and will not loose initiative.
> */
> static int
> -spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
> +spider_net_release_tx_chain(struct spider_net_card *card, int brutal, int locked)
> {
> struct spider_net_descr_chain *chain = &card->tx_chain;
> struct spider_net_descr *descr;
> @@ -804,9 +799,11 @@ spider_net_release_tx_chain(struct spide
> int status;
>
> while (1) {
> - spin_lock_irqsave(&chain->lock, flags);
> + if (!locked)
> + spin_lock_irqsave(&chain->lock, flags);
> if (chain->tail == chain->head) {
> - spin_unlock_irqrestore(&chain->lock, flags);
> + if (!locked)
> + spin_unlock_irqrestore(&chain->lock, flags);
> return 0;
> }
> descr = chain->tail;
> @@ -821,7 +818,8 @@ spider_net_release_tx_chain(struct spide
>
> case SPIDER_NET_DESCR_CARDOWNED:
> if (!brutal) {
> - spin_unlock_irqrestore(&chain->lock, flags);
> + if (!locked)
> + spin_unlock_irqrestore(&chain->lock, flags);
> return 1;
> }
>
> @@ -842,7 +840,8 @@ spider_net_release_tx_chain(struct spide
> default:
> card->netdev_stats.tx_dropped++;
> if (!brutal) {
> - spin_unlock_irqrestore(&chain->lock, flags);
> + if (!locked)
> + spin_unlock_irqrestore(&chain->lock, flags);
> return 1;
> }
> }
> @@ -852,7 +851,9 @@ spider_net_release_tx_chain(struct spide
> skb = descr->skb;
> descr->skb = NULL;
> buf_addr = hwdescr->buf_addr;
> - spin_unlock_irqrestore(&chain->lock, flags);
> +
> + if (!locked)
> + spin_unlock_irqrestore(&chain->lock, flags);
>
> /* unmap the skb */
> if (skb) {
> @@ -916,18 +917,28 @@ spider_net_xmit(struct sk_buff *skb, str
> {
> int cnt;
> struct spider_net_card *card = netdev_priv(netdev);
> + unsigned long flags;
> +
> + if (!spin_trylock_irqsave(&card->tx_chain.lock, flags))
> + return NETDEV_TX_BUSY;
> + //? collision ? return NETDEV_TX_LOCKED;
>
> - spider_net_release_tx_chain(card, 0);
> + spider_net_release_tx_chain(card, 0, 1);
>
> if (spider_net_prepare_tx_descr(card, skb) != 0) {
> + spin_unlock_irqrestore(&card->tx_chain.lock, flags);
> card->netdev_stats.tx_dropped++;
> netif_stop_queue(netdev);
> return NETDEV_TX_BUSY;
> }
>
> cnt = spider_net_set_low_watermark(card);
> +
> + spin_unlock_irqrestore(&card->tx_chain.lock, flags);
> +
> if (cnt < 5)
> spider_net_kick_tx_dma(card);
> +
> return NETDEV_TX_OK;
> }
>
> @@ -943,11 +954,20 @@ spider_net_xmit(struct sk_buff *skb, str
> static void
> spider_net_cleanup_tx_ring(struct spider_net_card *card)
> {
> - if ((spider_net_release_tx_chain(card, 0) != 0) &&
> + unsigned long flags;
> +
> + if (!spin_trylock_irqsave(&card->tx_chain.lock, flags))
> + return;
> +
> + if ((spider_net_release_tx_chain(card, 0, 1) != 0) &&
> (card->netdev->flags & IFF_UP)) {
> + spin_unlock_irqrestore(&card->tx_chain.lock, flags);
> spider_net_kick_tx_dma(card);
> netif_wake_queue(card->netdev);
> - }
> + } else
> + spin_unlock_irqrestore(&card->tx_chain.lock, flags);
> +
> +
> }
>
> /**
> @@ -2092,7 +2112,7 @@ spider_net_stop(struct net_device *netde
> spider_net_disable_rxdmac(card);
>
> /* release chains */
> - spider_net_release_tx_chain(card, 1);
> + spider_net_release_tx_chain(card, 1, 0);
> spider_net_free_rx_chain_contents(card);
>
> spider_net_free_chain(card, &card->tx_chain);
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] kbuild: Add "Section mismatch" warning whitelist for powerpc
From: Satyam Sharma @ 2007-05-15 10:03 UTC (permalink / raw)
To: Li Yang-r58472
Cc: Andrew Morton, Sam Ravnborg, Linux Kernel, linuxppc-dev, Linus
In-Reply-To: <989B956029373F45A0B8AF0297081890B76040@zch01exm26.fsl.freescale.net>
On 5/15/07, Li Yang-r58472 <LeoLi@freescale.com> wrote:
> > [...]
> > Actually, once __init_refok comes in, would we need any other
> > whitelisting mechanism at all? I think the exception patterns in
> > secref_whitelist() and those two other whitelisting functions
> > (init_section_ref_ok and exit_section_ref_ok) could all be
> > subsumed and made redundant if / when __init_refok is used
> > in the actual sources.
>
> I don't think so. __init_refok can be used to mark special functions
> which are legitimate to reference .init.text/.init.data
But I have slightly different (reversed) semantics for __init_refok
in mind. Basically, we use __init_refok to annotate _callees_
and not _callers_. In short, __init_refok is a _type_ of __init
section that other sections can freely reference to, without
modpost complaining about this. [ had suggested this in some
previous thread earlier ]
The __init_refok-for-callees mechanism could be useful to
reduce duplication, having to mark lesser number of functions,
and also make most of those exception patterns in modpost.c
redundant.
Ultimately, we want modpost to shut up for some known false
positives. Currently we have 9 exception patterns, 'n' number
of special sections hard-coded in modpost.c, 3 whitelisting
functions and also the __init_refok thing that can be used
directly to mark functions in the sources. But modpost
doesn't really care _how_ a particular case got whitelisted.
Using _only_ the __init_refok (easily greppable in the sources)
annotation for callees could help keep all such special cases
manageable and in control, compared to several different ways
to dodge modpost warnings.
> but cannot be used to mark special sections.
Yes, so mark the special _callees_ as __init_refok.
^ permalink raw reply
* Re: arch/powerpc/sysdev: dumping ground or only for shared drivers?
From: Christian Krafft @ 2007-05-15 9:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <A903CF97-CD70-4F26-9AB3-E3194F391448@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
Hi,
On Thu, 10 May 2007 17:06:48 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
> unknown:
> pmi.c (should this be in drivers somewhere?)
This driver does the communication with the BMC (baseboard management controller)
via a couple of FPGA registers on some future powerpc hardware.
>
> - k
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Mit freundlichen Grüssen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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