* Re: Problem in PCI initialization
From: G.Muruganandam @ 2006-06-15 19:27 UTC (permalink / raw)
To: Prabhat_Singh, linuxppc-embedded
In-Reply-To: <D8595042F3765A4285B848A78A2C2ED10494917B@bsdmsg002.corp.sa tyam.ad>
[-- Attachment #1: Type: text/plain, Size: 4700 bytes --]
Before testing the PCI in linux, you need to make
sure that the PCI is working under u-boot with out any issues.
Here are the check list.
1. pci long command under u-boot should display
the pci configuration registers of the device in PCI bus
consistently.
2. Check the PCI BAR registers at offset
0x10,0x14 and 0x18 are configured with proper values based on
whether it is a PCI memory mapped device or IO mapped device.
3. Check the TLB setting under U-boot whether it
is set correctly for the PCI memory and/or IO regions.
If you are using the u-boot 1.1.x, you should
look at init.S for the particular board/cpu.
Hope this helps!
Thanks
G.Muruganandam
At 11:39 PM 6/14/2006, Prabhat_Singh wrote:
>Content-class: urn:content-classes:message
>Content-Transfer-Encoding: 7bit
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_001_01C69046.65DE2215"
>
>Hi all
>I am using MPC8248 based board which has got one PCI interface at 66 MHz .
>
>I am not able to initialize PCI, I am really
>clueless and getting the following errors.
>
>Can any one tell me what is wrong with this?
>
>But I am initializing the pci in uboot also and
>there in uboot able to detect the network card,
>but while boot its give first time the machine
>check exception and then its reseting itself and
>then in second try it (uboot) is working fine.
>Do the register sets in uboot is again read by
>linux during linux PCI initialization?
>
>Someone please help.
>
>## Booting image at ffd00000 ...
>Image Name: Linux-2.4.28-1.3.1-517
>Image Type: PowerPC Linux Kernel Image (gzip compressed)
>Data Size: 643461 Bytes = 628.4 kB
>Load Address: 00000000
>Entry Point: 00000000
>Verifying Checksum ... OK
>Uncompressing Kernel Image ... OK
>## Current stack ends at 0x01FAB390 => set upper limit to 0x00800000
>No initrd
>## Transferring control to Linux (at address 00000000) ...
>Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb
>
>Linux version 2.4.28-1.3.1-517
>(root@localhost.localdomain) (gcc version 3.3.4)
>#280 Tue Jun 13 16:17:02 IST 2006
>
>On node 0 totalpages: 8192
>
>zone(0): 8192 pages.
>
>zone(1): 0 pages.
>
>zone(2): 0 pages.
>
>Kernel command line: console=ttyS0,115200 root=1f00
>
>Calibrating delay loop... 266.24 BogoMIPS
>
>Memory: 30712k available (1228k kernel code, 368k data, 64k init, 0k highmem)
>
>Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
>
>Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
>
>Mount cache hash table entries: 512 (order: 0, 4096 bytes)
>
>Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
>
>Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
>
>POSIX conformance testing by UNIFIX
>
>PCI: Probing PCI hardware
>
>Scanning bus 00
>
>Oops: kernel access of bad area, sig: 11
>
>NIP: C000C6DC XER: 00000000 LR: C0003FAC SP:
>C0183DC0 REGS: c0183d10 TRAP: 0300 Not tainted
>
>MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
>
>DAR: 00000024, DSISR: 20000000
>
>TASK = c023a000[14] '¢pÀ }¬' Last syscall: -1
>
>last math 00000000 last altivec 00000000
>
>GPR00: 00000000 C0183DC0 C023A000 C0183E80
>00000024 20000000 C0170000 00000439
>
>GPR08: 00000000 C0183D20 00000000 00000000
>22004084 B5FFFFFF 01FF8000 007FFC1E
>
>GPR16: 00000001 00000000 FFFFFFFF 007FFC00
>00001032 00183E70 00000000 C0003FAC
>
>GPR24: 00000000 00030001 00000008 20000000
>C0183E80 00000024 00000024 00000008
>
>Call backtrace:
>
>C0019384 C0003FAC 00000000 C0003FAC 00000000 C0003FAC C0184214
>
>C0003FAC C0184380 C0003FAC C01844F0 C0003FAC C0184664 C0003FAC
>
>C01847D0 C0003FAC C0184940 C0003FAC C0184AB4 C0003FAC C0184C24
>
>C0003FAC C0184D94 C0003FAC C0184F04 C0003FAC C0185074 C0003FAC
>
>00000000 C0003FAC 00000000 C0003FAC 00000000
>
>Kernel panic: Aiee, killing interrupt handler!
>
>In interrupt handler - not syncing
>
><0>Rebooting in 180 seconds..
>
>
>
>DISCLAIMER:
>This email (including any attachments) is
>intended for the sole use of the intended
>recipient/s and may contain material that is
>CONFIDENTIAL AND PRIVATE COMPANY INFORMATION.
>Any review or reliance by others or copying or
>distribution or forwarding of any or all of the
>contents in this message is STRICTLY PROHIBITED.
>If you are not the intended recipient, please
>contact the sender by email and delete all
>copies; your cooperation in this regard is appreciated..
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 5666 bytes --]
^ permalink raw reply
* MSI support on Linux PCI implementation for Ocotea
From: Shawn Jin @ 2006-06-15 21:14 UTC (permalink / raw)
To: ppcembed, ppcdev
Hi,
I'm looking at the linux PCI implementation, especially MSI support
for Ocotea. And I have some observations and questions about it. Maybe
somebody here can shed some light on them. Thanks.
1. Obviously MSI is supported in Linux 2.6.x, maybe even in 2.4.x. But
MSI implementation seems to support only IOxAPIC on x86 or IA64
architectures, though the implemenation is in generic drivers/pci
tree.
2. Why is the message data defined in a such way shown as follows? Or
does it just follow IOxAPIC's design? Further question is who defines
the format of the message data. The PCI/PCIe specs don't say anything
about the content of the message data register.
struct msg_data {
__u32 vector : 8;
__u32 delivery_mode : 3; /* 000b: FIXED | 001b: lowest prior */
__u32 reserved_1 : 3;
__u32 level : 1; /* 0: deassert | 1: assert */
__u32 trigger : 1; /* 0: edge | 1: level */
__u32 reserved_2 : 16;
} __attribute__ ((packed));
3. How is the pci subsystem initialized on a PPC platform? Is there
any existing document discussing PCI subsystem? Of course I've been
doing a lot internet search and couldn't find too much useful infor.
Thanks a lot,
-Shawn.
^ permalink raw reply
* Interrupt occurs but UIC0 MSR is still 0
From: Chris Dumoulin @ 2006-06-15 21:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I'm working with a 2.6 linux kernel in a board with a PPC405 in a Virtex
II Pro FPGA. I'm trying to generate interrupts and handle them in a
device driver that I've written.
Here is the sequence of events that happen currently:
1. I generate an interrupt by setting registers in an interrupt
controller we've got in the FPGA (it's a Xilinx LogicCORE OPB Interrupt
Controller).
2. The function do_IRQ, in arch/powerpc/kernel/irq.c, is called.
3. ppc_md.get_irq is called from do_IRQ.
4. ppc_md.get_irq points to ppc4xx_pic_get_irq in
arch/ppc/syslib/ppc4xx_pic.c.
5. ppc4xx_pic_get_irq reads the MSR from UIC0 to determine the IRQ. In
my case, the MSR is all zero, so ppc4xx_pic_get_irq returns -1.
6. After this, we return from the interrupt, and do_IRQ is called again
and again, going through the same steps indefinitely.
I've looked at the UIC0 registers, and the SR, MSR, and ER registers are
all 0. How can an interrupt be triggered, but all the UIC0 bits are 0?
Is it possible that I'm not actually accessing UIC0? I've got the
following in my arch/ppc/platforms/4xx/my_board.h file:
#define DCRN_UIC0_BASE 0x0C0
#define UIC0 DCRN_UIC0_BASE
Any ideas would be appreciated.
Cheers,
Chris Dumoulin
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Deerfield Internet connection
From: David H. Lynch Jr. @ 2006-06-15 22:00 UTC (permalink / raw)
To: barbara Lynch-Hughes, linuxppc-embedded, Bill Lynch,
maryJean Glick
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
Comcast finally installed internet at Deerfield.
There is a Linksys 802.11a+b+g Wireless Router in DTL's upstairs office.
The Wireless is setup using WEP security.
The ssid is "deerfield"
the WEP key is either "One Ring" or 40faad1ede
Barbara persuaded Comcast to bring in the service. I beleive it is
on a month-month basis.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 1435 bytes --]
^ permalink raw reply
* [PATCH]: powerpc: pseries: Print PCI slot location code on failure
From: Linas Vepstas @ 2006-06-15 22:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
Resending an older patch (from 28 April) that seems to have fallen
through the cracks, its not in mailine, is not in -mm and its not
controversial (its mostly a printk change). Tested.
--linas
The PCI error recovery code will printk diagnostic info when
a PCI error event occurs. Change the messages to include the slot
location code, which is how most sysadmins will know the device.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 33 ++++++++++++++++------------
1 files changed, 20 insertions(+), 13 deletions(-)
Index: linux-2.6.17-rc6-mm2/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.17-rc6-mm2.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2006-06-13 18:13:26.000000000 -0500
+++ linux-2.6.17-rc6-mm2/arch/powerpc/platforms/pseries/eeh_driver.c 2006-06-14 17:42:46.000000000 -0500
@@ -261,16 +261,20 @@ struct pci_dn * handle_eeh_events (struc
struct pci_bus *frozen_bus;
int rc = 0;
enum pci_ers_result result = PCI_ERS_RESULT_NONE;
- const char *pci_str, *drv_str;
+ const char *location, *pci_str, *drv_str;
frozen_dn = find_device_pe(event->dn);
frozen_bus = pcibios_find_pci_bus(frozen_dn);
if (!frozen_dn) {
- printk(KERN_ERR "EEH: Error: Cannot find partition endpoint for %s\n",
- pci_name(event->dev));
+
+ location = (char *) get_property(event->dn, "ibm,loc-code", NULL);
+ printk(KERN_ERR "EEH: Error: Cannot find partition endpoint "
+ "for location=%s pci addr=%s\n",
+ location, pci_name(event->dev));
return NULL;
}
+ location = (char *) get_property(frozen_dn, "ibm,loc-code", NULL);
/* There are two different styles for coming up with the PE.
* In the old style, it was the highest EEH-capable device
@@ -282,8 +286,9 @@ struct pci_dn * handle_eeh_events (struc
frozen_bus = pcibios_find_pci_bus (frozen_dn->parent);
if (!frozen_bus) {
- printk(KERN_ERR "EEH: Cannot find PCI bus for %s\n",
- frozen_dn->full_name);
+ printk(KERN_ERR "EEH: Cannot find PCI bus "
+ "for location=%s dn=%s\n",
+ location, frozen_dn->full_name);
return NULL;
}
@@ -318,8 +323,9 @@ struct pci_dn * handle_eeh_events (struc
eeh_slot_error_detail(frozen_pdn, 1 /* Temporary Error */);
printk(KERN_WARNING
- "EEH: This PCI device has failed %d times since last reboot: %s - %s\n",
- frozen_pdn->eeh_freeze_count, drv_str, pci_str);
+ "EEH: This PCI device has failed %d times since last reboot: "
+ "location=%s driver=%s pci addr=%s\n",
+ frozen_pdn->eeh_freeze_count, location, drv_str, pci_str);
/* Walk the various device drivers attached to this slot through
* a reset sequence, giving each an opportunity to do what it needs
@@ -368,17 +374,18 @@ excess_failures:
* due to actual, failed cards.
*/
printk(KERN_ERR
- "EEH: PCI device %s - %s has failed %d times \n"
- "and has been permanently disabled. Please try reseating\n"
- "this device or replacing it.\n",
- drv_str, pci_str, frozen_pdn->eeh_freeze_count);
+ "EEH: PCI device at location=%s driver=%s pci addr=%s \n"
+ "has failed %d times and has been permanently disabled. \n"
+ "Please try reseating this device or replacing it.\n",
+ location, drv_str, pci_str, frozen_pdn->eeh_freeze_count);
goto perm_error;
hard_fail:
printk(KERN_ERR
- "EEH: Unable to recover from failure of PCI device %s - %s\n"
+ "EEH: Unable to recover from failure of PCI device "
+ "at location=%s driver=%s pci addr=%s \n"
"Please try reseating this device or replacing it.\n",
- drv_str, pci_str);
+ location, drv_str, pci_str);
perm_error:
eeh_slot_error_detail(frozen_pdn, 2 /* Permanent Error */);
^ permalink raw reply
* [PATCH] powerpc: RTAS delay, fix module build breaks
From: John Rose @ 2006-06-15 22:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: External List, Anton Blanchard
In-Reply-To: <17553.4390.79327.634945@cargo.ozlabs.ibm.com>
Export both news RTAS delay functions, and change the scanlog module to
use the new delay functions.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
---
Respun against the powerpc git tree. Thanks Paul.
2_6_ppc-johnrose/arch/powerpc/kernel/rtas.c | 1 +
2_6_ppc-johnrose/arch/powerpc/platforms/pseries/scanlog.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff -puN arch/powerpc/kernel/rtas.c~finish_delay_reorg arch/powerpc/kernel/rtas.c
--- 2_6_ppc/arch/powerpc/kernel/rtas.c~finish_delay_reorg 2006-06-15 17:27:20.000000000 -0500
+++ 2_6_ppc-johnrose/arch/powerpc/kernel/rtas.c 2006-06-15 17:28:11.000000000 -0500
@@ -797,6 +797,7 @@ EXPORT_SYMBOL(rtas_call);
EXPORT_SYMBOL(rtas_data_buf);
EXPORT_SYMBOL(rtas_data_buf_lock);
EXPORT_SYMBOL(rtas_busy_delay_time);
+EXPORT_SYMBOL(rtas_busy_delay);
EXPORT_SYMBOL(rtas_get_sensor);
EXPORT_SYMBOL(rtas_get_power_level);
EXPORT_SYMBOL(rtas_set_power_level);
diff -puN arch/powerpc/platforms/pseries/scanlog.c~finish_delay_reorg arch/powerpc/platforms/pseries/scanlog.c
--- 2_6_ppc/arch/powerpc/platforms/pseries/scanlog.c~finish_delay_reorg 2006-06-15 17:28:30.000000000 -0500
+++ 2_6_ppc-johnrose/arch/powerpc/platforms/pseries/scanlog.c 2006-06-15 17:29:30.000000000 -0500
@@ -107,9 +107,9 @@ static ssize_t scanlog_read(struct file
/* Break to sleep default time */
break;
default:
- if (status > 9900 && status <= 9905) {
- wait_time = rtas_extended_busy_delay_time(status);
- } else {
+ /* Assume extended busy */
+ wait_time = rtas_busy_delay_time(status);
+ if (!wait_time) {
printk(KERN_ERR "scanlog: unknown error from rtas: %d\n", status);
return -EIO;
}
_
^ permalink raw reply
* Re: [PATCH]: powerpc: pseries: Print PCI slot location code on failure
From: Paul Mackerras @ 2006-06-15 22:42 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060615221527.GD12389@austin.ibm.com>
Linas Vepstas writes:
> Resending an older patch (from 28 April) that seems to have fallen
> through the cracks, its not in mailine, is not in -mm and its not
> controversial (its mostly a printk change). Tested.
I don't like doing printk on things that might be NULL (i.e. the
result of get_property). Even though printk doesn't crash, it would
be nicer for the user to see "location=unknown" or something rather
than "location=<NULL>".
Paul.
^ permalink raw reply
* Re: MSI support on Linux PCI implementation for Ocotea
From: Benjamin Herrenschmidt @ 2006-06-15 23:22 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev, ppcembed
In-Reply-To: <c3d0340b0606151414q6d218554j255fa74a68a5c9af@mail.gmail.com>
On Thu, 2006-06-15 at 14:14 -0700, Shawn Jin wrote:
> Hi,
>
> I'm looking at the linux PCI implementation, especially MSI support
> for Ocotea. And I have some observations and questions about it. Maybe
> somebody here can shed some light on them. Thanks.
Hi ! What is Ocotea ! :)
> 1. Obviously MSI is supported in Linux 2.6.x, maybe even in 2.4.x. But
> MSI implementation seems to support only IOxAPIC on x86 or IA64
> architectures, though the implemenation is in generic drivers/pci
> tree.
Exact. And it's also a pile of crap.
> 2. Why is the message data defined in a such way shown as follows? Or
> does it just follow IOxAPIC's design? Further question is who defines
> the format of the message data. The PCI/PCIe specs don't say anything
> about the content of the message data register.
.../...
It's all intel specific junk.
> 3. How is the pci subsystem initialized on a PPC platform? Is there
> any existing document discussing PCI subsystem? Of course I've been
> doing a lot internet search and couldn't find too much useful infor.
pci host bridges are initialized early, generally in setup_arch() and
the PCI bus is probed later. You can see the code in
arch/powerpc/kernel/pci_{32,64}.c
Now, regarding MSI, as you have noticed, the situation isn't great. I'm
currently in the middle of reworking our interrupt management (and
interrupt numbers allocation layer) and Michael Ellermann is looking at
the MSI issue in parallel.
We don't have a solution yet but are working on it.
Ben.
^ permalink raw reply
* Re: MSI support on Linux PCI implementation for Ocotea
From: Roland Dreier @ 2006-06-15 23:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppcdev, ppcembed
In-Reply-To: <1150413771.7725.20.camel@localhost.localdomain>
Benjamin> Hi ! What is Ocotea ! :)
It's an eval board for some PowerPC 440 ... 440GX I think (which has
the HW capability to support MSI on PCI-X iirc)
- R.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 64k pages on non-partitioned machines
From: Anton Blanchard @ 2006-06-16 0:14 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, torvalds, Paul Mackerras
In-Reply-To: <200606151508.46613.arnd.bergmann@de.ibm.com>
Hi Arnd,
> Actually, I thought we decided to postpone 64k page support on cell
> to 2.6.18 already. This patch alone is not enough to make it work,
> at least one more fix is needed for being able to boot, while
> the spu file system needs major changes for it.
We are hitting the bug on other ppc64 systems too, so I think its worth
fixing for 2.6.17.
Anton
^ permalink raw reply
* Re: MSI support on Linux PCI implementation for Ocotea
From: Shawn Jin @ 2006-06-16 0:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppcdev, ppcembed
In-Reply-To: <1150413771.7725.20.camel@localhost.localdomain>
> Hi ! What is Ocotea ! :)
Did I spell it wrong?? I don't believe Ben doesn't know Ocotea.
Hmmm...Ocotea again? Let me check if I really spelled it wrong. Hey,
it's really Ocotea. ;)
Of course, there is no such MSI support specific for Ocotea.
> > 1. Obviously MSI is supported in Linux 2.6.x, maybe even in 2.4.x. But
> > MSI implementation seems to support only IOxAPIC on x86 or IA64
> > architectures, though the implemenation is in generic drivers/pci
> > tree.
>
> Exact. And it's also a pile of crap.
;) I'm not in a position where I can either agree or disagree with
you. :D But may I ask if ppc platform can make use of this crap in our
PCI express testing? That is, are the functionalities of this crap
working?
> pci host bridges are initialized early, generally in setup_arch() and
> the PCI bus is probed later. You can see the code in
> arch/powerpc/kernel/pci_{32,64}.c
>
> Now, regarding MSI, as you have noticed, the situation isn't great. I'm
> currently in the middle of reworking our interrupt management (and
> interrupt numbers allocation layer) and Michael Ellermann is looking at
> the MSI issue in parallel.
>
> We don't have a solution yet but are working on it.
It's good to know the development status. What's the relationship
between generic pci driver layer in drivers/pci and architecture
specific implementation? One thing I notice is that architectures
provide pcibios_init() and do resource allocation while the generic
driver provides PCI generic functions such as pci_scan_device().
Thanks,
-Shawn.
^ permalink raw reply
* Re: Interrupt occurs but UIC0 MSR is still 0
From: Eugene Surovegin @ 2006-06-16 2:02 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <4491D34B.4060201@ics-ltd.com>
On Thu, Jun 15, 2006 at 05:38:19PM -0400, Chris Dumoulin wrote:
> Hi All,
> I'm working with a 2.6 linux kernel in a board with a PPC405 in a Virtex
> II Pro FPGA. I'm trying to generate interrupts and handle them in a
> device driver that I've written.
> Here is the sequence of events that happen currently:
> 1. I generate an interrupt by setting registers in an interrupt
> controller we've got in the FPGA (it's a Xilinx LogicCORE OPB Interrupt
> Controller).
> 2. The function do_IRQ, in arch/powerpc/kernel/irq.c, is called.
> 3. ppc_md.get_irq is called from do_IRQ.
> 4. ppc_md.get_irq points to ppc4xx_pic_get_irq in
> arch/ppc/syslib/ppc4xx_pic.c.
> 5. ppc4xx_pic_get_irq reads the MSR from UIC0 to determine the IRQ. In
> my case, the MSR is all zero, so ppc4xx_pic_get_irq returns -1.
> 6. After this, we return from the interrupt, and do_IRQ is called again
> and again, going through the same steps indefinitely.
I don't think ppc4xx_pic.c is correct file for Xilinx Virtex II Pro.
You should be using xilinx_pic.c probably.
--
Eugene
^ permalink raw reply
* Re: [PATCH] powerpc: Use soft irq-disable on all 64-bit machines
From: Stephen Rothwell @ 2006-06-16 3:24 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060614172309.59d7b76e.sfr@canb.auug.org.au>
On Wed, 14 Jun 2006 17:23:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 14 Jun 2006 17:08:40 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Looks good. A couple of small fixes below.
>
> Plus we want the below as well ...
And this ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 434461a..c6b0400 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -89,6 +89,8 @@ system_call_common:
addi r9,r1,STACK_FRAME_OVERHEAD
ld r11,exception_marker@toc(r2)
std r11,-16(r9) /* "regshere" marker */
+ lbz r10,PACAPROCENABLED(r13)
+ std r10,SOFTE(r1)
#ifdef CONFIG_PPC_ISERIES
/* Hack for handling interrupts when soft-enabling on iSeries */
cmpdi cr1,r0,0x5555 /* syscall 0x5555 */
@@ -96,8 +98,6 @@ #ifdef CONFIG_PPC_ISERIES
crand 4*cr0+eq,4*cr1+eq,4*cr0+eq
beq hardware_interrupt_entry
#endif
- lbz r10,PACAPROCENABLED(r13)
- std r10,SOFTE(r1)
mfmsr r11
ori r11,r11,MSR_EE
mtmsrd r11,1
^ permalink raw reply related
* Block driver question (MPC852 with DoC)
From: deepesh @ 2006-06-16 8:37 UTC (permalink / raw)
To: linuxppc-dev
Processor: MPC852
OS : linuxppc-2.4.20 from denx
DoC: Disk On Chip, A block device.
We are using DiskOnChip on our board. And we have got a block driver from
the vendor, which can be insmoded.
The request function of the block driver:
DeviceRequest() {
some error checkings;
list_add_tail(&queue,&requestsList);
wake_up(&waitQueueHead);
}
There is an kernel thread which does the final block read-writes to the
disk on chip:
IOKernelThread() {
while(1) {
set_current_state(TASK_INTERRUPTIBLE);
interruptible_sleep_on_timeout(&waitQueueHead,1);
while(!list_empty(&requestsList)) {
read/write to the disk;
list_del(&queue);
}
}
}
The list manipulations happen in the DeviceRequest and the IOKernelThread.
Is there a potential chance of a race condition, when a timer interrupt
occurs?
Thank you,
Deepesh
^ permalink raw reply
* Re: Interrupt occurs but UIC0 MSR is still 0
From: Chris Dumoulin @ 2006-06-16 14:38 UTC (permalink / raw)
To: Chris Dumoulin, linuxppc-embedded
In-Reply-To: <20060616020221.GA3366@gate.ebshome.net>
Thanks Eugene,
You were right on the money. I changed the appropriate Makefile to
include xilinx_pic.c, instead of ppc4xx_pic.c, and things are now
working. It seems like the UIC of the PPC405 isn't used (or doesn't
exist) in the Virtex II Pro. The interrupt servicing code interfaces
with an external interrupt controller (OPB Interrupt Controller, in my
case) instead.
Regards,
Chris Dumoulin
Eugene Surovegin wrote:
> On Thu, Jun 15, 2006 at 05:38:19PM -0400, Chris Dumoulin wrote:
>
>> Hi All,
>> I'm working with a 2.6 linux kernel in a board with a PPC405 in a Virtex
>> II Pro FPGA. I'm trying to generate interrupts and handle them in a
>> device driver that I've written.
>> Here is the sequence of events that happen currently:
>> 1. I generate an interrupt by setting registers in an interrupt
>> controller we've got in the FPGA (it's a Xilinx LogicCORE OPB Interrupt
>> Controller).
>> 2. The function do_IRQ, in arch/powerpc/kernel/irq.c, is called.
>> 3. ppc_md.get_irq is called from do_IRQ.
>> 4. ppc_md.get_irq points to ppc4xx_pic_get_irq in
>> arch/ppc/syslib/ppc4xx_pic.c.
>> 5. ppc4xx_pic_get_irq reads the MSR from UIC0 to determine the IRQ. In
>> my case, the MSR is all zero, so ppc4xx_pic_get_irq returns -1.
>> 6. After this, we return from the interrupt, and do_IRQ is called again
>> and again, going through the same steps indefinitely.
>>
>
> I don't think ppc4xx_pic.c is correct file for Xilinx Virtex II Pro.
> You should be using xilinx_pic.c probably.
>
>
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: Binding FCC interfaces to device names in reverse order
From: Laurent Pinchart @ 2006-06-16 14:50 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060615165344.7db8444e@vitb.ru.mvista.com>
> > Does anyone know why changing the device ids breaks the fs_enet driver ?
>
> Obviously, because board-specific platform_data fixup use that id field to
> detect what soc device is that - fcc1 or fcc2 this case. So the phy's will
> be wrong-assigned, as well as other stuff.
>
> To change order pdevs are registered, you may try to disable all the fccs
> at the startup, and then enable them after ppc_sys_init, or just shoot
> enable-disable seq (this was't tested at all, but supposed to work).
Enabling the FCCs in a device_initcall() call instead of arch_initcall()
works. I had to call ppc_sys_device_fixup manually.
Thanks for your help.
Laurent Pinchart
^ permalink raw reply
* secondary CPU kicking on 86xx
From: Jon Loeliger @ 2006-06-16 14:58 UTC (permalink / raw)
To: linuxppc-dev
Ben and folks,
I have a question regarding your comments on our proposed
additions for the mpc86xx secondary CPU release code.
We need a way to bounce the secondary CPUs through the
reset vector at 0x100, and can either statically lay down
an address like GEMINI does today:
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -348,6 +348,9 @@ #define EXC_XFER_EE_LITE(n, hdlr) \
#if defined(CONFIG_GEMINI) && defined(CONFIG_SMP)
. = 0x100
b __secondary_start_gemini
+#elif defined(CONFIG_PPC_86xx) && defined(CONFIG_SMP)
+ . = 0x100
+ b __secondary_hold_mpc86xx
#else
EXCEPTION(0x100, Reset, unknown_exception, EXC_XFER_STD)
#endif
Or we can dynamically rewrite a branch instruction into
the reset vector from C code during smp_kick_cpu() time
like the current powermac code does.
I have working code for both; just need opinions
and preferences on correct approach/style voiced!
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add wrappers
From: Mike Kravetz @ 2006-06-16 16:11 UTC (permalink / raw)
To: Paul Mackerras
Cc: Bryan Rosenburg, linuxppc-dev, Nathan Lynch, Christopher Yeoh
In-Reply-To: <17552.36563.460775.131555@cargo.ozlabs.ibm.com>
On Thu, Jun 15, 2006 at 08:33:55AM +1000, Paul Mackerras wrote:
> Nathan Lynch writes:
>
> > Without disabling preemption around the mfspr ... update_stats section
> > in these hcall wrappers, you risk updating the stats on the wrong cpu.
>
> I think we are only looking for total counts and times anyway, so it
> doesn't really matter which cpu updates the stats, as long as the time
> gets accounted on some cpu. The use of per-cpu counters is just for
> better cache behaviour.
Thought about this a little more.
We do an mfspr to get a 'timestamp' before the actual hcall. Then, make
the hcall and do another mfspr after. Isn't it possible to be preempted
and perform the mfspr's on separate CPUs? Worse yet, wouldn't this possibly
add 'time preempted' to the hcall time?. Do we have the same (skewed time)
issue with interrupts?
Thinking that enable/disable around the call might be worth the overhead.
But, disabling interrupts would not be worth it.
--
Mike
^ permalink raw reply
* Re: MSI support on Linux PCI implementation for Ocotea
From: Shawn Jin @ 2006-06-16 21:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppcdev
In-Reply-To: <1150413771.7725.20.camel@localhost.localdomain>
Hi Ben,
> Now, regarding MSI, as you have noticed, the situation isn't great. I'm
> currently in the middle of reworking our interrupt management (and
> interrupt numbers allocation layer) and Michael Ellermann is looking at
> the MSI issue in parallel.
Just one point about MSI(-X) message address and data format. I think
it should be the platform that defines the content. Current
implementation doesn't have this flexibility. We have a design where
MSI mode uses message data to carry vector number info while MSI-X
mode uses message address to carry this info. Although it seems
strange, but I think it's allowed by the spec.
Thanks,
-Shawn.
^ permalink raw reply
* Re: MSI support on Linux PCI implementation for Ocotea
From: Benjamin Herrenschmidt @ 2006-06-16 22:13 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <c3d0340b0606161445w5acb4da8j26870f56a4bf4d9@mail.gmail.com>
On Fri, 2006-06-16 at 14:45 -0700, Shawn Jin wrote:
> Hi Ben,
>
> > Now, regarding MSI, as you have noticed, the situation isn't great. I'm
> > currently in the middle of reworking our interrupt management (and
> > interrupt numbers allocation layer) and Michael Ellermann is looking at
> > the MSI issue in parallel.
>
> Just one point about MSI(-X) message address and data format. I think
> it should be the platform that defines the content.
That's an obvious requirement :)
> Current
> implementation doesn't have this flexibility. We have a design where
> MSI mode uses message data to carry vector number info while MSI-X
> mode uses message address to carry this info. Although it seems
> strange, but I think it's allowed by the spec.
The current implementation is bad :) There are some patches for altix
that are in -mm that add some platform hooks that make the situation a
little bit better, but it's still far from perfect.
Ben.
^ permalink raw reply
* Re: secondary CPU kicking on 86xx
From: Benjamin Herrenschmidt @ 2006-06-16 22:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1FrFmI-0002Vn-UE@jdl.com>
> Or we can dynamically rewrite a branch instruction into
> the reset vector from C code during smp_kick_cpu() time
> like the current powermac code does.
>
> I have working code for both; just need opinions
> and preferences on correct approach/style voiced!
Second approach. #ifdef are evil and they prevent multiple board support
in the same kernel.
Ben.
^ permalink raw reply
* RE: MPC5200B SPI PSC3 Problem
From: Trueskew @ 2006-06-17 4:22 UTC (permalink / raw)
To: linuxppc-embedded
Ok, I'm slightly less confused, and since I may have caused confusion I'll
clarify a little here. Sorry if some of you knew this already.
The MPC5200B has an SPI interface described in Chapter 17 of the MPC5200B
Users Guide. It uses either lines PSC3_6 - PSC3_9, or some of the Timer
pins. The MPC5200B also has an SPI available through the PSCs that use the
codec lines (PSC3_0 - PSC3_3). Depending on what rev of the user's guide
you have, there's a table in Chapter 15 that suggests you can set up PSC3
for Codec and SPI. Unfortunately, the SPI they're talking about is the
8-bit SPI, not the PSC3 SPI.
That was the basic source for my confusion. Hints here and in other places
and some parts of the manual suggested, but it was the scope that really
drove that home for me. I won't elaborate anymore here since for all I know
I'm the only person who just figured that out, but if anyone is struggling
like I just did and has any questions, I'm not a guru but I'll try to help.
Good luck.
^ permalink raw reply
* Using bestcomm in an external module (MPC5200B to be exact)
From: Trueskew @ 2006-06-17 4:47 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]
I'm writing a driver for a TI codec attached to the MPC5200B PSC3 codec
lines on a Lite5200b. It's an external module, and I'd like to use Bestcomm
with it. I've already tried a bunch of horrible things to get it to work.
I could say it's close, but by close I mean the FEC still runs, my stuff
doesn't.
1. Can the Bestcomm I/F be used by an external module, or is the module
required to be built in if built-in drivers use Bestcomm? TasksInitAPI (no
so bad) and TasksLoadImage (yeah, bad) aren't really supposed to be called
more than once from what I've read, and the kernel loads them for ethernet
and ATA (no disk in my system if that matters).
2. If it can be used by an external module, how would I do it? I've tried
compiling the source into my module and replicating the initialization the
kernel does in addition to my own stuff. It's not too bad, though I don't
get any interrupts yet.
The LTIB from Freescale includes AIC23 and AC97 drivers that use Bestcomm.
I built my kernel with them set as modules, and they had the same unresolved
problems that my driver has on insmod, so I'm pessimistic. If someone could
put me out of my misery one way or another, I'd appreciate it.
Thanks.
Sal
[-- Attachment #2: Type: text/html, Size: 2767 bytes --]
^ permalink raw reply
* Re: Using bestcomm in an external module (MPC5200B to be exact)
From: Frank Bennett @ 2006-06-17 18:53 UTC (permalink / raw)
To: Trueskew; +Cc: linuxppc-embedded
In-Reply-To: <4493894e.6d57ffd8.019a.ffff95b9@mx.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]
Trueskew wrote:
> I'm writing a driver for a TI codec attached to the MPC5200B PSC3
> codec lines on a Lite5200b. It's an external module, and I'd like to
> use Bestcomm with it. I've already tried a bunch of horrible things
> to get it to work. I could say it's close, but by close I mean the
> FEC still runs, my stuff doesn't.
>
> 1. Can the Bestcomm I/F be used by an external module, or is the
> module required to be built in if built-in drivers use Bestcomm?
> TasksInitAPI (no so bad) and TasksLoadImage (yeah, bad) aren't really
> supposed to be called more than once from what I've read, and the
> kernel loads them for ethernet and ATA (no disk in my system if that
> matters).
>
> 2. If it can be used by an external module, how would I do it? I've
> tried compiling the source into my module and replicating the
> initialization the kernel does in addition to my own stuff. It's not
> too bad, though I don't get any interrupts yet.
>
> The LTIB from Freescale includes AIC23 and AC97 drivers that use
> Bestcomm. I built my kernel with them set as modules, and they had
> the same unresolved problems that my driver has on insmod, so I'm
> pessimistic. If someone could put me out of my misery one way or
> another, I'd appreciate it.
Might check out the driver posted by Bob Petersen:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-September/020210.html
using DENX linuxppc_2_4_devel/arch/ppc/5xxx_io/ i2s.c, psc.c and Bestcomm/
Frank
>
> Thanks.
> Sal
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
*/Frank Bennett
President/*
Mathegraphics,LLC
613 Bentley Pl
Fort Collins,CO 80526
970-229-9269 (hm) 970-402-9269 (cell)
www.mathegraphics.com <http://www.mathegraphics.com>
bennett78@digis.net <mailto:bennett78@digis.net>
[-- Attachment #2: Type: text/html, Size: 4215 bytes --]
^ permalink raw reply
* [PATCH] Guard L3CR references with CPU_FTR_L3CR.
From: Jon Loeliger @ 2006-06-17 22:49 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/kernel/cpu_setup_6xx.S | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S b/arch/powerpc/kernel/cpu_setup_6xx.S
index 55ed771..365381f 100644
--- a/arch/powerpc/kernel/cpu_setup_6xx.S
+++ b/arch/powerpc/kernel/cpu_setup_6xx.S
@@ -210,9 +210,11 @@ setup_745x_specifics:
* the firmware. If any, we disable NAP capability as
* it's known to be bogus on rev 2.1 and earlier
*/
+BEGIN_FTR_SECTION
mfspr r11,SPRN_L3CR
andis. r11,r11,L3CR_L3E@h
beq 1f
+END_FTR_SECTION_IFSET(CPU_FTR_L3CR)
lwz r6,CPU_SPEC_FEATURES(r5)
andi. r0,r6,CPU_FTR_L3_DISABLE_NAP
beq 1f
^ permalink raw reply related
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