* Re: windfarm got signal
From: Benjamin Herrenschmidt @ 2006-06-22 6:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, linux-pm
In-Reply-To: <1150847482.16662.13.camel@johannes>
On Wed, 2006-06-21 at 01:51 +0200, Johannes Berg wrote:
> Hey,
>
> after cpu hotplug I decided to write some fake suspend routines for
> ppc64 that always fail to see what all the drivers would say... The
> first thing I saw was during the phase where all threads are stopped,
> that windfarm got a signal!
>
> Shortly after that, the fans were revved up fully but I guess that's
> expected if the wf control loop exits.
>
> So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> expected with pm and windfarm just does the wrong thing there by taking
> the signal as a reason to exit the control thread?
>
> [code in question is windfarm_core.c:wf_thread_func]
I think it's the way the freezer works ... it sends a pseudo signal to
all kernel threads who are then supposed to do something like test for
PF_FREEZE or something like that.
Ben.
^ permalink raw reply
* Re: Linux on Virtex4
From: Filippo Capurso @ 2006-06-22 7:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0606210055m71277d1fl66dacfa7cd7ed203@mail.gmail.com>
Hi Grant,
Thank you for your kind answer.
> Yes, I had seen your message; but I'm not an expert on the 4xx mmu. I
> haven't seen that behaviour on my board.
>
> Double check your memory ranges. Have you given the kernel real RAM?
I'll investigate further on that...
Anyway, is your porting to the ML403 intended to work on Xilinx
reference design? I haven't exactly this design on my Virtex-4 because
I've remapped the flash memory to the end of the CPU address space in
order to execute automatically U-Boot after the configuration process...
also, obviously, I haven't any BRAM on this design (it was mapped at the
end of the address space).
The only thing that I've done to recompile the kernel for my project is
replacing the xparameters_ml403.h file with the EDK generated one. Is
this correct? Other things to do? My aim just now is to get a working
kernel with serial port support only.
Thank you.
Filippo Capurso
--
DAVE Srl - Electronics System House
via Forniz 2/1
33080 Porcia (PN) - Italy
Telephone: +39.0434.921215
Telefax: +39.0434.1994030
Freefax: +39.02.700520062
web: www.dave-tech.it
e-mail: filippo.capurso@dave-tech.it
how to reach us: http://mail.map24.com/dave
^ permalink raw reply
* Re: [PATCH 1/3] PAL: Support of the fixed PHY
From: Vitaly Bordug @ 2006-06-22 8:39 UTC (permalink / raw)
To: Michael Buesch; +Cc: netdev, linux-kernel, Jeff Garzik, linuxppc-embedded
In-Reply-To: <200606212248.27836.mb@bu3sch.de>
На Wed, 21 Jun 2006 22:48:27 +0200
Michael Buesch <mb@bu3sch.de> записано:
> On Wednesday 21 June 2006 18:09, Vitaly Bordug wrote:
>
> > +static int fixed_mdio_update_regs(struct fixed_info *fixed)
> > +{
> > + u16 *regs = fixed->regs;
> > + u16 bmsr = 0;
> > + u16 bmcr = 0;
> > +
> > + if(!regs) {
> > + printk(KERN_ERR "%s: regs not set up",
> > __FUNCTION__);
> > + return -1;
>
> -EINVAL perhaps?
>
OK
> > +static int fixed_mdio_register_device(int number, int speed, int
> > duplex) +{
> > + struct mii_bus *new_bus;
> > + struct fixed_info *fixed;
> > + struct phy_device *phydev;
> > + int err = 0;
> > +
> > + struct device* dev = kzalloc(sizeof(struct device),
> > GFP_KERNEL); +
> > + if (NULL == dev)
> > + return -EINVAL;
>
> -ENOMEM here.
OK
[snip]
> > + /*
> > + the mdio bus has phy_id match... In order not to do it
> > + artificially, we are binding the driver here by hand;
> > + it will be the same
> > + for all the fixed phys anyway.
> > + */
> > + down_write(&phydev->dev.bus->subsys.rwsem);
> > +
> > + phydev->dev.driver = &fixed_mdio_driver.driver;
> > +
> > + err = phydev->dev.driver->probe(&phydev->dev);
> > + if(err < 0) {
> > + printk(KERN_ERR "Phy %s: problems with fixed
> > driver\n",
> > + phydev->dev.bus_id);
> > + up_write(&phydev->dev.bus->subsys.rwsem);
> > + goto bus_register_fail;
>
> Probably need some additional error unwinding code.
> Of doesn't device_register() have to be reverted?
> What about phy_device_create()?
>
Definitely. Moreover, as I noticed now, phy_driver_register also has to
be error-handled and such. Will fix/update and resubmit.
Thanks for the feedback.
--
Sincerely, Vitaly
^ permalink raw reply
* entry point of kernel in RAM at 0x0c--linux tree file name
From: Arun Kumar @ 2006-06-22 8:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
Hi ,
I would like to kow what is the entry point to kernel at 0x000 after
decompressing and passing control to 0x0c .
My kernel crashes somewhere after uncomressing and jumping to 0x0c .
If any one can help the .c /.S file that contains the source of kernel
startup code in RAM at 0x0/0x0c .
thanks,
Arun
[-- Attachment #2: Type: text/html, Size: 333 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Jimi Xenidis @ 2006-06-22 10:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20060621235156.GA5414@pb15.lixom.net>
On Jun 21, 2006, at 7:51 PM, Olof Johansson wrote:
> On Wed, Jun 21, 2006 at 07:15:55PM -0400, Jimi Xenidis wrote:
>>
>> The following patch avoids accessing Hypervisor privilege HID
>> registers when running on a Hypervisor (MSR[HV]=0).
>
> I'm curious, why is this causing problems now?
Every once in a while I run Xen on one of our simulators thats is
sensitive to this code that does this.
First time we hit it (a while ago) we discovered that mtsdr1 was used
(even though a no-op)
> JS20 has been running
> that code with a hypervisor since a long time back.
970s consider this a no-op (I believe an expensive one) especially
when you consider some of the synchronization issues around the mtspr
HIDx.
And though this is 970 specific code, Cell and future processors,
will no longer allow writing to to these registers if !(MSR[0]=1 &&
MSR[PR]=0)
-JX
^ permalink raw reply
* Re: [linux-pm] windfarm got signal
From: Johannes Berg @ 2006-06-22 11:13 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, linuxppc-dev list
In-Reply-To: <200606221303.19860.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
On Thu, 2006-06-22 at 13:03 +0200, Rafael J. Wysocki wrote:
> > I think it's the way the freezer works ... it sends a pseudo signal to
> > all kernel threads who are then supposed to do something like test for
> > PF_FREEZE or something like that.
>
> Yes. More precisely, they are supposed to use try_to_freeze().
>
> Please see Documentation/power/kernel_threads.txt.
Thanks, I'll look and submit a patch. It does try_to_freeze() but also
checks for pending signals.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [linux-pm] windfarm got signal
From: Rafael J. Wysocki @ 2006-06-22 11:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Johannes Berg, linux-pm
In-Reply-To: <1150956123.3633.23.camel@localhost.localdomain>
On Thursday 22 June 2006 08:02, Benjamin Herrenschmidt wrote:
> On Wed, 2006-06-21 at 01:51 +0200, Johannes Berg wrote:
> > Hey,
> >
> > after cpu hotplug I decided to write some fake suspend routines for
> > ppc64 that always fail to see what all the drivers would say... The
> > first thing I saw was during the phase where all threads are stopped,
> > that windfarm got a signal!
> >
> > Shortly after that, the fans were revved up fully but I guess that's
> > expected if the wf control loop exits.
> >
> > So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> > expected with pm and windfarm just does the wrong thing there by taking
> > the signal as a reason to exit the control thread?
> >
> > [code in question is windfarm_core.c:wf_thread_func]
>
> I think it's the way the freezer works ... it sends a pseudo signal to
> all kernel threads who are then supposed to do something like test for
> PF_FREEZE or something like that.
Yes. More precisely, they are supposed to use try_to_freeze().
Please see Documentation/power/kernel_threads.txt.
Greetings,
Rafael
^ permalink raw reply
* Re: [linux-pm] windfarm got signal
From: Johannes Berg @ 2006-06-22 11:34 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linuxppc-dev list, linux-pm
In-Reply-To: <1150974836.16258.29.camel@johannes>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
> Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> checks for pending signals.
Ah. The code is just in the wrong order:
while (!kthread_should_stop()) {
try_to_freeze();
...
schedule_timeout_interruptible(...);
if (signal_pending())
break;
}
Would it be correct to just move the try_to_freeze() before the
signal_pending() statement?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Benjamin Herrenschmidt @ 2006-06-22 12:09 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <6BBF4F7C-1375-41FF-8D42-43BEC67194CC@watson.ibm.com>
On Thu, 2006-06-22 at 06:58 -0400, Jimi Xenidis wrote:
> 970s consider this a no-op (I believe an expensive one) especially
> when you consider some of the synchronization issues around the mtspr
> HIDx.
> And though this is 970 specific code, Cell and future processors,
> will no longer allow writing to to these registers if !(MSR[0]=1 &&
> MSR[PR]=0)
Fair enough, let's fix it.
Ben.
^ permalink raw reply
* Re: [linux-pm] windfarm got signal
From: Nigel Cunningham @ 2006-06-22 12:33 UTC (permalink / raw)
To: linux-pm; +Cc: Rafael J. Wysocki, linuxppc-dev list, Johannes Berg
In-Reply-To: <1150976092.16258.33.camel@johannes>
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Hi.
On Thursday 22 June 2006 21:34, Johannes Berg wrote:
> On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
> > Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> > checks for pending signals.
>
> Ah. The code is just in the wrong order:
> while (!kthread_should_stop()) {
> try_to_freeze();
> ...
> schedule_timeout_interruptible(...);
> if (signal_pending())
> break;
> }
>
> Would it be correct to just move the try_to_freeze() before the
> signal_pending() statement?
Hmm. Will kthread_should_stop() be set if it should really exit? If so,
perhaps you can just remove the signal_pending() check. Otherwise, you'd want
to change the signal_pending() test to something like the "if
(signal_pending() && !try_to_freeze())" to avoid any possibility of a race.
(In this case, you should be able to remove the try_to_freeze() from above).
Regards,
Nigel
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Jimi Xenidis @ 2006-06-22 2:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17561.56593.481580.556093@cargo.ozlabs.ibm.com>
On Jun 21, 2006, at 7:58 PM, Paul Mackerras wrote:
> Jimi Xenidis writes:
>
>> The following patch avoids accessing Hypervisor privilege HID
>> registers when running on a Hypervisor (MSR[HV]=0).
>
> Why? Aren't the writes defined to be no-ops when not in hypervisor
> mode?
The write are no-ops but look at the instructions required to be
around the write for some of them.
I believe read may have performance issues as well.
I juts think its good practice and as Xell and newer processes come
along we may want to start using the PACA(?) rather then peeking at
the msr all the time.
-JX
^ permalink raw reply
* Problem for "insmod: unresolved symbol printk"
From: Zhou Rui @ 2006-06-22 14:31 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
Hi, all
I'm a newbie for linuxppc. I've tried to write a simple hello.c as a kernel module.
/*hello.c*/
#ifndef MODULE
#define MODULE
#endif
#ifndef __KERNEL__
#define __KERNEL__
#endif
#include <linux/module.h>
#include <linux/kernel.h>
int init_module(void)
{
printk("Hello world 1.\n");
return 0;
}
void cleanup_module(void)
{
printk("Goodbye world 1.\n");
}
I wrote the code on a machine with Slackware installed. There was a PowerPC405EP board connected to the machined with NFS used. On the PowerPC board, the kernel is linuxppc-2.4.25-rthal5 and can be logged in via telnet. On the machine, there was also a toolchain for PowerPC and there were a series of commands beginning with "powerpc-linux-" existing. I've tried to cross-compile the source file with "powerpc-linux-gcc -c hello.c" or "powerpc-linux-gcc -c -DMODVERSIONS -I/usr/src/linuxppc-2.4.25/include hello.c" for PowerPC. But when I telneted into the board and run "insmod hello.o" on the PowerPC board, there always was "insmod: unresolved symbol printk". So would anyone give me some advice about the problem? Thank you very much.
---------------------------------
雅虎免费邮箱-3.5G容量，20M附件
[-- Attachment #2: Type: text/html, Size: 1458 bytes --]
^ permalink raw reply
* Re: entry point of kernel in RAM at 0x0c--linux tree file name
From: Laurent Pinchart @ 2006-06-22 15:35 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Arun Kumar
In-Reply-To: <edd12c050606220146i57282781o2052679c8f6108ef@mail.gmail.com>
Hi Arun,
> I would like to kow what is the entry point to kernel at 0x000 after
> decompressing and passing control to 0x0c .
> My kernel crashes somewhere after uncomressing and jumping to 0x0c .
>
> If any one can help the .c /.S file that contains the source of kernel
> startup code in RAM at 0x0/0x0c .
The entry point is in arch/ppc/kernel/head.S. Symbols _start and __start are
located at 0x00000000 and 0x0000000c respectively.
Best regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Olof Johansson @ 2006-06-22 16:23 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <C468730C-7E39-4B17-869D-CB2BA802A709@watson.ibm.com>
On Wed, Jun 21, 2006 at 10:35:28PM -0400, Jimi Xenidis wrote:
>
> On Jun 21, 2006, at 7:58 PM, Paul Mackerras wrote:
>
> > Jimi Xenidis writes:
> >
> >> The following patch avoids accessing Hypervisor privilege HID
> >> registers when running on a Hypervisor (MSR[HV]=0).
> >
> > Why? Aren't the writes defined to be no-ops when not in hypervisor
> > mode?
>
> The write are no-ops but look at the instructions required to be
> around the write for some of them.
> I believe read may have performance issues as well.
Are you aware that this code runs only once per processor during
boot (and/or during cpu hotplug)? A few extra cycles there won't kill
anyone.
That being said, not touching the registers makes sense, but I don't buy
the performance motivation. :-)
> I juts think its good practice and as Xell and newer processes come
> along we may want to start using the PACA(?) rather then peeking at
> the msr all the time.
PACA means it's a mfspr + dependent load + test instead of mfmsr + mask,
right? It'd need benchmarking on several processors to show if it's
better or not.
-Olof
^ permalink raw reply
* help to run the C code on AMCC PPC 405EP Kit
From: jagadeesh kalisetty @ 2006-06-22 17:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev-request
[-- Attachment #1: Type: text/plain, Size: 6869 bytes --]
Hi
We are using AMCC PPC 405EP Taihu board, our aim is to run the C code on kit. The kit already contains U-boot, linux kernel, and Ramdik images on Flash memory. We are successfully configured C-Kermit, NFS server(/opt/eldk4/ppc_4xx, /mnt/nfs-share) on host(Fedora Core 4). We are succeeded loading the files from NFS server after U-boot, but we are failed to mount the files (/mnt/nfs-share) on target after kernel booting on kit. But booth host and target are communicating after kernel booting (using ping).
We using the command to mount /mnt/nfs-share on target(Busy box 1.1.0):
target # mkdir /mnt/nfs
target # mount –t nfs 192.168.1.18:/mnt/nfs-share /mnt/nfs
error: monting 192.168.1.18:/mnt/nfs-share on /mnt/nfs : No such directory or file
Can u tell how to mount flash file system on target, using that one also we can run (bebug) the programs on kit using gdb
So we are failed to transfer any file on to the target. Is it any way to run the program on kit using host side ppc_4xx-gdb tool and target side gdbserver tool?
Is there any another way to run the code on the target or
Below is the problem we are facing while passing arguments to the kernel …….
we are expecting that there is no nfs device notice on the target, we tried different ways but we have failed to mount the root file system on linux or to mount host files on target, But we are succeeded loading the files from NFS server after U-boot
Hit any key to stop autoboot: 0
=> printenv
bootdelay=5
baudrate=9600
filesize=ebb7e5
ethaddr=50:00:00:00:25:00
eth1addr=50:00:00:00:25:01
loads_echo=1
setboot=setenv bootargs ramdisk=71800 root=/dev/ram ip=$(RT_eth0_ip)$(RT_eth0_ip2)
ethact=ppc_4xx_eth0
bootcmd=run setboot;bootm 0xfc000000 0xfc300000
kozio=bootm 0xffe00000
RT_eth0_ip=192.168.1.62
RT_eth0_ip2=:::::eth0:off
ipaddr=192.168.1.62
serverip=192.168.1.18
netmask=255.255.255.0
hostname=taihu
netdev=eth0
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 1.1.4 (Jan 19 2006 - 14:16:53)
Environment size: 722/16379 bytes
=> setenv bootargs root=/dev/nfs rw nfsroot=192.168.1.18:/opt/eldk/ppc_4xx ip=192.168.1.62:192.168.1.18::::eth0:off
=> bootm 0xfc000000
## Booting image at fc000000 ...
Image Name: Linux-2.6.13
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1121647 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.6.13 (root@linux_box) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #50 Tue Feb 7 09:07:24 CST 2006
AMCC PowerPC 405EP Taihu Platform
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.18:/opt/eldk/ppc_4xx ip=192.168.1.62:192.168.1.18::::eth0:off
PID hash table entries: 1024 (order: 10, 16384 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 127232k available (1916k kernel code, 452k data, 96k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 1) is a 16550A
ttyS1 at MMIO 0x0 (irq = 0) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
mal0: Initialized, 4 tx channels, 2 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
eth0: IBM emac, MAC 50:00:00:00:25:00
eth0: Found Generic MII PHY (0x14)
eth1: IBM emac, MAC 50:00:00:00:25:01
eth1: Found Generic MII PHY (0x10)
e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
taihu: bootflash mapping: 200000 at ffe00000
AMCC Taihu Boot Flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 3 MTD partitions on "AMCC Taihu Boot Flash":
0x00000000-0x001a0000 : "kozio diags"
0x001a0000-0x001c0000 : "u-boot env"
0x001c0000-0x00200000 : "u-boot"
taihu: appflash mapping: 2000000 at fc000000
AMCC Taihu Application Flash: Found 2 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
AMCC Taihu Application Flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 3 MTD partitions on "AMCC Taihu Application Flash":
0x00000000-0x00300000 : "kernel"
0x00300000-0x01d00000 : "initrd"
0x01d00000-0x02000000 : "jffs2"
Yenta: CardBus bridge found at 0000:00:07.0 [0000:0000]
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:07.0, mfunc 0x00001000, devctl 0x66
Yenta TI: socket 0000:00:07.0 probing PCI interrupt failed, trying to fix
Yenta TI: socket 0000:00:07.0 falling back to parallel PCI interrupts
Yenta TI: socket 0000:00:07.0 parallel PCI interrupts ok
eth0: Link is Up
eth0: Speed: 100, Full duplex.
Yenta: ISA IRQ mask 0x0000, PCI irq 26
Socket status: 30000087
pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
pcmcia: parent PCI bridge Memory window: 0x80000000 - 0xbfffffff
zero gadget: Gadget Zero, version: St Patrick's Day 2004
zero gadget: using pd12_udc, OUT ep1out-bulk IN ep2in-bulk
pd12_udc: registered gadget driver 'zero'
i2c /dev entries driver
IBM IIC driver v2.1
ibm-iic0: using standard (100 kHz) mode
NET: Registered protocol family 2
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
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
eth0: Link is Up
eth0: Speed: 100, Full duplex.
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.1.62, mask=255.255.255.0, gw=255.255.255.255,
host=192.168.1.62, domain=, nis-domain=(none),
bootserver=192.168.1.18, rootserver=192.168.1.18, rootpath=
VFS: Cannot open root device "nfs" or unknown-block(0,255)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255)
<0>Rebooting in 180 seconds..
[-- Attachment #2: Type: text/html, Size: 8017 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Jimi Xenidis @ 2006-06-22 17:22 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060622162358.GA13300@pb15.lixom.net>
On Jun 22, 2006, at 12:23 PM, Olof Johansson wrote:
>
> Are you aware that this code runs only once per processor during
> boot (and/or during cpu hotplug)? A few extra cycles there won't kill
> anyone.
Hey, I never said it was a hot path, only that it had performance
issues.
I agree about the a "few extra cycles"
> That being said, not touching the registers makes sense, but I
> don't buy
> the performance motivation. :-)
>
>> I juts think its good practice and as Xell and newer processes come
>> along we may want to start using the PACA(?) rather then peeking at
>> the msr all the time.
>
> PACA means it's a mfspr + dependent load + test instead of mfmsr +
> mask,
> right? It'd need benchmarking on several processors to show if it's
> better or not.
>
>
> -Olof
^ permalink raw reply
* Re: Problem for "insmod: unresolved symbol printk"
From: Olof Johansson @ 2006-06-22 17:48 UTC (permalink / raw)
To: Zhou Rui; +Cc: linuxppc-dev
In-Reply-To: <20060622143156.39031.qmail@web15601.mail.cnb.yahoo.com>
On Thu, Jun 22, 2006 at 10:31:56PM +0800, Zhou Rui wrote:
> Hi, all
> I'm a newbie for linuxppc. I've tried to write a simple hello.c as a kernel module.
Hi,
http://kernelnewbies.org/ should have information on kernel module
basics, and where to find help if you still have problems.
-Olof
^ permalink raw reply
* Re: help to run the C code on AMCC PPC 405EP Kit
From: Olof Johansson @ 2006-06-22 17:51 UTC (permalink / raw)
To: jagadeesh kalisetty; +Cc: linuxppc-dev
In-Reply-To: <20060622171846.18376.qmail@webmail28.rediffmail.com>
Hi,
On Thu, Jun 22, 2006 at 05:18:46PM -0000, jagadeesh kalisetty wrote:
> Hi
> We are using AMCC PPC 405EP Taihu board, our aim is to run the C code on kit.
linuxppc-embedded@ozlabs.org is a better list to post your question
to. Or try contacting AMCC for documentation on how to use their kit,
since it's pretty basic stuff you're trying to get working.
Thanks,
Olof
^ permalink raw reply
* [PATCH] Remove redundant PPC_86XX check.
From: Jon Loeliger @ 2006-06-22 17:59 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/Makefile | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/Makefile b/arch/powerpc/platforms/86xx/Makefile
index 7be796c..476a6ee 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -2,9 +2,6 @@ #
# Makefile for the PowerPC 86xx linux kernel.
#
-
-ifeq ($(CONFIG_PPC_86xx),y)
obj-$(CONFIG_SMP) += mpc86xx_smp.o
-endif
obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
obj-$(CONFIG_PCI) += pci.o mpc86xx_pcie.o
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* [PATCH] Move I8259 selection under MPC8641HPCN board
From: Jon Loeliger @ 2006-06-22 18:00 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/Kconfig | 1 -
arch/powerpc/platforms/86xx/Kconfig | 1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index cdaa4b1..45043f0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -786,7 +786,6 @@ config GENERIC_ISA_DMA
config PPC_I8259
bool
- default y if MPC8641_HPCN
default n
config PPC_INDIRECT_PCI
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 3a87863..3d2b21a 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -7,6 +7,7 @@ choice
config MPC8641_HPCN
bool "Freescale MPC8641 HPCN"
+ select PPC_I8259
help
This option enables support for the MPC8641 HPCN board.
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* [PATCH] Remove redundant STD_MMU selection.
From: Jon Loeliger @ 2006-06-22 18:01 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/Kconfig | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 3d2b21a..d1ecc0f 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -29,9 +29,4 @@ config PPC_INDIRECT_PCI_BE
depends on PPC_86xx
default y
-config PPC_STD_MMU
- bool
- depends on PPC_86xx
- default y
-
endmenu
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* [PATCH] Remove obsolete #include <linux/config.h>.
From: Jon Loeliger @ 2006-06-22 18:02 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/mpc8641_hpcn.h | 1 -
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 -
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 1 -
arch/powerpc/platforms/86xx/pci.c | 1 -
include/asm-powerpc/mpc86xx.h | 1 -
5 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8641_hpcn.h b/arch/powerpc/platforms/86xx/mpc8641_hpcn.h
index 747e549..d862a9c 100644
--- a/arch/powerpc/platforms/86xx/mpc8641_hpcn.h
+++ b/arch/powerpc/platforms/86xx/mpc8641_hpcn.h
@@ -14,7 +14,6 @@
#ifndef __MPC8641_HPCN_H__
#define __MPC8641_HPCN_H__
-#include <linux/config.h>
#include <linux/init.h>
/* PCI-Express memory map */
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 092bca3..cf4fd04 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -12,7 +12,6 @@
* option) any later version.
*/
-#include <linux/config.h>
#include <linux/stddef.h>
#include <linux/kernel.h>
#include <linux/pci.h>
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_smp.c b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
index 944ec4b..167f040 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_smp.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
@@ -10,7 +10,6 @@
* option) any later version.
*/
-#include <linux/config.h>
#include <linux/stddef.h>
#include <linux/kernel.h>
#include <linux/init.h>
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index a03b36f..dd7e3bf 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -12,7 +12,6 @@
* option) any later version.
*/
-#include <linux/config.h>
#include <linux/types.h>
#include <linux/module.h>
#include <linux/init.h>
diff --git a/include/asm-powerpc/mpc86xx.h b/include/asm-powerpc/mpc86xx.h
index d0a6718..1ed72f6 100644
--- a/include/asm-powerpc/mpc86xx.h
+++ b/include/asm-powerpc/mpc86xx.h
@@ -15,7 +15,6 @@ #ifdef __KERNEL__
#ifndef __ASM_POWERPC_MPC86xx_H__
#define __ASM_POWERPC_MPC86xx_H__
-#include <linux/config.h>
#include <asm/mmu.h>
#ifdef CONFIG_PPC_86xx
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* [PATCH] Use IRQ and senses from OF-tree on 8641hpcn.
From: Jon Loeliger @ 2006-06-22 18:04 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/mpc8641_hpcn.h | 11 -
arch/powerpc/platforms/86xx/mpc86xx.h | 1
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 118 +---------------
arch/powerpc/platforms/86xx/pci.c | 212 ++++++++++++++++++++++++----
4 files changed, 187 insertions(+), 155 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8641_hpcn.h b/arch/powerpc/platforms/86xx/mpc8641_hpcn.h
index 5042253..747e549 100644
--- a/arch/powerpc/platforms/86xx/mpc8641_hpcn.h
+++ b/arch/powerpc/platforms/86xx/mpc8641_hpcn.h
@@ -17,17 +17,6 @@ #define __MPC8641_HPCN_H__
#include <linux/config.h>
#include <linux/init.h>
-/* PCI interrupt controller */
-#define PIRQA 3
-#define PIRQB 4
-#define PIRQC 5
-#define PIRQD 6
-#define PIRQ7 7
-#define PIRQE 9
-#define PIRQF 10
-#define PIRQG 11
-#define PIRQH 12
-
/* PCI-Express memory map */
#define MPC86XX_PCIE_LOWER_IO 0x00000000
#define MPC86XX_PCIE_UPPER_IO 0x00ffffff
diff --git a/arch/powerpc/platforms/86xx/mpc86xx.h b/arch/powerpc/platforms/86xx/mpc86xx.h
index e3c9e4f..96010c6 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx.h
+++ b/arch/powerpc/platforms/86xx/mpc86xx.h
@@ -16,6 +16,7 @@ #define __MPC86XX_H__
*/
extern int __init add_bridge(struct device_node *dev);
+extern void mpc86xx_pcibios_fixup(void);
extern void __init setup_indirect_pcie(struct pci_controller *hose,
u32 cfg_addr, u32 cfg_data);
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 483c21d..092bca3 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -44,93 +44,24 @@ unsigned long pci_dram_offset = 0;
#endif
-/*
- * Internal interrupts are all Level Sensitive, and Positive Polarity
- */
-
-static u_char mpc86xx_hpcn_openpic_initsenses[] __initdata = {
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 0: Reserved */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 1: MCM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 2: DDR DRAM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 3: LBIU */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 4: DMA 0 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 5: DMA 1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 6: DMA 2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 7: DMA 3 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 8: PCIE1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 9: PCIE2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 10: Reserved */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 11: Reserved */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 12: DUART2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 13: TSEC 1 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 14: TSEC 1 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 15: TSEC 3 transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 16: TSEC 3 receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 17: TSEC 3 error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 18: TSEC 1 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 19: TSEC 2 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 20: TSEC 2 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 21: TSEC 4 transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 22: TSEC 4 receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 23: TSEC 4 error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 24: TSEC 2 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 25: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 26: DUART1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 27: I2C */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 28: Performance Monitor */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 29: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 30: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 31: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 32: SRIO error/write-port unit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 33: SRIO outbound doorbell */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 34: SRIO inbound doorbell */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 35: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 36: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 37: SRIO outbound message unit 1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 38: SRIO inbound message unit 1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 39: SRIO outbound message unit 2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 40: SRIO inbound message unit 2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 41: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 42: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 43: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 44: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 45: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 46: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 47: Unused */
- 0x0, /* External 0: */
- 0x0, /* External 1: */
- 0x0, /* External 2: */
- 0x0, /* External 3: */
- 0x0, /* External 4: */
- 0x0, /* External 5: */
- 0x0, /* External 6: */
- 0x0, /* External 7: */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 8: Pixis FPGA */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* External 9: ULI 8259 INTR Cascade */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 10: Quad ETH PHY */
- 0x0, /* External 11: */
- 0x0,
- 0x0,
- 0x0,
- 0x0,
-};
-
-
void __init
mpc86xx_hpcn_init_irq(void)
{
struct mpic *mpic1;
phys_addr_t openpic_paddr;
+ int irq_count =
+ NR_IRQS - NUM_8259_INTERRUPTS - 4; /* leave room for IPIs */
+ unsigned char init_senses[NR_IRQS - NUM_8259_INTERRUPTS - 4];
+ prom_get_irq_senses(init_senses, NUM_8259_INTERRUPTS, NR_IRQS - 4);
/* Determine the Physical Address of the OpenPIC regs */
openpic_paddr = get_immrbase() + MPC86xx_OPENPIC_OFFSET;
/* Alloc mpic structure and per isu has 16 INT entries. */
mpic1 = mpic_alloc(openpic_paddr,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
- 16, MPC86xx_OPENPIC_IRQ_OFFSET, 0, 250,
- mpc86xx_hpcn_openpic_initsenses,
- sizeof(mpc86xx_hpcn_openpic_initsenses),
+ 16, NUM_8259_INTERRUPTS, irq_count,
+ NR_IRQS - 4, init_senses, irq_count,
" MPIC ");
BUG_ON(mpic1 == NULL);
@@ -153,40 +84,6 @@ #endif
#ifdef CONFIG_PCI
-/*
- * interrupt routing
- */
-
-int
-mpc86xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
-{
- static char pci_irq_table[][4] = {
- /*
- * PCI IDSEL/INTPIN->INTLINE
- * A B C D
- */
- {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 17 -- PCI Slot 1 */
- {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 18 -- PCI Slot 2 */
- {0, 0, 0, 0}, /* IDSEL 19 */
- {0, 0, 0, 0}, /* IDSEL 20 */
- {0, 0, 0, 0}, /* IDSEL 21 */
- {0, 0, 0, 0}, /* IDSEL 22 */
- {0, 0, 0, 0}, /* IDSEL 23 */
- {0, 0, 0, 0}, /* IDSEL 24 */
- {0, 0, 0, 0}, /* IDSEL 25 */
- {PIRQD, PIRQA, PIRQB, PIRQC}, /* IDSEL 26 -- PCI Bridge*/
- {PIRQC, 0, 0, 0}, /* IDSEL 27 -- LAN */
- {PIRQE, PIRQF, PIRQH, PIRQ7}, /* IDSEL 28 -- USB 1.1 */
- {PIRQE, PIRQF, PIRQG, 0}, /* IDSEL 29 -- Audio & Modem */
- {PIRQH, 0, 0, 0}, /* IDSEL 30 -- LPC & PMU*/
- {PIRQD, 0, 0, 0}, /* IDSEL 31 -- ATA */
- };
-
- const long min_idsel = 17, max_idsel = 31, irqs_per_slot = 4;
- return PCI_IRQ_TABLE_LOOKUP + I8259_OFFSET;
-}
-
-
int
mpc86xx_exclude_device(u_char bus, u_char devfn)
{
@@ -224,8 +121,6 @@ #ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
add_bridge(np);
- ppc_md.pci_swizzle = common_swizzle;
- ppc_md.pci_map_irq = mpc86xx_map_irq;
ppc_md.pci_exclude_device = mpc86xx_exclude_device;
#endif
@@ -316,6 +211,7 @@ define_machine(mpc86xx_hpcn) {
.name = "MPC86xx HPCN",
.probe = mpc86xx_hpcn_probe,
.setup_arch = mpc86xx_hpcn_setup_arch,
+ .pcibios_fixup = mpc86xx_pcibios_fixup,
.init_IRQ = mpc86xx_hpcn_init_irq,
.show_cpuinfo = mpc86xx_hpcn_show_cpuinfo,
.get_irq = mpic_get_irq,
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index 5180df7..a03b36f 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -199,63 +199,207 @@ int __init add_bridge(struct device_node
return 0;
}
-static void __devinit quirk_ali1575(struct pci_dev *dev)
+static int __init get_pci_irq_from_of(struct pci_controller *hose,
+ int slot, int pin)
+{
+ struct device_node *node;
+ unsigned long *interrupt, *interrupt_mask;
+ int len, mask_len;
+ int shift, i;
+ int irq = 0;
+
+ if (!hose) {
+ printk(KERN_ERR "No PCI hose found!\n");
+ return -EFAULT;
+ }
+
+ node = (struct device_node *)hose->arch_data;
+ interrupt = (unsigned long *)get_property(node,
+ "interrupt-map", &len);
+ interrupt_mask = (unsigned long *)get_property(node,
+ "interrupt-map-mask", &mask_len);
+ if (!interrupt || !interrupt_mask) {
+ printk(KERN_ERR "No PCI interrupt-map or interrupt-map-mask"
+ "property in OpenFirmware device tree!\n");
+ return -EFAULT;
+ }
+ shift = __ilog2((~interrupt_mask[0] + 1) & 0xffff);
+
+ /*
+ * Find matched irq in interrupt-map node of OF-tree.
+ *
+ * interrupt-map entries format:
+ * <slot> <pin> <interrupt-parent> <irq#>
+ * 8800 0 0 1 40000 3 0
+ */
+ pr_debug("PCI slot %x, pin %d ", slot, pin);
+ for (i = 0; i < (len / 7); i++)
+ if (((interrupt[i * 7] & interrupt_mask[0]) == (slot << shift))
+ && (interrupt[i * 7 + 3] == pin))
+ irq = interrupt[i * 7 + 5] & interrupt_mask[3];
+ pr_debug("irq %d\n", irq);
+
+ if (!irq)
+ printk(KERN_WARNING "PCI Slot %d, Pin %d device "
+ "has no matched irq!\n", slot, pin);
+
+ return irq;
+}
+
+static int __init mpc86xx_irq_fixup(struct pci_dev *dev)
+{
+ struct pci_controller *hose = NULL;
+ int pin, slot;
+
+ hose = pci_bus_to_hose(dev->bus->number);
+ if (!hose) {
+ printk(KERN_ERR "No PCI hose found!\n");
+ return -EFAULT;
+ }
+
+ pin = dev->pin;
+ if (dev->bus->number != hose->first_busno) {
+ do {
+ pin = ((pin-1) + PCI_SLOT(dev->devfn)) %4 + 1;
+ /* Move up the chain of bridges. */
+ dev = dev->bus->self;
+ } while (dev->bus->self);
+ /* The slot is the idsel of the last bridge. */
+ }
+ slot = PCI_SLOT(dev->devfn);
+
+ return get_pci_irq_from_of(hose, slot, pin);
+}
+
+void __init mpc86xx_pcibios_fixup(void)
+{
+ struct pci_dev *dev = NULL;
+
+ for_each_pci_dev(dev) {
+ dev->irq = mpc86xx_irq_fixup(dev);
+ if (dev->irq < 0)
+ return;
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
+ }
+}
+
+enum pirq{PIRQA = 8, PIRQB, PIRQC, PIRQD, PIRQE, PIRQF, PIRQG, PIRQH};
+const unsigned char uli1575_irq_route_table[16] = {
+ 0, /* 0: Reserved */
+ 0x8, /* 1: 0b1000 */
+ 0, /* 2: Reserved */
+ 0x2, /* 3: 0b0010 */
+ 0x4, /* 4: 0b0100 */
+ 0x5, /* 5: 0b0101 */
+ 0x7, /* 6: 0b0111 */
+ 0x6, /* 7: 0b0110 */
+ 0, /* 8: Reserved */
+ 0x1, /* 9: 0b0001 */
+ 0x3, /* 10: 0b0011 */
+ 0x9, /* 11: 0b1001 */
+ 0xb, /* 12: 0b1011 */
+ 0, /* 13: Reserved */
+ 0xd, /* 14, 0b1101 */
+ 0xf, /* 15, 0b1111 */
+};
+
+
+static void __devinit quirk_uli1575(struct pci_dev *dev)
{
unsigned short temp;
+ struct pci_controller *hose = pci_bus_to_hose(dev->bus->number);
+ int i, irq;
+ unsigned char irq2pin[16];
+ unsigned long pirq_map_word = 0;
+
+ if (!hose) {
+ printk(KERN_ERR "No PCI hose!\n");
+ return;
+ }
/*
- * ALI1575 interrupts route table setup:
+ * ULI1575 interrupts route setup
+ */
+ memset(irq2pin, 0, 16); /* Initialize default value 0 */
+
+ /*
+ * PIRQA -> PIRQD mapping read from OF-tree
+ *
+ * interrupts for PCI slot0 -- PIRQA / PIRQB / PIRQC / PIRQD
+ * PCI slot1 -- PIRQB / PIRQC / PIRQD / PIRQA
+ */
+ for (i = 0; i < 4; i++){
+ irq = get_pci_irq_from_of(hose, 17, i + 1);
+ if (irq >= 0 && irq <= 15)
+ irq2pin[irq] = PIRQA + i;
+ }
+
+ /*
+ * PIRQE -> PIRQF mapping set manually
*
* IRQ pin IRQ#
- * PIRQA ---- 3
- * PIRQB ---- 4
- * PIRQC ---- 5
- * PIRQD ---- 6
* PIRQE ---- 9
* PIRQF ---- 10
* PIRQG ---- 11
* PIRQH ---- 12
- *
- * interrupts for PCI slot0 -- PIRQA / PIRQB / PIRQC / PIRQD
- * PCI slot1 -- PIRQB / PIRQC / PIRQD / PIRQA
*/
- pci_write_config_dword(dev, 0x48, 0xb9317542);
+ for (i = 0; i < 4; i++) irq2pin[i + 9] = PIRQE + i;
- /* USB 1.1 OHCI controller 1, interrupt: PIRQE */
- pci_write_config_byte(dev, 0x86, 0x0c);
+ /* Set IRQ-PIRQ Mapping to ULI1575 */
+ for (i = 0; i < 16; i++)
+ if (irq2pin[i])
+ pirq_map_word |= (uli1575_irq_route_table[i] & 0xf)
+ << ((irq2pin[i] - PIRQA) * 4);
- /* USB 1.1 OHCI controller 2, interrupt: PIRQF */
- pci_write_config_byte(dev, 0x87, 0x0d);
+ DBG("Setup ULI1575 IRQ mapping configuration register value = 0x%x\n",
+ pirq_map_word);
+ pci_write_config_dword(dev, 0x48, pirq_map_word);
- /* USB 1.1 OHCI controller 3, interrupt: PIRQH */
- pci_write_config_byte(dev, 0x88, 0x0f);
+#define ULI1575_SET_DEV_IRQ(slot, pin, reg) \
+ do { \
+ int irq; \
+ irq = get_pci_irq_from_of(hose, slot, pin); \
+ if (irq >= 0 && irq <=15) \
+ pci_write_config_byte(dev, reg, irq2pin[irq]); \
+ } while(0)
- /* USB 2.0 controller, interrupt: PIRQ7 */
- pci_write_config_byte(dev, 0x74, 0x06);
+ /* USB 1.1 OHCI controller 1, slot 28, pin 1 */
+ ULI1575_SET_DEV_IRQ(28, 1, 0x86);
- /* Audio controller, interrupt: PIRQE */
- pci_write_config_byte(dev, 0x8a, 0x0c);
+ /* USB 1.1 OHCI controller 2, slot 28, pin 2 */
+ ULI1575_SET_DEV_IRQ(28, 2, 0x87);
- /* Modem controller, interrupt: PIRQF */
- pci_write_config_byte(dev, 0x8b, 0x0d);
+ /* USB 1.1 OHCI controller 3, slot 28, pin 3 */
+ ULI1575_SET_DEV_IRQ(28, 3, 0x88);
- /* HD audio controller, interrupt: PIRQG */
- pci_write_config_byte(dev, 0x8c, 0x0e);
+ /* USB 2.0 controller, slot 28, pin 4 */
+ irq = get_pci_irq_from_of(hose, 28, 4);
+ if (irq >= 0 && irq <=15)
+ pci_write_config_dword(dev, 0x74, uli1575_irq_route_table[irq]);
- /* Serial ATA interrupt: PIRQD */
- pci_write_config_byte(dev, 0x8d, 0x0b);
+ /* Audio controller, slot 29, pin 1 */
+ ULI1575_SET_DEV_IRQ(29, 1, 0x8a);
- /* SMB interrupt: PIRQH */
- pci_write_config_byte(dev, 0x8e, 0x0f);
+ /* Modem controller, slot 29, pin 2 */
+ ULI1575_SET_DEV_IRQ(29, 2, 0x8b);
- /* PMU ACPI SCI interrupt: PIRQH */
- pci_write_config_byte(dev, 0x8f, 0x0f);
+ /* HD audio controller, slot 29, pin 3 */
+ ULI1575_SET_DEV_IRQ(29, 3, 0x8c);
+
+ /* SMB interrupt: slot 30, pin 1 */
+ ULI1575_SET_DEV_IRQ(30, 1, 0x8e);
+
+ /* PMU ACPI SCI interrupt: slot 30, pin 2 */
+ ULI1575_SET_DEV_IRQ(30, 2, 0x8f);
+
+ /* Serial ATA interrupt: slot 31, pin 1 */
+ ULI1575_SET_DEV_IRQ(31, 1, 0x8d);
/* Primary PATA IDE IRQ: 14
* Secondary PATA IDE IRQ: 15
*/
- pci_write_config_byte(dev, 0x44, 0x3d);
- pci_write_config_byte(dev, 0x75, 0x0f);
+ pci_write_config_byte(dev, 0x44, 0x30 | uli1575_irq_route_table[14]);
+ pci_write_config_byte(dev, 0x75, uli1575_irq_route_table[15]);
/* Set IRQ14 and IRQ15 to legacy IRQs */
pci_read_config_word(dev, 0x46, &temp);
@@ -277,6 +421,8 @@ static void __devinit quirk_ali1575(stru
*/
outb(0xfa, 0x4d0);
outb(0x1e, 0x4d1);
+
+#undef ULI1575_SET_DEV_IRQ
}
static void __devinit quirk_uli5288(struct pci_dev *dev)
@@ -319,7 +465,7 @@ static void __devinit early_uli5249(stru
dev->class |= 0x1;
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575, quirk_ali1575);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575, quirk_uli1575);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5288, quirk_uli5288);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5229, quirk_uli5229);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AL, 0x5249, early_uli5249);
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* Re: [linux-pm] windfarm got signal
From: Pavel Machek @ 2006-06-22 13:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-pm, linuxppc-dev list
In-Reply-To: <1150847482.16662.13.camel@johannes>
Hi!
> after cpu hotplug I decided to write some fake suspend routines for
> ppc64 that always fail to see what all the drivers would say... The
> first thing I saw was during the phase where all threads are stopped,
> that windfarm got a signal!
>
> Shortly after that, the fans were revved up fully but I guess that's
> expected if the wf control loop exits.
>
> So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> expected with pm and windfarm just does the wrong thing there by taking
> the signal as a reason to exit the control thread?
>
> [code in question is windfarm_core.c:wf_thread_func]
See kernel/power/process.c
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
^ permalink raw reply
* Re: help to run the C code on AMCC PPC 405EP Kit
From: Wolfgang Denk @ 2006-06-22 19:30 UTC (permalink / raw)
To: Olof Johansson; +Cc: jagadeesh kalisetty, linuxppc-dev
In-Reply-To: <20060622175111.GB16973@pb15.lixom.net>
In message <20060622175111.GB16973@pb15.lixom.net> you wrote:
>
> > We are using AMCC PPC 405EP Taihu board, our aim is to run the C code on kit.
>
> linuxppc-embedded@ozlabs.org is a better list to post your question
> to. Or try contacting AMCC for documentation on how to use their kit,
> since it's pretty basic stuff you're trying to get working.
...and read the DULG, see http://www.denx.de/wiki/DULG/Manual
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I really hate this damned machine It never does quite what I want
I wish that they would sell it. But only what I tell it.
^ 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