* 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
* [PATCH] Prevent duplicate lmb reservations for Device Tree blob.
From: Jon Loeliger @ 2006-06-17 22:51 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
We talked about preventing the device tree blob from being
reserved multiple times. This patch implements it.
arch/powerpc/kernel/prom.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index d77d24a..6290232 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -1267,13 +1267,16 @@ static void __init early_reserve_mem(voi
{
u64 base, size;
u64 *reserve_map;
+ unsigned long self_base;
+ unsigned long self_size;
reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
initial_boot_params->off_mem_rsvmap);
/* before we do anything, lets reserve the dt blob */
- lmb_reserve(__pa((unsigned long)initial_boot_params),
- initial_boot_params->totalsize);
+ self_base = __pa((unsigned long)initial_boot_params);
+ self_size = initial_boot_params->totalsize;
+ lmb_reserve(self_base, self_size);
#ifdef CONFIG_PPC32
/*
@@ -1289,6 +1292,9 @@ #ifdef CONFIG_PPC32
size_32 = *(reserve_map_32++);
if (size_32 == 0)
break;
+ /* skip if the reservation is for the blob */
+ if (base_32 == self_base && size_32 == self_size)
+ continue;
DBG("reserving: %x -> %x\n", base_32, size_32);
lmb_reserve(base_32, size_32);
}
@@ -1300,6 +1306,9 @@ #endif
size = *(reserve_map++);
if (size == 0)
break;
+ /* skip if the reservation is for the blob */
+ if (base == self_base && size == self_size)
+ continue;
DBG("reserving: %llx -> %llx\n", base, size);
lmb_reserve(base, size);
}
^ permalink raw reply related
* [PATCH 0/9 v3] Introduce the MPC8641 HPCN platform
From: Jon Loeliger @ 2006-06-17 22:52 UTC (permalink / raw)
To: linuxppc-dev
This is the third posting of a series of patches
that introduces the MPC8641 HPCN platform. This
version corrects all of the suggestions from Kumar,
and shows an ACK from Jeff Garzik for the netdev
related parts. It also addresses all of the problems
that Ben brought up related to multi-platform issues.
It does not use IRQ settings from the device tree yet;
that will come as a follow on patch when Ben's IRQ
rewrite is more solid.
Please consider this for addition into the 2.6.18 queue.
Collectively:
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: Wei Zhang <Wei.Zhang@freescale.com>
Signed-off-by: Jeff Brown <Jeff.Brown@freescale.com>
Signed-off-by: Kriston Carson <KristonCarson@freescale.com>
Acked-by: Jeff Garzik <jeff@garzik.org>
^ permalink raw reply
* [PATCH 1/9 v3] Add the mpc8641 hpcn Kconfig and Makefiles.
From: Jon Loeliger @ 2006-06-17 22:52 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/Kconfig | 15 ++++++++++++--
arch/powerpc/platforms/Makefile | 1 +
arch/powerpc/platforms/86xx/Kconfig | 36 ++++++++++++++++++++++++++++++++++
arch/powerpc/platforms/86xx/Makefile | 10 +++++++++
4 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4ef2478..65f4cd1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -141,6 +141,15 @@ config PPC_85xx
select FSL_SOC
select 85xx
+config PPC_86xx
+ bool "Freescale 86xx"
+ select 6xx
+ select FSL_SOC
+ select PPC_FPU
+ select ALTIVEC
+ help
+ The Freescale E600 SoCs have 74xx cores.
+
config 40x
bool "AMCC 40x"
@@ -549,6 +558,7 @@ source arch/powerpc/platforms/embedded6x
source arch/powerpc/platforms/4xx/Kconfig
source arch/powerpc/platforms/83xx/Kconfig
source arch/powerpc/platforms/85xx/Kconfig
+source arch/powerpc/platforms/86xx/Kconfig
source arch/powerpc/platforms/8xx/Kconfig
source arch/powerpc/platforms/cell/Kconfig
@@ -780,6 +790,7 @@ config GENERIC_ISA_DMA
config PPC_I8259
bool
+ default y if MPC8641_HPCN
default n
config PPC_INDIRECT_PCI
@@ -802,8 +813,8 @@ config MCA
bool
config PCI
- bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_MPC52xx || (EMBEDDED && PPC_ISERIES)
- default y if !40x && !CPM2 && !8xx && !APUS && !PPC_83xx && !PPC_85xx
+ bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx || PPC_MPC52xx || (EMBEDDED && PPC_ISERIES)
+ default y if !40x && !CPM2 && !8xx && !APUS && !PPC_83xx && !PPC_85xx && !PPC_86xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx && APUS
default PCI_QSPAN if !4xx && !CPM2 && 8xx
help
diff --git a/arch/powerpc/platforms/Makefile b/arch/powerpc/platforms/Makefile
index c4f6b0d..2928636 100644
--- a/arch/powerpc/platforms/Makefile
+++ b/arch/powerpc/platforms/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_PPC_CHRP) += chrp/
obj-$(CONFIG_4xx) += 4xx/
obj-$(CONFIG_PPC_83xx) += 83xx/
obj-$(CONFIG_PPC_85xx) += 85xx/
+obj-$(CONFIG_PPC_86xx) += 86xx/
obj-$(CONFIG_PPC_PSERIES) += pseries/
obj-$(CONFIG_PPC_ISERIES) += iseries/
obj-$(CONFIG_PPC_MAPLE) += maple/
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
new file mode 100644
index 0000000..3a87863
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -0,0 +1,36 @@
+menu "Platform Support"
+ depends on PPC_86xx
+
+choice
+ prompt "Machine Type"
+ default MPC8641_HPCN
+
+config MPC8641_HPCN
+ bool "Freescale MPC8641 HPCN"
+ help
+ This option enables support for the MPC8641 HPCN board.
+
+endchoice
+
+
+config MPC8641
+ bool
+ select PPC_INDIRECT_PCI
+ select PPC_UDBG_16550
+ default y if MPC8641_HPCN
+
+config MPIC
+ bool
+ default y
+
+config PPC_INDIRECT_PCI_BE
+ bool
+ depends on PPC_86xx
+ default y
+
+config PPC_STD_MMU
+ bool
+ depends on PPC_86xx
+ default y
+
+endmenu
diff --git a/arch/powerpc/platforms/86xx/Makefile b/arch/powerpc/platforms/86xx/Makefile
new file mode 100644
index 0000000..7be796c
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -0,0 +1,10 @@
+#
+# 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
^ 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