* Re: RapidIO - general questions
From: Jan Neskudla @ 2009-07-01 14:46 UTC (permalink / raw)
To: ext david.hagood@gmail.com
Cc: linuxppc-dev, ext Li Yang, linux-kernel, IDT - Kim, Chul
In-Reply-To: <bd421daddbfcd48f86096879ce621310.squirrel@localhost>
On Mon, 2009-06-29 at 10:44 -0500, ext david.hagood@gmail.com wrote:
> Do you know (and if you know, can you comment) if IDT is planning on
> offering RIO (and more importantly to me sRIO) chipsets that can be used
> on other architectures besides the various PPC chips with embedded sRIO
> controllers?
I am using only switches, and they are not fixed to any architecture.
You can use them independently to any MCU.
I do not know if they are planning to provides something more.
Jan
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Grant Likely @ 2009-07-01 14:44 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090701135547.GD3144@pengutronix.de>
On Wed, Jul 1, 2009 at 7:55 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
>
>> > Sorry, I didn't get it: Shall I test something specific?
>>
>> I don't own a touchscreen.
>>
>> AFAIK no one has ever plugged a touchscreen into the PCM-973 to see if
>> works since there hasn't been a driver previously.
>> Just do a general
>> test so that you can tell customers that it works.
>
> I am not sure, we have a suitable touchscreen. Also, I am afraid this is a bit
> too much to do besides my regular day work right now. Sorry.
I've now tested this on a client's board which uses the pcm030 with a
custom base board (based on the development board) which uses the same
codec. It works there. I don't have a discrete touchscreen to wire
up to the PCM-973 though.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Wolfram Sang @ 2009-07-01 13:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <9e4733910907010632g10706084o66720d4616e40865@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
> > Sorry, I didn't get it: Shall I test something specific?
>
> I don't own a touchscreen.
>
> AFAIK no one has ever plugged a touchscreen into the PCM-973 to see if
> works since there hasn't been a driver previously. Just do a general
> test so that you can tell customers that it works.
I am not sure, we have a suitable touchscreen. Also, I am afraid this is a bit
too much to do besides my regular day work right now. Sorry.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH Resend] Remove 'SBC8240 Wind River' Device Driver Code
From: Subrata Modak @ 2009-07-01 13:52 UTC (permalink / raw)
To: linux-mtd, dwmw2
Cc: carolyn.j.smith, Stephen Rothwell, Jim Cromie, David Woodhouse,
linux-kernel, Linuxppc-dev, Sachin P Sant, linux-next, Scott Wood,
Subrata Modak, Balbir Singh
Hi,
Linux next tree(20090626) produced the following build error:
CC [M] drivers/mtd/maps/sbc8240.o
drivers/mtd/maps/sbc8240.c:31:1: warning: "DEBUG" redefined
In file included from drivers/mtd/maps/sbc8240.c:23:
include/linux/mtd/mtd.h:333:1: warning: this is the location of the previous definition
drivers/mtd/maps/sbc8240.c: In function 'init_sbc8240_mtd':
drivers/mtd/maps/sbc8240.c:172: warning: passing argument 1 of 'simple_map_init' from incompatible pointer type
drivers/mtd/maps/sbc8240.c:177: error: 'struct mtd_info' has no member named 'module'
make[3]: *** [drivers/mtd/maps/sbc8240.o] Error 1
make[2]: *** [drivers/mtd/maps] Error 2
make[1]: *** [drivers/mtd] Error 2
make: *** [drivers] Error 2
I remember reporting this back in April, when it was suggested to remove
the code as it is no more used:
http://lkml.org/lkml/2009/4/21/476,
I tried to gather some more info about this driver from the link
mentioned in Kconfig:
http://www.windriver.com/products/sbc8240/,
without much success.
The original author of this driver code has no problem, as she has
expressed by the following mail:
>On Tue, 2009-06-30 at 09:37 -0700, carolyn.j.smith@tektronix.com wrote:
>Hello Subrata,
>
> I am the original author of this file and have no objection to its removal
> from the 2.6 kernel. I added it to the 2.4 kernel when I ported Linux to
> the SBC8240 board many years ago. I haven't used the board in several years.
>
> Regards,
> Carolyn
>
Last time i did not address: linux-mtd@lists.infradead.org. If there are
no issues, can you please apply this patch to remove it ?
To: linux-mtd@lists.infradead.org,
Cc: David Woodhouse <dwmw2@infradead.org>,
Cc: Scott Wood <scottwood@freescale.com>,
Cc: Jim Cromie <jim.cromie@gmail.com>,
Cc: carolyn.j.smith@exgate.tek.com,
Cc: dwmw2@infradead.org,
Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>,
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Cc: Linuxppc-dev <Linuxppc-dev@ozlabs.org>,
Cc: linux-next <linux-next@vger.kernel.org>,
--
Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
Tested-on-PPC64-by: Subrata Modak <subrata@linux.vnet.ibm.com>
---
diff -uprN a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
--- a/drivers/mtd/maps/Kconfig 2009-06-26 07:36:23.000000000 -0500
+++ b/drivers/mtd/maps/Kconfig 2009-06-26 07:39:34.000000000 -0500
@@ -284,13 +284,6 @@ config MTD_L440GX
BE VERY CAREFUL.
-config MTD_SBC8240
- tristate "Flash device on SBC8240"
- depends on MTD_JEDECPROBE && 8260
- help
- Flash access on the SBC8240 board from Wind River. See
- <http://www.windriver.com/products/sbc8240/>
-
config MTD_TQM8XXL
tristate "CFI Flash device mapped on TQM8XXL"
depends on MTD_CFI && TQM8xxL
diff -uprN a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
--- a/drivers/mtd/maps/Makefile 2009-06-26 07:36:23.000000000 -0500
+++ b/drivers/mtd/maps/Makefile 2009-06-26 07:40:03.000000000 -0500
@@ -50,7 +50,6 @@ obj-$(CONFIG_MTD_UCLINUX) += uclinux.o
obj-$(CONFIG_MTD_NETtel) += nettel.o
obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o
obj-$(CONFIG_MTD_H720X) += h720x-flash.o
-obj-$(CONFIG_MTD_SBC8240) += sbc8240.o
obj-$(CONFIG_MTD_IXP4XX) += ixp4xx.o
obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82xx_flash.o
diff -uprN a/drivers/mtd/maps/sbc8240.c b/drivers/mtd/maps/sbc8240.c
--- a/drivers/mtd/maps/sbc8240.c 2009-06-26 07:36:23.000000000 -0500
+++ b/drivers/mtd/maps/sbc8240.c 1969-12-31 18:00:00.000000000 -0600
@@ -1,250 +0,0 @@
-/*
- * Handle mapping of the flash memory access routines on the SBC8240 board.
- *
- * Carolyn Smith, Tektronix, Inc.
- *
- * This code is GPLed
- */
-
-/*
- * The SBC8240 has 2 flash banks.
- * Bank 0 is a 512 KiB AMD AM29F040B; 8 x 64 KiB sectors.
- * It contains the U-Boot code (7 sectors) and the environment (1 sector).
- * Bank 1 is 4 x 1 MiB AMD AM29LV800BT; 15 x 64 KiB sectors, 1 x 32 KiB sector,
- * 2 x 8 KiB sectors, 1 x 16 KiB sectors.
- * Both parts are JEDEC compatible.
- */
-
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <asm/io.h>
-
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/map.h>
-#include <linux/mtd/cfi.h>
-
-#ifdef CONFIG_MTD_PARTITIONS
-#include <linux/mtd/partitions.h>
-#endif
-
-#define DEBUG
-
-#ifdef DEBUG
-# define debugk(fmt,args...) printk(fmt ,##args)
-#else
-# define debugk(fmt,args...)
-#endif
-
-
-#define WINDOW_ADDR0 0xFFF00000 /* 512 KiB */
-#define WINDOW_SIZE0 0x00080000
-#define BUSWIDTH0 1
-
-#define WINDOW_ADDR1 0xFF000000 /* 4 MiB */
-#define WINDOW_SIZE1 0x00400000
-#define BUSWIDTH1 8
-
-#define MSG_PREFIX "sbc8240:" /* prefix for our printk()'s */
-#define MTDID "sbc8240-%d" /* for mtdparts= partitioning */
-
-
-static struct map_info sbc8240_map[2] = {
- {
- .name = "sbc8240 Flash Bank #0",
- .size = WINDOW_SIZE0,
- .bankwidth = BUSWIDTH0,
- },
- {
- .name = "sbc8240 Flash Bank #1",
- .size = WINDOW_SIZE1,
- .bankwidth = BUSWIDTH1,
- }
-};
-
-#define NUM_FLASH_BANKS ARRAY_SIZE(sbc8240_map)
-
-/*
- * The following defines the partition layout of SBC8240 boards.
- *
- * See include/linux/mtd/partitions.h for definition of the
- * mtd_partition structure.
- *
- * The *_max_flash_size is the maximum possible mapped flash size
- * which is not necessarily the actual flash size. It must correspond
- * to the value specified in the mapping definition defined by the
- * "struct map_desc *_io_desc" for the corresponding machine.
- */
-
-#ifdef CONFIG_MTD_PARTITIONS
-
-static struct mtd_partition sbc8240_uboot_partitions [] = {
- /* Bank 0 */
- {
- .name = "U-boot", /* U-Boot Firmware */
- .offset = 0,
- .size = 0x00070000, /* 7 x 64 KiB sectors */
- .mask_flags = MTD_WRITEABLE, /* force read-only */
- },
- {
- .name = "environment", /* U-Boot environment */
- .offset = 0x00070000,
- .size = 0x00010000, /* 1 x 64 KiB sector */
- },
-};
-
-static struct mtd_partition sbc8240_fs_partitions [] = {
- {
- .name = "jffs", /* JFFS filesystem */
- .offset = 0,
- .size = 0x003C0000, /* 4 * 15 * 64KiB */
- },
- {
- .name = "tmp32",
- .offset = 0x003C0000,
- .size = 0x00020000, /* 4 * 32KiB */
- },
- {
- .name = "tmp8a",
- .offset = 0x003E0000,
- .size = 0x00008000, /* 4 * 8KiB */
- },
- {
- .name = "tmp8b",
- .offset = 0x003E8000,
- .size = 0x00008000, /* 4 * 8KiB */
- },
- {
- .name = "tmp16",
- .offset = 0x003F0000,
- .size = 0x00010000, /* 4 * 16KiB */
- }
-};
-
-/* trivial struct to describe partition information */
-struct mtd_part_def
-{
- int nums;
- unsigned char *type;
- struct mtd_partition* mtd_part;
-};
-
-static struct mtd_info *sbc8240_mtd[NUM_FLASH_BANKS];
-static struct mtd_part_def sbc8240_part_banks[NUM_FLASH_BANKS];
-
-
-#endif /* CONFIG_MTD_PARTITIONS */
-
-
-static int __init init_sbc8240_mtd (void)
-{
- static struct _cjs {
- u_long addr;
- u_long size;
- } pt[NUM_FLASH_BANKS] = {
- {
- .addr = WINDOW_ADDR0,
- .size = WINDOW_SIZE0
- },
- {
- .addr = WINDOW_ADDR1,
- .size = WINDOW_SIZE1
- },
- };
-
- int devicesfound = 0;
- int i,j;
-
- for (i = 0; i < NUM_FLASH_BANKS; i++) {
- printk (KERN_NOTICE MSG_PREFIX
- "Probing 0x%08lx at 0x%08lx\n", pt[i].size, pt[i].addr);
-
- sbc8240_map[i].map_priv_1 =
- (unsigned long) ioremap (pt[i].addr, pt[i].size);
- if (!sbc8240_map[i].map_priv_1) {
- printk (MSG_PREFIX "failed to ioremap\n");
- for (j = 0; j < i; j++) {
- iounmap((void *) sbc8240_map[j].map_priv_1);
- sbc8240_map[j].map_priv_1 = 0;
- }
- return -EIO;
- }
- simple_map_init(&sbc8240_mtd[i]);
-
- sbc8240_mtd[i] = do_map_probe("jedec_probe", &sbc8240_map[i]);
-
- if (sbc8240_mtd[i]) {
- sbc8240_mtd[i]->module = THIS_MODULE;
- devicesfound++;
- } else {
- if (sbc8240_map[i].map_priv_1) {
- iounmap((void *) sbc8240_map[i].map_priv_1);
- sbc8240_map[i].map_priv_1 = 0;
- }
- }
- }
-
- if (!devicesfound) {
- printk(KERN_NOTICE MSG_PREFIX
- "No suppported flash chips found!\n");
- return -ENXIO;
- }
-
-#ifdef CONFIG_MTD_PARTITIONS
- sbc8240_part_banks[0].mtd_part = sbc8240_uboot_partitions;
- sbc8240_part_banks[0].type = "static image";
- sbc8240_part_banks[0].nums = ARRAY_SIZE(sbc8240_uboot_partitions);
- sbc8240_part_banks[1].mtd_part = sbc8240_fs_partitions;
- sbc8240_part_banks[1].type = "static file system";
- sbc8240_part_banks[1].nums = ARRAY_SIZE(sbc8240_fs_partitions);
-
- for (i = 0; i < NUM_FLASH_BANKS; i++) {
-
- if (!sbc8240_mtd[i]) continue;
- if (sbc8240_part_banks[i].nums == 0) {
- printk (KERN_NOTICE MSG_PREFIX
- "No partition info available, registering whole device\n");
- add_mtd_device(sbc8240_mtd[i]);
- } else {
- printk (KERN_NOTICE MSG_PREFIX
- "Using %s partition definition\n", sbc8240_part_banks[i].mtd_part->name);
- add_mtd_partitions (sbc8240_mtd[i],
- sbc8240_part_banks[i].mtd_part,
- sbc8240_part_banks[i].nums);
- }
- }
-#else
- printk(KERN_NOTICE MSG_PREFIX
- "Registering %d flash banks at once\n", devicesfound);
-
- for (i = 0; i < devicesfound; i++) {
- add_mtd_device(sbc8240_mtd[i]);
- }
-#endif /* CONFIG_MTD_PARTITIONS */
-
- return devicesfound == 0 ? -ENXIO : 0;
-}
-
-static void __exit cleanup_sbc8240_mtd (void)
-{
- int i;
-
- for (i = 0; i < NUM_FLASH_BANKS; i++) {
- if (sbc8240_mtd[i]) {
- del_mtd_device (sbc8240_mtd[i]);
- map_destroy (sbc8240_mtd[i]);
- }
- if (sbc8240_map[i].map_priv_1) {
- iounmap ((void *) sbc8240_map[i].map_priv_1);
- sbc8240_map[i].map_priv_1 = 0;
- }
- }
-}
-
-module_init (init_sbc8240_mtd);
-module_exit (cleanup_sbc8240_mtd);
-
-MODULE_LICENSE ("GPL");
-MODULE_AUTHOR ("Carolyn Smith <carolyn.smith@tektronix.com>");
-MODULE_DESCRIPTION ("MTD map driver for SBC8240 boards");
-
---
Regards--
Subrata
^ permalink raw reply
* RE: ppc405ex + gigabit ethernet
From: Cote, Sylvain @ 2009-07-01 13:25 UTC (permalink / raw)
To: lada.podivin@gmail.com, linuxppc-dev@ozlabs.org
In-Reply-To: <COL107-W41E84129BE81739BC96295B22E0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]
> Hi,
> I benchmarked performance of my network, which contains ppc405EX (Kilauea board, kernel 2.6.30 from Denx) connected with a linux desktop via gigabit ethernet. I used the > netperf tool:
> netperf -t UDP_STREAM -H 192.168.1.1 -- -m 32768
> So I was sending UDP packets to the desktop. The resulting speed was about 370 Kb/s. I tried to send the packets to several different computers - with the same result. So the >ppc board is the bottleneck in this case.
> Is there any possibility to improve the gigabit capabilities of the ppc405EX? Is there anyone who achieved a better performance with ppc4xx boards?
We have seen also bad performances with Gig Ethernet with ppc405ex. One optimisation we have done is interrupt coalescing in ibm_new_mac. This gives near 25% of txput gain. Unfortunately, this optimisation is not yet on denx git. We got it from AMCC directly. Also, it looks like that 2.6 kernel is much slower then 2.4 on ppc405ex. This is probably due to IPC and/or context switching. We have not yet found a solution to this. However, 370Kb/s (3Mbits/s) look like very poor. In the worst case with 100% CPU used to send UDP data on network with the ppc405ex 600MHz, we got 190Mbits/s on Gig eth. It looks like netperf does not stress the ppc405ex ant it network at is maximum.
Sylvain
________________________________
立刻下载 MSN 保护盾，保障 MSN 安全稳定！ 现在就下载！<http://im.live.cn/safe/>
This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries.
The information is intended to be for the use of the individual(s) or
entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
[-- Attachment #2: Type: text/html, Size: 6498 bytes --]
^ permalink raw reply
* RE: ppc405ex + gigabit ethernet
From: john.p.price @ 2009-07-01 13:26 UTC (permalink / raw)
To: Lada Podivin, LiuMing; +Cc: linuxppc-dev
In-Reply-To: <e35801cc0907010424l66a7c4dem6f3f363c3b194ff4@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="GB2312", Size: 2649 bytes --]
I have developed a board with the AMCC PPC405eX running at 600MHz and experimented with two transmission methods;
1. Raw socket w/jumbo frames ¨C approx. 600Mbits/sec
2. TCP using writev w/jumbo frames ¨C approx. 525Mbits/sec
From: linuxppc-dev-bounces+john.p.price=l-3com.com@lists.ozlabs.org [mailto:linuxppc-dev-bounces+john.p.price=l-3com.com@lists.ozlabs.org] On Behalf Of Lada Podivin
Sent: Wednesday, July 01, 2009 7:25 AM
To: LiuMing
Cc: linuxppc-dev@ozlabs.org
Subject: Re: ppc405ex + gigabit ethernet
Thank you for your reply!
Yes, I agree the CPU is the bottleneck. But I have performed more tests with the netperf tool and results seem strange to me. If I send 800 B of data, the resulting speed is aproximately 100 Kb/s. On the other hand, If I try to send 32KB chunk of data with jumbo frames turned on, resulting speed is about 600 Kb/s (300-400 without jumbo frames). My ppc405ex runs at 600 MHz.
So it seems that it is definetely better idea to call sendto() less frequently with bigger amounts of data, than to call it more often with smaler amounts. Is it because smaller data means more frequent user space/kernel space switching? Or is it network related issue?
Thanks!
Best,
Lada
2009/7/1 LiuMing <eemingliu@hotmail.com>
Hi,
According to our experience on PPC405 + Gigabit Enet, your result is already very reasonable. For UDP transmission, it can be around 400 Kb/s because of the CPU bottleneck (in our case 300 MHz ppc405). If you want to further improve it, a faster CPU is needed to process the TCP/IP stack, or you may buy commercial TCP/IP stack rather than using the free Linux one.
BR
Ming
________________________________
Date: Tue, 30 Jun 2009 15:58:53 +0200
Subject: ppc405ex + gigabit ethernet
From: lada.podivin@gmail.com
To: linuxppc-dev@ozlabs.org
Hi,
I benchmarked performance of my network, which contains ppc405EX (Kilauea board, kernel 2.6.30 from Denx) connected with a linux desktop via gigabit ethernet. I used the netperf tool:
netperf -t UDP_STREAM -H 192.168.1.1 -- -m 32768
So I was sending UDP packets to the desktop. The resulting speed was about 370 Kb/s. I tried to send the packets to several different computers - with the same result. So the ppc board is the bottleneck in this case.
Is there any possibility to improve the gigabit capabilities of the ppc405EX? Is there anyone who achieved a better performance with ppc4xx boards?
Thanks!
Best,
Lada Podivin
________________________________
Á¢¿ÌÏÂÔØ MSN ±£»¤¶Ü£¬±£ÕÏ MSN °²È«Îȶ¨£¡ ÏÖÔÚ¾ÍÏÂÔØ£¡ <http://im.live.cn/safe/>
[-- Attachment #2: Type: text/html, Size: 10727 bytes --]
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Jon Smirl @ 2009-07-01 13:32 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090701085633.GB3144@pengutronix.de>
On Wed, Jul 1, 2009 at 4:56 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> Hi Jon,
>
>> Wolfram, do you have any way to test the on the Phytec hardware? The
>> WM9712 on the baseboard supports a touchscreen, is it brought out to a
>> header?
>
> Sorry, I didn't get it: Shall I test something specific?
I don't own a touchscreen.
AFAIK no one has ever plugged a touchscreen into the PCM-973 to see if
works since there hasn't been a driver previously. Just do a general
test so that you can tell customers that it works.
>
> The touchscreen connector is X19 BTW (assuming a PCM-973 baseboard).
>
> Regards,
>
> =A0 Wolfram
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/ =A0|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkpLJMEACgkQD27XaX1/VRs/cwCgn7p7ffxr8WGoW7MwALkBMKtD
> VtYAoIa5/viinyvFF5cQP3BvH9WP3a5I
> =3DZrq3
> -----END PGP SIGNATURE-----
>
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Detlev Zundel @ 2009-07-01 12:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <97dd5fd20906301048o30354271haf603a9bae29b0fe@mail.gmail.com>
Hi,
> As for my device tree, I reverted back to the original version with
> nothing filled in and just replaced 0xfa20xxxx with 0xf000xxxx as Gary
> suggested earlier.
Would it be a problem to also dynamically fixup IMMR in the device tree
from U-Boot?
Cheers
Detlev
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: ppc405ex + gigabit ethernet
From: Lada Podivin @ 2009-07-01 12:56 UTC (permalink / raw)
To: LiuMing; +Cc: linuxppc-dev
In-Reply-To: <e35801cc0907010424l66a7c4dem6f3f363c3b194ff4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]
Eh! I mean Mb/s NOT Kb/s! Sorry!
2009/7/1 Lada Podivin <lada.podivin@gmail.com>
> Thank you for your reply!
> Yes, I agree the CPU is the bottleneck. But I have performed more tests
> with the netperf tool and results seem strange to me. If I send 800 B of
> data, the resulting speed is aproximately 100 Kb/s. On the other hand, If I
> try to send 32KB chunk of data with jumbo frames turned on, resulting speed
> is about 600 Kb/s (300-400 without jumbo frames). My ppc405ex runs at 600
> MHz.
>
> So it seems that it is definetely better idea to call sendto() less
> frequently with bigger amounts of data, than to call it more often with
> smaler amounts. Is it because smaller data means more frequent user
> space/kernel space switching? Or is it network related issue?
>
> Thanks!
>
> Best,
> Lada
>
> 2009/7/1 LiuMing <eemingliu@hotmail.com>
>
> Hi,
>> According to our experience on PPC405 + Gigabit Enet, your result is
>> already very reasonable. For UDP transmission, it can be around 400 Kb/s
>> because of the CPU bottleneck (in our case 300 MHz ppc405). If you want
>> to further improve it, a faster CPU is needed to process the TCP/IP stack,
>> or you may buy commercial TCP/IP stack rather than using the free Linux one.
>>
>>
>> BR
>> Ming
>>
>> ------------------------------
>> Date: Tue, 30 Jun 2009 15:58:53 +0200
>> Subject: ppc405ex + gigabit ethernet
>> From: lada.podivin@gmail.com
>> To: linuxppc-dev@ozlabs.org
>>
>>
>> Hi,
>>
>> I benchmarked performance of my network, which contains ppc405EX (Kilauea
>> board, kernel 2.6.30 from Denx) connected with a linux desktop via gigabit
>> ethernet. I used the netperf tool:
>>
>> netperf -t UDP_STREAM -H 192.168.1.1 -- -m 32768
>>
>> So I was sending UDP packets to the desktop. The resulting speed was about
>> 370 Kb/s. I tried to send the packets to several different computers - with
>> the same result. So the ppc board is the bottleneck in this case.
>>
>> Is there any possibility to improve the gigabit capabilities of the
>> ppc405EX? Is there anyone who achieved a better performance with ppc4xx
>> boards?
>>
>> Thanks!
>>
>> Best,
>> Lada Podivin
>>
>>
>> ------------------------------
>> 立刻下载 MSN 保护盾，保障 MSN 安全稳定！ 现在就下载！ <http://im.live.cn/safe/>
>>
>
>
[-- Attachment #2: Type: text/html, Size: 3043 bytes --]
^ permalink raw reply
* Re: ppc405ex + gigabit ethernet
From: Detlev Zundel @ 2009-07-01 12:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <e35801cc0906300658q45d5ea00ub939ba73185efd72@mail.gmail.com>
Hi Lada,
> Hi,
>
> I benchmarked performance of my network, which contains ppc405EX (Kilauea
> board, kernel 2.6.30 from Denx) connected with a linux desktop via gigabit
> ethernet. I used the netperf tool:
>
> netperf -t UDP_STREAM -H 192.168.1.1 -- -m 32768
>
> So I was sending UDP packets to the desktop. The resulting speed was about 370
> Kb/s. I tried to send the packets to several different computers - with the
> same result. So the ppc board is the bottleneck in this case.
>
> Is there any possibility to improve the gigabit capabilities of the ppc405EX?
> Is there anyone who achieved a better performance with ppc4xx boards?
On our kilauea in the lab:
-bash-3.2# src/netperf -t UDP_STREAM -p 7776 -H 192.168.1.1 -fK -- -m 32768
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1) port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
106496 32768 10.00 3601 0 11519.64
124928 10.00 3601 11519.64
-bash-3.2# grep cpu /proc/cpuinfo
cpu : 405EX
-bash-3.2# cat /proc/version
Linux version 2.6.29.4 (dzu@pollux.denx.de) (gcc version 4.2.2) #9 Wed Jun 17 11:18:46 CEST 2009
-bash-3.2#
I can send you the kernel+dtb that I used for testing offlist.
Cheers
Detlev
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* RE: [PATCH][v2] sata_fsl: Add asynchronous notification support
From: Kalra Ashish-B00888 @ 2009-07-01 12:26 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <4A4B1D8F.9090609@ru.mvista.com>
Hello Sergei,
It looks like that the email client has added these whitespaces and
alignment mess-up,
as the original patch file has none of these issues.=20
I will try using another email client and re-post the patch.
Thanks,
Ashish
-----Original Message-----
From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com]=20
Sent: Wednesday, July 01, 2009 1:56 PM
To: Kalra Ashish-B00888
Cc: linux-ide@vger.kernel.org; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH][v2] sata_fsl: Add asynchronous notification support
Hello.
ashish kalra wrote:
> Enable device hot-plug support on Port multiplier fan-out ports
>
> Signed-off-by: Ashish Kalra <Ashish.Kalra@freescale.com>
[...]
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index=20
> 94eaa43..5751145 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -34,7 +34,7 @@ enum {
>
> SATA_FSL_HOST_FLAGS =3D (ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
> ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
> - ATA_FLAG_PMP | ATA_FLAG_NCQ),
> + ATA_FLAG_PMP | ATA_FLAG_NCQ | ATA_FLAG_AN),
Why are you breaking the alignment? There's alos trailing whitespace
here...
> @@ -132,7 +132,7 @@ enum {
> INT_ON_SINGL_DEVICE_ERR =3D (1 << 1),
> INT_ON_CMD_COMPLETE =3D 1,
>
> - INT_ON_ERROR =3D INT_ON_FATAL_ERR |
> + INT_ON_ERROR =3D INT_ON_FATAL_ERR | INT_ON_SNOTIFY_UPDATE |
Trailing whitespace.
> @@ -154,6 +154,7 @@ enum {
>
> DEFAULT_PORT_IRQ_ENABLE_MASK =3D IE_ON_FATAL_ERR | =
IE_ON_PHYRDY_CHG
|
> IE_ON_SIGNATURE_UPDATE |
> + IE_ON_SNOTIFY_UPDATE |
Again.
> IE_ON_SINGL_DEVICE_ERR | IE_ON_CMD_COMPLETE,
>
> EXT_INDIRECT_SEG_PRD_FLAG =3D (1 << 31), @@ -1003,6 +1004,11 @@=20
> static void sata_fsl_error_intr(struct ata_port
> *ap)
> freeze =3D 1;
> }
>
> + /* Handle SDB FIS receive & notify update */
> + if (hstatus & INT_ON_SNOTIFY_UPDATE) {
> + sata_async_notification(ap);
> + }
And again -- on every line.
MBR, Sergei
^ permalink raw reply
* Re: ppc405ex + gigabit ethernet
From: Lada Podivin @ 2009-07-01 11:24 UTC (permalink / raw)
To: LiuMing; +Cc: linuxppc-dev
In-Reply-To: <COL107-W41E84129BE81739BC96295B22E0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]
Thank you for your reply!
Yes, I agree the CPU is the bottleneck. But I have performed more tests with
the netperf tool and results seem strange to me. If I send 800 B of data,
the resulting speed is aproximately 100 Kb/s. On the other hand, If I try to
send 32KB chunk of data with jumbo frames turned on, resulting speed is
about 600 Kb/s (300-400 without jumbo frames). My ppc405ex runs at 600 MHz.
So it seems that it is definetely better idea to call sendto() less
frequently with bigger amounts of data, than to call it more often with
smaler amounts. Is it because smaller data means more frequent user
space/kernel space switching? Or is it network related issue?
Thanks!
Best,
Lada
2009/7/1 LiuMing <eemingliu@hotmail.com>
> Hi,
> According to our experience on PPC405 + Gigabit Enet, your result is
> already very reasonable. For UDP transmission, it can be around 400 Kb/s
> because of the CPU bottleneck (in our case 300 MHz ppc405). If you want
> to further improve it, a faster CPU is needed to process the TCP/IP stack,
> or you may buy commercial TCP/IP stack rather than using the free Linux one.
>
>
> BR
> Ming
>
> ------------------------------
> Date: Tue, 30 Jun 2009 15:58:53 +0200
> Subject: ppc405ex + gigabit ethernet
> From: lada.podivin@gmail.com
> To: linuxppc-dev@ozlabs.org
>
>
> Hi,
>
> I benchmarked performance of my network, which contains ppc405EX (Kilauea
> board, kernel 2.6.30 from Denx) connected with a linux desktop via gigabit
> ethernet. I used the netperf tool:
>
> netperf -t UDP_STREAM -H 192.168.1.1 -- -m 32768
>
> So I was sending UDP packets to the desktop. The resulting speed was about
> 370 Kb/s. I tried to send the packets to several different computers - with
> the same result. So the ppc board is the bottleneck in this case.
>
> Is there any possibility to improve the gigabit capabilities of the
> ppc405EX? Is there anyone who achieved a better performance with ppc4xx
> boards?
>
> Thanks!
>
> Best,
> Lada Podivin
>
>
> ------------------------------
> 立刻下载 MSN 保护盾，保障 MSN 安全稳定！ 现在就下载！ <http://im.live.cn/safe/>
>
[-- Attachment #2: Type: text/html, Size: 2645 bytes --]
^ permalink raw reply
* RE: ppc405ex + gigabit ethernet
From: LiuMing @ 2009-07-01 10:19 UTC (permalink / raw)
To: lada.podivin, linuxppc-dev
In-Reply-To: <e35801cc0906300658q45d5ea00ub939ba73185efd72@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]
Hi,
According to our experience on PPC405 + Gigabit Enet, your result is already very reasonable. For UDP transmission, it can be around 400 Kb/s because of the CPU bottleneck (in our case 300 MHz ppc405). If you want to further improve it, a faster CPU is needed to process the TCP/IP stack, or you may buy commercial TCP/IP stack rather than using the free Linux one.
BR
Ming
Date: Tue, 30 Jun 2009 15:58:53 +0200
Subject: ppc405ex + gigabit ethernet
From: lada.podivin@gmail.com
To: linuxppc-dev@ozlabs.org
Hi,
I benchmarked performance of my network, which contains ppc405EX (Kilauea board, kernel 2.6.30 from Denx) connected with a linux desktop via gigabit ethernet. I used the netperf tool:
netperf -t UDP_STREAM -H 192.168.1.1 -- -m 32768
So I was sending UDP packets to the desktop. The resulting speed was about 370 Kb/s. I tried to send the packets to several different computers - with the same result. So the ppc board is the bottleneck in this case.
Is there any possibility to improve the gigabit capabilities of the ppc405EX? Is there anyone who achieved a better performance with ppc4xx boards?
Thanks!
Best,
Lada Podivin
_________________________________________________________________
MSN 表情魔法书，改变你的对话时代！
http://im.live.cn/emoticons/
[-- Attachment #2: Type: text/html, Size: 1580 bytes --]
^ permalink raw reply
* RapidIO - behavior after reboot
From: Thomas Moll @ 2009-07-01 9:36 UTC (permalink / raw)
To: ext Li Yang; +Cc: linuxppc-dev
Hi,
we are using an EP8548 eval board from Embedded Planet and we have a
problem with the RapidIO controller/Linux driver if we perform a reboot.
On the second boot phase (after reboot), Linux will always print the
following message when it loads the RapidIO driver: “RIO: doorbell queue
full”
We have debugged the RapidIO driver in Linux and we found out that the
problem is located in the setup function of the doorbells. On the second
boot phase after reboot, Linux will update dequeue/enqueue pointers to
the first entry in the ring, but this is maybe not allowed when the
doorbell controller is enabled (doorbell controller was already enabled
by the first boot).
We have checked all the registers of the RapidIO controller if they will
contain the reset value after a reboot, but the registers contain the
values that were used on the latest setting. We have checked the reset
behavior of the RapidIO controller by sending the HRESET_REQ signal and
with a reset generated by the Debug Control Register 0.
Do you have any idea how to solve the problem and maybe solve future
problems with enumeration?
You can find the log of the second boot on the bottom. You can also find
there the processor and core version of the used MPC8548 processor.
--Thomas
....
U-Boot 1.3.3 (Jul 17 2008 - 09:29:31)
CPU: 8548_E, Version: 1.1, (0x80390011)
Core: E500, Version: 1.0, (0x80210010)
Clock Configuration:
CPU:1000 MHz, CCB: 334 MHz,
DDR: 167 MHz (334 MT/s data rate), LBC: 41 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: EP8548
I2C: ready
DRAM: Initializing
Reusing current 256MB configuration
DDR: 256 MB
FLASH: 16 MB
L2 cache 512KB: already enabled.
In: serial
Out: serial
Err: serial
Net: eTSEC0, eTSEC1, eTSEC2, eTSEC3
Hit any key to stop autoboot: 0
Speed: 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 129.168.3.241
Using eTSEC0 device
TFTP from server 129.168.1.85; our IP address is 129.168.3.241
Filename '/quicc01/pImage'.
Load address: 0x1000000
Loading: #################################################################
################################
done
Bytes transferred = 1419118 (15a76e hex)
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-2.6.29.1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1419054 Bytes = 1.4 MB
Load Address: 00400000
Entry Point: 00400560
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory <- <0x0 0x10000000> (256MB)
ethernet0: local-mac-address <- 00:10:ec:00:b3:b0
CPU clock-frequency <- 0x3b9aa2f0 (1000MHz)
CPU timebase-frequency <- 0x27bc6ca (42MHz)
CPU bus-frequency <- 0x13de3650 (333MHz)
zImage starting: loaded at 0x00400000 (sp: 0x0ef7eae0)
Allocating 0x2fd488 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x006ffd84)...done 0x2df950 bytes
Linux/PowerPC load: root=/dev/nfs/ rw console=ttyS0,115200 ip=on
Finalizing device tree... flat tree at 0x70c300
Using EP8548 machine description
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.29.1 (thmoll@demmc3qc) (gcc version 3.4.3) #12 PREEMPT
Wed Jul 1 09:20:23 CEST 2009
Found legacy serial port 0 for /soc8548@e0000000/serial@4500
mem=e0004500, taddr=e0004500, irq=0, clk=333330000, speed=0
console [udbg0] enabled
setup_arch: bootmem
ep8548_setup_arch()
arch: exit
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal 0x00010000 -> 0x00010000
HighMem 0x00010000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00010000
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c02d8d84, node_mem_map c0300000
DMA zone: 512 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 65024 pages, LIFO batch:15
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs/ rw console=ttyS0,115200 ip=on
mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs
mpic: ISU size: 80, shift: 7, mask: 7f
mpic: Initializing for 80 sources
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 41.666250 MHz
time_init: processor frequency = 999.990000 MHz
clocksource: timebase mult[60003ef] shift[22] registered
clockevent: decrementer mult[aaa] shift[16] cpu[0]
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
High memory: 0k
Memory: 256512k/262144k available (2796k kernel code, 5364k reserved,
124k data, 117k bss, 152k init)
Calibrating delay loop... 83.20 BogoMIPS (lpj=166400)
Mount-cache hash table entries: 512
net_namespace: 296 bytes
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
NET: Registered protocol family 1
Setting up RapidIO peer-to-peer network /soc8548@e0000000/rapidio@c0000
fsl-of-rio e00c0000.rapidio: Of-device full name
/soc8548@e0000000/rapidio@c0000
fsl-of-rio e00c0000.rapidio: Regs start 0xe00c0000 size 0x20000
fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size
0x0000000020000000.
fsl-of-rio e00c0000.rapidio: bellirq: 50, txirq: 53, rxirq 54
fsl-of-rio e00c0000.rapidio: Overriding RIO_PORT setting to single lane 0
fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial
fsl-of-rio e00c0000.rapidio: Hardware port width: 4
fsl-of-rio e00c0000.rapidio: Training connection status: Four-lane
fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256
RIO: doorbell queue full
RIO: doorbell queue full
RIO: doorbell queue full
RIO: doorbell queue full
RIO: doorbell queue full
...
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Wolfram Sang @ 2009-07-01 8:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <9e4733910906300642o4f1c0e2cn45423c426e3aff7e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
Hi Jon,
> Wolfram, do you have any way to test the on the Phytec hardware? The
> WM9712 on the baseboard supports a touchscreen, is it brought out to a
> header?
Sorry, I didn't get it: Shall I test something specific?
The touchscreen connector is X19 BTW (assuming a PCM-973 baseboard).
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: USB Host support on MPC8536DS
From: Felix Radensky @ 2009-07-01 8:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <5D2C5D06-6637-41EC-A08A-27FF92DF18F2@kernel.crashing.org>
Hi, Kumar
Kumar Gala-3 wrote:
>
>
> On Jun 30, 2009, at 2:03 AM, Felix Radensky wrote:
>
>>
>> Hi,
>>
>> Is USB host functionality supported by mainline kernel on MPC8536DS ?
>> Are there any limitations (e.g not all host ports supported, etc.) ?
>
> It should be. If you have any issues let us know and we can see if we
> can help out.
>
> - k
> _______________________________________________
>
Thanks for a prompt reply. I'll get evaluation tomorrow
and will let you know if there are any issues.
Felix.
--
View this message in context: http://www.nabble.com/USB-Host-support-on-MPC8536DS-tp24267110p24286271.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH][v2] sata_fsl: Add asynchronous notification support
From: Sergei Shtylyov @ 2009-07-01 8:25 UTC (permalink / raw)
To: ashish kalra; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <Pine.WNT.4.64.0906292044150.5480@B00888-02.fsl.freescale.net>
Hello.
ashish kalra wrote:
> Enable device hot-plug support on Port multiplier fan-out ports
>
> Signed-off-by: Ashish Kalra <Ashish.Kalra@freescale.com>
[...]
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
> index 94eaa43..5751145 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -34,7 +34,7 @@ enum {
>
> SATA_FSL_HOST_FLAGS = (ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
> ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
> - ATA_FLAG_PMP | ATA_FLAG_NCQ),
> + ATA_FLAG_PMP | ATA_FLAG_NCQ | ATA_FLAG_AN),
Why are you breaking the alignment? There's alos trailing whitespace
here...
> @@ -132,7 +132,7 @@ enum {
> INT_ON_SINGL_DEVICE_ERR = (1 << 1),
> INT_ON_CMD_COMPLETE = 1,
>
> - INT_ON_ERROR = INT_ON_FATAL_ERR |
> + INT_ON_ERROR = INT_ON_FATAL_ERR | INT_ON_SNOTIFY_UPDATE |
Trailing whitespace.
> @@ -154,6 +154,7 @@ enum {
>
> DEFAULT_PORT_IRQ_ENABLE_MASK = IE_ON_FATAL_ERR | IE_ON_PHYRDY_CHG |
> IE_ON_SIGNATURE_UPDATE |
> + IE_ON_SNOTIFY_UPDATE |
Again.
> IE_ON_SINGL_DEVICE_ERR | IE_ON_CMD_COMPLETE,
>
> EXT_INDIRECT_SEG_PRD_FLAG = (1 << 31),
> @@ -1003,6 +1004,11 @@ static void sata_fsl_error_intr(struct ata_port
> *ap)
> freeze = 1;
> }
>
> + /* Handle SDB FIS receive & notify update */
> + if (hstatus & INT_ON_SNOTIFY_UPDATE) {
> + sata_async_notification(ap);
> + }
And again -- on every line.
MBR, Sergei
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Mikhail Zaturenskiy @ 2009-06-30 16:11 UTC (permalink / raw)
To: Scott Wood; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <4A492C1A.6020302@freescale.com>
> Check the clock-frequency of the CPM BRG node. =A0If u-boot isn't setting=
the
> memory, it's probably not setting this either.
I set the CPM BRG "clock-frequency =3D <153609>" (value obtained from
u-boot's 'brginfo' command), set my CPU "clock-frequency =3D
<100000000>" (down from 130000000) to match what u-boot is using, and
used the "console=3DttyCPM0,9600n8" boot arg and I've finally got
console output! Thanks everyone!
I'll still try to figure out how to get u-boot to fill all this in.
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Mikhail Zaturenskiy @ 2009-06-30 17:48 UTC (permalink / raw)
To: Scott Wood; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <97dd5fd20906300911k7b1e72banf61bcb9ff500787@mail.gmail.com>
> I'll still try to figure out how to get u-boot to fill all this in.
Got it... thanks to
"http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg05111.html"
I made sure that CONFIG_OF_LIBFDT and CONFIG_OF_BOARD_SETUP were both
present in "u-boot-2009.03/include/configs/EP88x.h". Then added the
following to the very end of "u-boot-2009.03/board/ep88x/ep88x.c":
#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
I suppose I could have put this code in w/o the "#if defined..." and
forget about the "CONFIG_OF_BOARD_SETUP" flag since I'm not really
using the "fdt boardsetup" command, but whatever.
As for my device tree, I reverted back to the original version with
nothing filled in and just replaced 0xfa20xxxx with 0xf000xxxx as Gary
suggested earlier.
Once again, thanks to all those who offered suggestions!
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Grant Likely @ 2009-06-30 16:53 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090630085917.GA13961@sirena.org.uk>
On Tue, Jun 30, 2009 at 2:59 AM, Mark
Brown<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Jun 29, 2009 at 08:26:12PM -0400, Jon Smirl wrote:
>
>> Does your touchscreen driver use this mutex? Or was this mutex needed
>> just for the AC97 driver?
>
> It's in the register accesses so everything accessing the chip registers
> will use it.
The mutexes are needed. The ac97 bus doesn't have any knowledge about
what codec(s) will be wired up to it so it must protect against
multiple access. In my case both the wm9712 audio codec driver and
the wm9712 touchscreen driver perform register accesses.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* ppc405ex + gigabit ethernet
From: Lada Podivin @ 2009-06-30 13:58 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
Hi,
I benchmarked performance of my network, which contains ppc405EX (Kilauea
board, kernel 2.6.30 from Denx) connected with a linux desktop via gigabit
ethernet. I used the netperf tool:
netperf -t UDP_STREAM -H 192.168.1.1 -- -m 32768
So I was sending UDP packets to the desktop. The resulting speed was about
370 Kb/s. I tried to send the packets to several different computers - with
the same result. So the ppc board is the bottleneck in this case.
Is there any possibility to improve the gigabit capabilities of the
ppc405EX? Is there anyone who achieved a better performance with ppc4xx
boards?
Thanks!
Best,
Lada Podivin
[-- Attachment #2: Type: text/html, Size: 685 bytes --]
^ permalink raw reply
* [PATCH] powerpc/86xx: Enable XMC site on GE Fanuc SBC310
From: Martyn Welch @ 2009-06-30 14:32 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
This patch enables the XMC (PCIe daughter card) site on the SBC310.
STG enter the description for the patch above.
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/boot/dts/gef_sbc310.dts | 37 ++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts b/arch/powerpc/boot/dts/gef_sbc310.dts
index 0f4c9ec..7810ea9 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -376,4 +376,41 @@
0x0 0x00400000>;
};
};
+
+ pci1: pcie@fef09000 {
+ compatible = "fsl,mpc8641-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xfef09000 0x1000>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x02000000 0x0 0xc0000000 0xc0000000 0x0 0x20000000
+ 0x01000000 0x0 0x00000000 0xfe400000 0x0 0x00400000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <0x19 0x2>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+ 0x0000 0x0 0x0 0x1 &mpic 0x4 0x2
+ 0x0000 0x0 0x0 0x2 &mpic 0x5 0x2
+ 0x0000 0x0 0x0 0x3 &mpic 0x6 0x2
+ 0x0000 0x0 0x0 0x4 &mpic 0x7 0x2
+ >;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x02000000 0x0 0xc0000000
+ 0x02000000 0x0 0xc0000000
+ 0x0 0x20000000
+
+ 0x01000000 0x0 0x00000000
+ 0x01000000 0x0 0x00000000
+ 0x0 0x00400000>;
+ };
+ };
+
};
^ permalink raw reply related
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Jon Smirl @ 2009-06-30 13:42 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090630061847.GA24164@pengutronix.de>
On Tue, Jun 30, 2009 at 2:18 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
Wolfram, do you have any way to test the on the Phytec hardware? The
WM9712 on the baseboard supports a touchscreen, is it brought out to a
header?
> Hi Grant,
>
> On Mon, Jun 29, 2009 at 05:42:21PM -0600, Grant Likely wrote:
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> AC97 bus register read/write hooks need to provide locking, but the
>> mpc5200-psc-ac97 driver does not. =A0This patch adds a mutex around
>> the register access routines.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> =A0sound/soc/fsl/mpc5200_dma.c =A0 =A0 =A0| =A0 =A01 +
>> =A0sound/soc/fsl/mpc5200_dma.h =A0 =A0 =A0| =A0 =A01 +
>> =A0sound/soc/fsl/mpc5200_psc_ac97.c | =A0 17 ++++++++++++++++-
>> =A03 files changed, 18 insertions(+), 1 deletions(-)
>>
>>
>> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
>> index efec33a..f0a2d40 100644
>> --- a/sound/soc/fsl/mpc5200_dma.c
>> +++ b/sound/soc/fsl/mpc5200_dma.c
>> @@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>>
>> =A0 =A0 =A0 spin_lock_init(&psc_dma->lock);
>> + =A0 =A0 mutex_init(&psc_dma->mutex);
>> =A0 =A0 =A0 psc_dma->id =3D be32_to_cpu(*prop);
>> =A0 =A0 =A0 psc_dma->irq =3D irq;
>> =A0 =A0 =A0 psc_dma->psc_regs =3D regs;
>> diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
>> index 2000803..8d396bb 100644
>> --- a/sound/soc/fsl/mpc5200_dma.h
>> +++ b/sound/soc/fsl/mpc5200_dma.h
>> @@ -55,6 +55,7 @@ struct psc_dma {
>> =A0 =A0 =A0 unsigned int irq;
>> =A0 =A0 =A0 struct device *dev;
>> =A0 =A0 =A0 spinlock_t lock;
>> + =A0 =A0 struct mutex mutex;
>> =A0 =A0 =A0 u32 sicr;
>> =A0 =A0 =A0 uint sysclk;
>> =A0 =A0 =A0 int imr;
>> diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_ps=
c_ac97.c
>> index 794a247..7eb5499 100644
>> --- a/sound/soc/fsl/mpc5200_psc_ac97.c
>> +++ b/sound/soc/fsl/mpc5200_psc_ac97.c
>> @@ -34,13 +34,20 @@ static unsigned short psc_ac97_read(struct snd_ac97 =
*ac97, unsigned short reg)
>> =A0 =A0 =A0 int status;
>> =A0 =A0 =A0 unsigned int val;
>>
>> + =A0 =A0 mutex_lock(&psc_dma->mutex);
>> +
>> =A0 =A0 =A0 /* Wait for command send status zero =3D ready */
>> =A0 =A0 =A0 status =3D spin_event_timeout(!(in_be16(&psc_dma->psc_regs->=
sr_csr.status) &
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPC52xx_PSC_=
SR_CMDSEND), 100, 0);
>> =A0 =A0 =A0 if (status =3D=3D 0) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("timeout on ac97 bus (rdy)\n");
>> + =A0 =A0 =A0 =A0 =A0 =A0 mutex_unlock(&psc_dma->mutex);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>> =A0 =A0 =A0 }
>> +
>> + =A0 =A0 /* Force clear the data valid bit */
>> + =A0 =A0 in_be32(&psc_dma->psc_regs->ac97_data);
>> +
>
> No mutex involved here. I think this is either a seperate patch or it nee=
ds at
> least to be mentioned in the patch description.
>
>> =A0 =A0 =A0 /* Send the read */
>> =A0 =A0 =A0 out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7=
f) << 24));
>>
>> @@ -50,16 +57,19 @@ static unsigned short psc_ac97_read(struct snd_ac97 =
*ac97, unsigned short reg)
>> =A0 =A0 =A0 if (status =3D=3D 0) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("timeout on ac97 read (val) %x\n",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in_be16(&psc=
_dma->psc_regs->sr_csr.status));
>> + =A0 =A0 =A0 =A0 =A0 =A0 mutex_unlock(&psc_dma->mutex);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>> =A0 =A0 =A0 }
>> =A0 =A0 =A0 /* Get the data */
>> =A0 =A0 =A0 val =3D in_be32(&psc_dma->psc_regs->ac97_data);
>> =A0 =A0 =A0 if (((val >> 24) & 0x7f) !=3D reg) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("reg echo error on ac97 read\n");
>> + =A0 =A0 =A0 =A0 =A0 =A0 mutex_unlock(&psc_dma->mutex);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>> =A0 =A0 =A0 }
>> =A0 =A0 =A0 val =3D (val >> 8) & 0xffff;
>>
>> + =A0 =A0 mutex_unlock(&psc_dma->mutex);
>> =A0 =A0 =A0 return (unsigned short) val;
>> =A0}
>>
>> @@ -68,16 +78,21 @@ static void psc_ac97_write(struct snd_ac97 *ac97,
>> =A0{
>> =A0 =A0 =A0 int status;
>>
>> + =A0 =A0 mutex_lock(&psc_dma->mutex);
>> +
>> =A0 =A0 =A0 /* Wait for command status zero =3D ready */
>> =A0 =A0 =A0 status =3D spin_event_timeout(!(in_be16(&psc_dma->psc_regs->=
sr_csr.status) &
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPC52xx_PSC_=
SR_CMDSEND), 100, 0);
>> =A0 =A0 =A0 if (status =3D=3D 0) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("timeout on ac97 bus (write)\n");
>> - =A0 =A0 =A0 =A0 =A0 =A0 return;
>> + =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>> =A0 =A0 =A0 }
>> =A0 =A0 =A0 /* Write data */
>> =A0 =A0 =A0 out_be32(&psc_dma->psc_regs->ac97_cmd,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((reg & 0x7f) << 24) | (val =
<< 8));
>> +
>> + out:
>> + =A0 =A0 mutex_unlock(&psc_dma->mutex);
>> =A0}
>>
>> =A0static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/ =A0|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkpJrkcACgkQD27XaX1/VRsY/QCgyx8IMANjokbNnrOQlXINRLeW
> lT4AnAy3ES9r3wriGkRN7ivnLA3zyRHb
> =3DRUPr
> -----END PGP SIGNATURE-----
>
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Jon Smirl @ 2009-06-30 18:33 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <fa686aa40906300950m15b7d48av953c0c738f6bf0e7@mail.gmail.com>
On Tue, Jun 30, 2009 at 12:50 PM, Grant Likely<grant.likely@secretlab.ca> w=
rote:
> On Tue, Jun 30, 2009 at 12:18 AM, Wolfram Sang<w.sang@pengutronix.de> wro=
te:
>>> +
>>> + =A0 =A0 /* Force clear the data valid bit */
>>> + =A0 =A0 in_be32(&psc_dma->psc_regs->ac97_data);
>>> +
>>
>> No mutex involved here. I think this is either a separate patch or it ne=
eds at
>> least to be mentioned in the patch description.
>
> Oops, that was sloppy. =A0Yes, I'll put this into a separate patch. =A0Th=
anks.
Now that you have added the mutexes, do you ever need to force clear
the valid bit?
Maybe log an error if this happens so that we can track down why.
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Mark Brown @ 2009-06-30 13:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910906300642o4f1c0e2cn45423c426e3aff7e@mail.gmail.com>
On Tue, Jun 30, 2009 at 09:42:06AM -0400, Jon Smirl wrote:
> Wolfram, do you have any way to test the on the Phytec hardware? The
> WM9712 on the baseboard supports a touchscreen, is it brought out to a
> header?
You can probably test adequately by writing a dummy AC97 driver that
sits in a thread and does reads (which should be all that's required to
test the interaction).
^ 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