* 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
* Re: USB Host support on MPC8536DS
From: Kumar Gala @ 2009-06-30 19:54 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev
In-Reply-To: <24267110.post@talk.nabble.com>
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
^ permalink raw reply
* Re: Direct MII connection between MPC8313 and VIRTEX FPGA
From: Grant Likely @ 2009-06-30 16:16 UTC (permalink / raw)
To: Frank Prepelica; +Cc: linuxppc-dev
In-Reply-To: <29DC34A6B43468409F5A371CFE34E849D7EF7B@ex01.ads.ubidyne.de>
On Tue, Jun 30, 2009 at 2:35 AM, Frank
Prepelica<Frank.Prepelica@ubidyne.com> wrote:
>> What kernel version are you using?
>
> We are using kernel version 2.6.24. I've searched for "current speed" in =
version 2.6.28.7 and I've found that string.
>
>> Yes, you need to modify the DTB. =A0You have a back to back MII
>> connection, not a phy, so you do *not* want to have a PHY node in the
>> device tree.
>
> Hmm, but I do have a "PHY", don't I?. The "PHY" will be emulated in the F=
PGA. Of course, it's not a physical PHY but it should look like one.
No, it sounds like you don't. If you've got a back-to-back MII
connection, then you can fix the link speed and you don't need to do
any form of PHY emulation. ie. you don't need to wire up the MDIO
pins.
> So, do I really need the remove the complete PHY description in the DTB?
yes.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix spin_event_timeout() to be robust over context switches
From: Timur Tabi @ 2009-06-30 15:02 UTC (permalink / raw)
To: Grant Likely, Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090629234035.12475.58493.stgit@localhost.localdomain>
On Mon, Jun 29, 2009 at 6:40 PM, Grant Likely<grant.likely@secretlab.ca> wr=
ote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Current implementation of spin_event_timeout can be interrupted by an
> IRQ or context switch after testing the condition, but before checking
> the timeout. =A0This can cause the loop to report a timeout when the
> condition actually became true in the middle.
>
> This patch adds one final check of the condition upon exit of the loop
> if the last test of the condition was still false.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Timur Tabi <timur@freescale.com>
Ben, please pick this up for the next rc of 2.6.31.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Grant Likely @ 2009-06-30 19:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <9e4733910906301133n4928cfc4h3ce4ee2aef53fa73@mail.gmail.com>
On Tue, Jun 30, 2009 at 12:33 PM, Jon Smirl<jonsmirl@gmail.com> wrote:
> On Tue, Jun 30, 2009 at 12:50 PM, Grant Likely<grant.likely@secretlab.ca>=
wrote:
>> On Tue, Jun 30, 2009 at 12:18 AM, Wolfram Sang<w.sang@pengutronix.de> wr=
ote:
>>>> +
>>>> + =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 n=
eeds at
>>> least to be mentioned in the patch description.
>>
>> Oops, that was sloppy. =A0Yes, I'll put this into a separate patch. =A0T=
hanks.
>
> 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.
I know exactly why it happened. spin_event_timeout() had a bug that
would cause it to report a false positive timeout. The bug is fixed
and queued for merging.
However, I still think this explicit clear should be applied. It is
just a cheap register read and it prevents the driver from getting
wedged after a timeout does event, for whatever reason.
g.
--=20
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: Grant Likely @ 2009-06-30 16:50 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 12:18 AM, Wolfram Sang<w.sang@pengutronix.de> wrote=
:
>> +
>> + =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.
Oops, that was sloppy. Yes, I'll put this into a separate patch. Thanks.
g.
^ permalink raw reply
* [PATCH] powerpc/86xx: Correct reading of information presented in cpuinfo
From: Martyn Welch @ 2009-06-30 14:32 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
/proc/cpuinfo should be showing the boards revision and the revision of the FPGA fitted. The functions currently used to access this information as incorrect.
Additionally the VME geographical address of the PPC9A and it's status as system contoller are available in the board registers. Show these in cpuinfo.
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/platforms/86xx/gef_ppc9a.c | 37 +++++++++++++++++++++++++------
1 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/gef_ppc9a.c b/arch/powerpc/platforms/86xx/gef_ppc9a.c
index 2efa052..287f7bd 100644
--- a/arch/powerpc/platforms/86xx/gef_ppc9a.c
+++ b/arch/powerpc/platforms/86xx/gef_ppc9a.c
@@ -102,8 +102,8 @@ static unsigned int gef_ppc9a_get_pcb_rev(void)
{
unsigned int reg;
- reg = ioread32(ppc9a_regs);
- return (reg >> 8) & 0xff;
+ reg = ioread32be(ppc9a_regs);
+ return (reg >> 16) & 0xff;
}
/* Return the board (software) revision */
@@ -111,8 +111,8 @@ static unsigned int gef_ppc9a_get_board_rev(void)
{
unsigned int reg;
- reg = ioread32(ppc9a_regs);
- return (reg >> 16) & 0xff;
+ reg = ioread32be(ppc9a_regs);
+ return (reg >> 8) & 0xff;
}
/* Return the FPGA revision */
@@ -120,8 +120,26 @@ static unsigned int gef_ppc9a_get_fpga_rev(void)
{
unsigned int reg;
- reg = ioread32(ppc9a_regs);
- return (reg >> 24) & 0xf;
+ reg = ioread32be(ppc9a_regs);
+ return reg & 0xf;
+}
+
+/* Return VME Geographical Address */
+static unsigned int gef_ppc9a_get_vme_geo_addr(void)
+{
+ unsigned int reg;
+
+ reg = ioread32be(ppc9a_regs + 0x4);
+ return reg & 0x1f;
+}
+
+/* Return VME System Controller Status */
+static unsigned int gef_ppc9a_get_vme_is_syscon(void)
+{
+ unsigned int reg;
+
+ reg = ioread32be(ppc9a_regs + 0x4);
+ return (reg >> 9) & 0x1;
}
static void gef_ppc9a_show_cpuinfo(struct seq_file *m)
@@ -131,10 +149,15 @@ static void gef_ppc9a_show_cpuinfo(struct seq_file *m)
seq_printf(m, "Vendor\t\t: GE Fanuc Intelligent Platforms\n");
seq_printf(m, "Revision\t: %u%c\n", gef_ppc9a_get_pcb_rev(),
- ('A' + gef_ppc9a_get_board_rev() - 1));
+ ('A' + gef_ppc9a_get_board_rev()));
seq_printf(m, "FPGA Revision\t: %u\n", gef_ppc9a_get_fpga_rev());
seq_printf(m, "SVR\t\t: 0x%x\n", svid);
+
+ seq_printf(m, "VME geo. addr\t: %u\n", gef_ppc9a_get_vme_geo_addr());
+
+ seq_printf(m, "VME syscon\t: %s\n",
+ gef_ppc9a_get_vme_is_syscon() ? "yes" : "no");
}
static void __init gef_ppc9a_nec_fixup(struct pci_dev *pdev)
^ permalink raw reply related
* Re: Can't boot 2.6.30 powerpc kernel under qemu.
From: Michael Ellerman @ 2009-06-30 14:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, linuxppc-dev, Jeremy Kerr, Rob Landley,
linux-kernel
In-Reply-To: <1246359020.31413.12.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]
On Tue, 2009-06-30 at 20:50 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-06-30 at 10:24 +1000, Michael Ellerman wrote:
> > On Mon, 2009-06-29 at 18:34 -0500, Rob Landley wrote:
> > > Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
> > > symbol wasn't set, and once I switched that on it started working again.
> >
> > What defconfig are you using? It sounds like maybe something should be
> > 'select'ing OF_BOOT_TRAMPOLINE.
>
> Right, pmac, pseries and chrp probably ... though I don't like select
> for a user-visible option, I'd rather fix things if I inadvertently
> forgot the "default y" here, after all, one may want to do a minimum
> kdump kernel without prom_init.c in it.
Yeah true. In that case there's not much to do, it's default y, and the
help text says "In case of doubt, say Y".
Rob, do you remember saying "no" to this option when it came up, or did
you run 'make <something defconfig>' and end up with it unset? The
latter would be a bug, the former would not :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Preemption question (4xx related)
From: Felix Radensky @ 2009-06-30 12:55 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Preemption is disabled on the vast majority of powerpc
targets. Are there any known problems in this area ?
I'd like to enable CONFIG_PREEMPT_VOLUNTARY on
AMCC 405EX target, to increase application responsiveness.
Is it a bad idea ?
--
View this message in context: http://www.nabble.com/Preemption-question-%284xx-related%29-tp24271342p24271342.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Can't boot 2.6.30 powerpc kernel under qemu.
From: Benjamin Herrenschmidt @ 2009-06-30 10:50 UTC (permalink / raw)
To: michael
Cc: Stephen Rothwell, linuxppc-dev, Jeremy Kerr, Rob Landley,
linux-kernel
In-Reply-To: <1246321478.4621.11.camel@concordia>
On Tue, 2009-06-30 at 10:24 +1000, Michael Ellerman wrote:
> On Mon, 2009-06-29 at 18:34 -0500, Rob Landley wrote:
> > Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
> > symbol wasn't set, and once I switched that on it started working again.
>
> What defconfig are you using? It sounds like maybe something should be
> 'select'ing OF_BOOT_TRAMPOLINE.
Right, pmac, pseries and chrp probably ... though I don't like select
for a user-visible option, I'd rather fix things if I inadvertently
forgot the "default y" here, after all, one may want to do a minimum
kdump kernel without prom_init.c in it.
Cheers,
Ben.
>
> > > linuxppc-dev@lists.ozlabs.org is the one you want for this:
> > >
> > > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> > Cool! Is there a reason it's hidden? (Or at least not listed in either
> > vger.kernel.org's list info page or in the "Maling lists" page linked from
> > ozlabs.org's top level web page.) Just curious, I couldn't find it when I
> > looked in the obvious (to me) places.
>
> It's not hidden, it's just in the process of moving from ozlabs.org to
> lists.ozlabs.org - and it's a bit hard to find in the process. I've
> updated the ozlabs.org page to point to it in the meantime.
>
> It's also in maintainers :D
>
> LINUX FOR POWERPC (32-BIT AND 64-BIT)
> P: Benjamin Herrenschmidt
> M: benh@kernel.crashing.org
> P: Paul Mackerras
> M: paulus@samba.org
> W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
> S: Supported
>
>
> cheers
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ 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