* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-28 13:55 UTC (permalink / raw)
To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <46D4257C.7060208@fz-juelich.de>
On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> Grant Likely wrote:
> > On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> >
> >> Grant Likely wrote:
> >>
> >>> You've got 2 choices:
> >>> 1. use the new sysace driver; it's already in mainline. The new
> >>> driver is faster, but it doesn't handle hotswap of the CF card (yet)
> >>>
> >>>
> >> But where in menuconfig could i find the sysace driver ? i'm blind, i
> >> think :)
> >>
> >
> > Which version of kernel are you using? The new sysace driver was
> > merged into 2.6.22
> >
> >
> linux-2.6.22.5
Should be under drivers->block devices then.
> >>> 2. use the EDK driver; easiest way is to use my tree which already hasGrant Likely <grant.likely@secretlab.ca>
> >>> it merged: http://git.secretlab.ca
> >>>
> >>>
> >>>
> >> i made an EDK update and now i have the linux_2_2 os in the software
> >> options. the bsp with all drivers is generated.
> >> and now ?
> >> - copy to kernel tree
> >> - use the xmake to build the kernel, or make ?
> >>
> > Grant Likely <grant.likely@secretlab.ca>
> > Don't use EDK to build you're kernel. It's too fragile and you need
> > to use the *exact* version of kernel that EDK expects. You're better
> > off to manually copy the xparams file from the generated BSP. (ie.
> > Don't let EDK know where your real kernel source tree is)
> >
> wuh ? i dont need all the driver from the generatet bsp files ? what
> about the gpios and leds ?
Most drivers are already in my tree; any that are missing you can copy
over manually.
> i compile the kernel with a self made cross toolchain, not with the edk.
> until now i copied the bsp files into the kernel tree (modfied some
> defines) und compile with "make zImage". But know with the linux_2_6
> option there is some more stuff in the bsp directory and i don't know
> what to do with :)
>
> >
> >> and why is there no dokumentation :)
> >
> > Care to write some?
> >
> huh, not really :)
> im just a little newbie
best way to learn. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-08-28 13:50 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0708281531060.3856-100000@slslc02.psi.ch>
On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> Hi Grant,
>
> Thanks for your answer.
> I have found in the System.map :
> c020f0c4 b __log_buf
>
> Is the address c020f0c4 relative to the .data segment?
0xc0000000 are virtual kernel addresses; not physical addresses. If
the MMU is still on, then you need to use the virtual address to
examine memory. If the MMU is off (such as after reloading u-boot),
then you need to change 0xCxxxxxxx to 0x0xxxxxxxx.
> I understand that when the system hangs I should type in the XMD window
> stop.
>
> Is there anyway to examine the memory from the XMD window? or should I
> reload the u-boot and examine the memory from u-boot?
I don't know; I've never used XMD. Read the XMD documentation. You
can do it from u-boot too.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-28 13:39 UTC (permalink / raw)
Cc: Linux PPC Linux PPC
In-Reply-To: <fa686aa40708280630x67856334qaf2e0dd59ecb95bf@mail.gmail.com>
Grant Likely wrote:
> On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
>
>> Grant Likely wrote:
>>
>>> You've got 2 choices:
>>> 1. use the new sysace driver; it's already in mainline. The new
>>> driver is faster, but it doesn't handle hotswap of the CF card (yet)
>>>
>>>
>> But where in menuconfig could i find the sysace driver ? i'm blind, i
>> think :)
>>
>
> Which version of kernel are you using? The new sysace driver was
> merged into 2.6.22
>
>
linux-2.6.22.5
>>> 2. use the EDK driver; easiest way is to use my tree which already hasGrant Likely <grant.likely@secretlab.ca>
>>> it merged: http://git.secretlab.ca
>>>
>>>
>>>
>> i made an EDK update and now i have the linux_2_2 os in the software
>> options. the bsp with all drivers is generated.
>> and now ?
>> - copy to kernel tree
>> - use the xmake to build the kernel, or make ?
>>
> Grant Likely <grant.likely@secretlab.ca>
> Don't use EDK to build you're kernel. It's too fragile and you need
> to use the *exact* version of kernel that EDK expects. You're better
> off to manually copy the xparams file from the generated BSP. (ie.
> Don't let EDK know where your real kernel source tree is)
>
wuh ? i dont need all the driver from the generatet bsp files ? what
about the gpios and leds ?
i compile the kernel with a self made cross toolchain, not with the edk.
until now i copied the bsp files into the kernel tree (modfied some
defines) und compile with "make zImage". But know with the linux_2_6
option there is some more stuff in the bsp directory and i don't know
what to do with :)
>
>> and why is there no dokumentation :)
>>
>
> Care to write some?
>
>
huh, not really :)
im just a little newbie
G
> g.
>
>
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-28 13:37 UTC (permalink / raw)
To: Grant Likely; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <fa686aa40708280602vc00920do459a087c25b830e1@mail.gmail.com>
Hi Grant,
Thanks for your answer.
I have found in the System.map :
c020f0c4 b __log_buf
Is the address c020f0c4 relative to the .data segment?
I understand that when the system hangs I should type in the XMD window
stop.
Is there anyway to examine the memory from the XMD window? or should I
reload the u-boot and examine the memory from u-boot?
Best Regards
Mirek
On Tue, 28 Aug 2007, Grant Likely wrote:
> On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> > Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
> > nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
> > ip=::::virtex4-mirek:eth0:dhcp panic=1
> > Uncompressing Linux...
> >
> >
> > After that system just hangs.
> >
> > I do not understand why it is possible to run zImage.elf straight from jtag
> > but it hangs when started from u-boot.
> >
> > Is it any fundamental problem with running Linux from u-boot on ML403
> > (Virtex-4) boards?
>
> No there isn't. It should work. Most likely the kernel did not hang
> immediately, but rather the console is not setup correctly. You need
> to halt the processor after the hang and look at __log_buf in memory
> (Find the address in System.map).
>
> Cheers,
> g.
>
> >
> > Best Regards
> >
> > Mirek
> >
> >
>
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-28 13:30 UTC (permalink / raw)
To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <46D4221D.8030500@fz-juelich.de>
On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> Grant Likely wrote:
> >
> > You've got 2 choices:
> > 1. use the new sysace driver; it's already in mainline. The new
> > driver is faster, but it doesn't handle hotswap of the CF card (yet)
> >
> But where in menuconfig could i find the sysace driver ? i'm blind, i
> think :)
Which version of kernel are you using? The new sysace driver was
merged into 2.6.22
>
> > 2. use the EDK driver; easiest way is to use my tree which already has
> > it merged: http://git.secretlab.ca
> >
> >
> i made an EDK update and now i have the linux_2_2 os in the software
> options. the bsp with all drivers is generated.
> and now ?
> - copy to kernel tree
> - use the xmake to build the kernel, or make ?
Don't use EDK to build you're kernel. It's too fragile and you need
to use the *exact* version of kernel that EDK expects. You're better
off to manually copy the xparams file from the generated BSP. (ie.
Don't let EDK know where your real kernel source tree is)
>
> and why is there no dokumentation :)
Care to write some?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] PS3: fix the bug the major version part is not compared
From: Andreas Schwab @ 2007-08-28 13:26 UTC (permalink / raw)
To: Masakazu Mokuno; +Cc: Geert Uytterhoeven, linuxppc-dev, paulus
In-Reply-To: <20070828211415.C2B5.MOKUNO@sm.sony.co.jp>
Masakazu Mokuno <mokuno@sm.sony.co.jp> writes:
> Fix the bug that the major version part of the firmware
> is not compared.
>
> Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
> CC: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> arch/powerpc/platforms/ps3/setup.c | 2 +-
> include/asm-powerpc/ps3.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --- a/arch/powerpc/platforms/ps3/setup.c
> +++ b/arch/powerpc/platforms/ps3/setup.c
> @@ -54,7 +54,7 @@ void ps3_get_firmware_version(union ps3_
> }
> EXPORT_SYMBOL_GPL(ps3_get_firmware_version);
>
> -int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
> +s64 ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
> {
> union ps3_firmware_version x;
>
Better yet: normalize the return value.
return (ps3_firmware_version.raw > x.raw) -
(ps3_firmware_version.raw < x.raw);
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-28 13:24 UTC (permalink / raw)
Cc: Linux PPC Linux PPC
In-Reply-To: <fa686aa40708280606p67fd74p9287d041d955c538@mail.gmail.com>
Grant Likely wrote:
> On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
>
>> Hi Grant,
>>
>> i need your help again :)
>>
>> my 2.6. kernel is running. now i want to add the system ace driver to
>> mount a rootfs on the systemace-flash.
>> but i don't know how to import the EKD driver to the linux kernel, or is
>> there a ready to go driver in the kernel tree ?
>> i didn't find anything...
>>
>
> You've got 2 choices:
> 1. use the new sysace driver; it's already in mainline. The new
> driver is faster, but it doesn't handle hotswap of the CF card (yet)
>
But where in menuconfig could i find the sysace driver ? i'm blind, i
think :)
> 2. use the EDK driver; easiest way is to use my tree which already has
> it merged: http://git.secretlab.ca
>
>
i made an EDK update and now i have the linux_2_2 os in the software
options. the bsp with all drivers is generated.
and now ?
- copy to kernel tree
- use the xmake to build the kernel, or make ?
and why is there no dokumentation :)
Thanks a lot
Georg
> Cheers,
> g.
>
>
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-28 13:06 UTC (permalink / raw)
To: schardt, Linux PPC Linux PPC
In-Reply-To: <46D41298.7060109@fz-juelich.de>
On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> Hi Grant,
>
> i need your help again :)
>
> my 2.6. kernel is running. now i want to add the system ace driver to
> mount a rootfs on the systemace-flash.
> but i don't know how to import the EKD driver to the linux kernel, or is
> there a ready to go driver in the kernel tree ?
> i didn't find anything...
You've got 2 choices:
1. use the new sysace driver; it's already in mainline. The new
driver is faster, but it doesn't handle hotswap of the CF card (yet)
2. use the EDK driver; easiest way is to use my tree which already has
it merged: http://git.secretlab.ca
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-08-28 13:02 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0708281300570.31877-100000@slslc02.psi.ch>
On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
> nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
> ip=::::virtex4-mirek:eth0:dhcp panic=1
> Uncompressing Linux...
>
>
> After that system just hangs.
>
> I do not understand why it is possible to run zImage.elf straight from jtag
> but it hangs when started from u-boot.
>
> Is it any fundamental problem with running Linux from u-boot on ML403
> (Virtex-4) boards?
No there isn't. It should work. Most likely the kernel did not hang
immediately, but rather the console is not setup correctly. You need
to halt the processor after the hang and look at __log_buf in memory
(Find the address in System.map).
Cheers,
g.
>
> Best Regards
>
> Mirek
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC 440EPx: Sequoia bootwrapper
From: Valentine Barshak @ 2007-08-28 12:54 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20070816055135.GH3540@localhost.localdomain>
David Gibson wrote:
> On Wed, Aug 15, 2007 at 04:22:58PM +0400, Valentine Barshak wrote:
>> David Gibson wrote:
>>> On Tue, Aug 14, 2007 at 10:53:55PM +0400, Valentine Barshak wrote:
>>>> Bootwrapper code for AMCC 440EPx Sequoia board.
>>>> The DDR2 Denali controller support has been moved to
>>>> arch/powerpc/boot/4xx.c
>>>> The code also uses 440EP clocking fixups
>>>> initially provided for 440EP Bamboo.
>>>>
>>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> [snip]
>>>> diff -ruN linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c linux-2.6/arch/powerpc/boot/cuboot-sequoia.c
>>>> --- linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c 1970-01-01 03:00:00.000000000 +0300
>>>> +++ linux-2.6/arch/powerpc/boot/cuboot-sequoia.c 2007-08-14 17:25:37.000000000 +0400
>>>> @@ -0,0 +1,31 @@
>>>> +/*
>>>> + * Old U-boot compatibility for Sequoia
>>>> + *
>>>> + * Based on Ebony code by David Gibson <david@gibson.dropbear.id.au>
>>>> + *
>>>> + * Copyright 2007 David Gibson, IBM Corporatio.
>>>> + * Based on cuboot-83xx.c, which is:
>>>> + * Copyright (c) 2007 Freescale Semiconductor, Inc.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify it
>>>> + * under the terms of the GNU General Public License version 2 as published
>>>> + * by the Free Software Foundation.
>>>> + */
>>>> +
>>>> +#include "ops.h"
>>>> +#include "stdio.h"
>>>> +#include "44x.h"
>>>> +#include "cuboot.h"
>>>> +
>>>> +#define TARGET_4xx
>>>> +#define TARGET_44x
>>> Surely you need to be more specific than that to select the correct
>>> bd_t structure?
>> Both TARGET_4xx and TARGET_44x should be selected for 44x. Otherwise I
>> get wrong bd_t structure (wrong offsets to the eth0/eth1 MAC addresses).
>> In the older arch/ppc code it used to be CONFIG_4xx and it was selected
>> for CONFIG_40x and CONFIG_44x as well.
>
> Yes, I'm not objecting to those TARGET macros, but I'd be very
> surprised if you don't need more to really get the correct bd_t
> structure.
Sorry, I don't quite follow.
As far as I can tell the bd_t structure looks OK.
Could you be more specific, please?
What exactly do you think I need to get the correct bd_t?
Thanks,
Valentine.
>
> [snip]
>>>> diff -ruN linux-2.6.orig/arch/powerpc/boot/sequoia.c linux-2.6/arch/powerpc/boot/sequoia.c
>>>> --- linux-2.6.orig/arch/powerpc/boot/sequoia.c 1970-01-01 03:00:00.000000000 +0300
>>>> +++ linux-2.6/arch/powerpc/boot/sequoia.c 2007-08-14 20:52:10.000000000 +0400
>>> Unless another bootloader is expected to come along for Sequoia,
>>> there's no reason to separate sequoia.c from cuboot-sequoia.c
>> The previous version of Sequoia series had treeboot-sequoia.c, but I've
>> removed it since only u-boot is used now.
>> I'm not sure if there are any other bootloaders expected, but is it OK
>> if I leave 2 separate files just in case? :)
>
> Not unless you have a particular reason to expect another bootloader
> will come along, which doesn't seem that likely to me. Or rather the
> only likely future bootloader I'd see is newer versions of u-boot
> which are device tree aware and handled separately anyway.
>
^ permalink raw reply
* [PATCH] PS3: fix the bug the major version part is not compared
From: Masakazu Mokuno @ 2007-08-28 12:32 UTC (permalink / raw)
To: paulus; +Cc: Geert Uytterhoeven, linuxppc-dev
Fix the bug that the major version part of the firmware
is not compared.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
CC: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/setup.c | 2 +-
include/asm-powerpc/ps3.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -54,7 +54,7 @@ void ps3_get_firmware_version(union ps3_
}
EXPORT_SYMBOL_GPL(ps3_get_firmware_version);
-int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
+s64 ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
{
union ps3_firmware_version x;
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -36,7 +36,7 @@ union ps3_firmware_version {
};
void ps3_get_firmware_version(union ps3_firmware_version *v);
-int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev);
+s64 ps3_compare_firmware_version(u16 major, u16 minor, u16 rev);
/* 'Other OS' area */
--
Masakazu MOKUNO
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Evgeniy Polyakov @ 2007-08-28 12:16 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: tklein, themann, stefan.roscher, netdev, James Chapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger,
David Miller
In-Reply-To: <200708281348.21302.ossthema@de.ibm.com>
On Tue, Aug 28, 2007 at 01:48:20PM +0200, Jan-Bernd Themann (ossthema@de.ibm.com) wrote:
> I'm not sure if I understand your approach correctly.
> This approach may reduce the number of interrupts, but it does so
> by blocking the CPU for up to 1 jiffy (that can be quite some time
> on some platforms). So no other application / tasklet / softIRQ type
> can do anything in between. The CPU utilization does not drop at all,
> and I thought that is one reason why we try to reduce the number of interrupts.
Only NICs interrupts are suposed to be stopped, system will continue to
work as usual, since all others are alive.
Having hrtimer to reshcedule NIC procesing can work only if number of
timer's interrupts are much less than NICs and if rate of the timer's
starts/changes (presumbly in NICs interrupt) is small too, otherwise
having too many NIC interrupts will not gain anything (actually it is
what is supposed to be dropped noticebly).
--
Evgeniy Polyakov
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-28 11:48 UTC (permalink / raw)
To: James Chapman
Cc: tklein, themann, stefan.roscher, netdev, linux-kernel, raisch,
linuxppc-dev, akepner, meder, shemminger, David Miller
In-Reply-To: <46D3E971.4010909@katalix.com>
On Tuesday 28 August 2007 11:22, James Chapman wrote:
> > So in this scheme what runs ->poll() to process incoming packets?
> > The hrtimer?
>
> No, the regular NAPI networking core calls ->poll() as usual; no timers
> are involved. This scheme simply delays the napi_complete() from the
> driver so the device stays in the poll list longer. It means that its
> ->poll() will be called when there is no work to do for 1-2 jiffies,
> hence the optimization at the top of ->poll() to efficiently handle that
> case. The device's ->poll() is called by the NAPI core until it has
> continuously done no work for 1-2 jiffies, at which point it finally
> does the netif_rx_complete() and re-enables its interrupts.
>
I'm not sure if I understand your approach correctly.
This approach may reduce the number of interrupts, but it does so
by blocking the CPU for up to 1 jiffy (that can be quite some time
on some platforms). So no other application / tasklet / softIRQ type
can do anything in between. The CPU utilization does not drop at all,
and I thought that is one reason why we try to reduce the number of interrupts.
> If people feel that holding the device in the poll list for 1-2 jiffies
> is too long (because there are too many wasted polls), a counter could
> be used to to delay the netif_rx_complete() by N polls instead. N would
> be a value depending on CPU speed. I use the jiffy sampling method
> because it results in some natural randomization of the actual delay
> depending on when the jiffy value was sampled in relation to the jiffy tick.
>
Waiting for N polls seems to make no sense if there are no further network adapters
in that machine. It would take no time to call poll N times in a row when no
new packets arrive. There is no real delay as the net_rx_action function will
do nothing else between the poll calls.
Please correct me if I'm wrong.
Regards,
Jan-Bernd
^ permalink raw reply
* [PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
From: Jochen Friedrich @ 2007-08-28 11:20 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Instantiation of 8MB pages on the TLB cache for the kernel static
mapping trashes r3 register on !CONFIG_8xx_CPU6 configurations.
This ensures r3 gets saved and restored.
This has been posted to linuxppc-embedded by Marcelo Tosatti
<marcelo@kvack.org>, but only an incomplete version of the patch
has been applied in c51e078f82096a7d35ac8ec2416272e843a0e1c4.
This patch adds the rest of the fix.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/ppc/kernel/head_8xx.S | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
This can be pulled from git://git.bocc.de/dbox2.git ppc-fixes
[-- Attachment #2: d14ebb1e9d133983252a14f2ef037f76969ab3c6.diff --]
[-- Type: text/x-patch, Size: 362 bytes --]
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index 944c35c..eb8d26f 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -495,9 +495,7 @@ LoadLargeDTLB:
lwz r11, 4(r0)
lwz r12, 16(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is the data TLB error on the MPC8xx. This could be due to
^ permalink raw reply related
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-28 11:21 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070827.140251.95055210.davem@davemloft.net>
Hi
On Monday 27 August 2007 23:02, David Miller wrote:
> But there are huger fish to fry for you I think. Talk to your
> platform maintainers and ask for an interface for obtaining
> a flat static distribution of interrupts to cpus in order to
> support multiqueue NAPI better.
>
> In your previous postings you made arguments saying that the
> automatic placement of interrupts to cpus made everything
> bunch of to a single cpu and you wanted to propagate the
> NAPI work to other cpu's software interrupts from there.
>
> That logic is bogus, because it merely proves that the hardware
> interrupt distribution is broken. If it's a bad cpu to run
> software interrupts on, it's also a bad cpu to run hardware
> interrupts on.
>
As already mentioned some mails were mixed up here. To clarify the interrupt
issue that has nothing to do with the reduction of interrupts:
- Interrupts are distributed the round robin way on IBM POWER6 processors
- Interrupt distribution can be modified by user/daemons (smp_affinity, pinning)
- NAPI is scheduled on CPU where interrupt is catched
- NAPI polls on that CPU as long as poll has packets to process (default)
(David please correct if there is a misunderstanding here)
Problem for multi queue driver with interrupt distribution scheme set to
round robin for this simple example:
Assuming we have 2 SLOW CPUs. CPU_1 is under heavy load (applications). CPU_2
is not under heavy load. Now we receive a lot of packets (high load situation).
Receive queue 1 (RQ1) is scheduled on CPU_1. NAPI-Poll does not manage to empty
RQ1 ever, so it stays on CPU_1. The second receive queue (RQ2) is scheduled on
CPU_2. As that CPU is not under heavy load, RQ2 can be emptied, and the next IRQ
for RQ2 will go to CPU_1. Then both RQs are on CPU_1 and will stay there if
no IRQ is forced at some time as both RQs are never emptied completely.
This is a simplified example to demonstrate the problem. The interrupt scheme
is not bogus, it is just an effect you see if you don't use pinning.
The user can avoid this problem by pinning the interrupts to CPUs.
As pointed out by David, it will be too expensive to schedule NAPI poll on
a different CPU than the one that gets the IRQ. So I guess one solution
is to "force" an HW interrupt when two many RQs are processed on the same CPU
(when no IRQ pinning is used). This is something the driver has to handle.
Regards,
Jan-Bernd
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-28 11:19 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070827.133721.59473971.davem@davemloft.net>
On Monday 27 August 2007 22:37, David Miller wrote:
> From: Jan-Bernd Themann <ossthema@de.ibm.com>
> Date: Mon, 27 Aug 2007 11:47:01 +0200
>
> > So the question is simply: Do we want drivers that need (benefit
> > from) a timer based polling support to implement their own timers
> > each, or should there be a generic support?
>
> I'm trying to figure out how an hrtimer implementation would
> even work.
>
> Would you start the timer from the chip interrupt handler? If so,
> that's taking two steps backwards as you've already taken all of the
> overhead of running the interrupt handler.
I'm also still trying to understand how hrtimer work exactly.
The implementation of hrtimers for P6 has not been finished yet, so
I can't do experiments with hrtimers and eHEA now.
I will try the following scheme (once we get hrtimers):
Each device (queue) has a hrtimer.
Schedule the timer in the poll function instead of reactivating IRQs
when a high load situation has been detected and all packets have
been emptied from the receive queue.
The timer function could then just call netif_rx_schedule to register
the rx_queue for NAPI again.
The advantages of this scheme (if it works as I understood it) would be:
- we don't have to modify NAPI
- benefit from fairness amoung rx_queues / network devices
- The poll function can decide how long to stick to the timer based
polling mode, and when to switch back to it's HW IRQs.
- driver can determine the time to wait based on the receive queue length and
speed
Regards,
Jan-Bernd
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-28 11:18 UTC (permalink / raw)
To: Grant Likely, Leonid; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708270753u1411796fv698d3b39ee908599@mail.gmail.com>
I have done additional test with my u-boot and linux kernel.
I have downloaded u-boot(.elf) and zImage.elf via jtag to SDRAM:
The SDRAM has 32 MB:
Address Map for Processor ppc405_0
(0x00000000-0x01ffffff) DDR_SDRAM_1 plb
The steps I have doe are as following:
1. XMD% dow -data zImage.elf 0xe00000
2. XMD% dow u-boot.elf
section, .text: 0x00800000-0x0081513c
section, .resetvec: 0x0081513c-0x00815140
section, .rodata: 0x00815140-0x00817ce0
section, .reloc: 0x00817d00-0x00818674
section, .data: 0x00818674-0x00818b08
section, .data.rel: 0x00818b08-0x00818b34
section, .data.rel.local: 0x00818b34-0x00818f6c
section, .u_boot_cmd: 0x00818f6c-0x008191dc
section, .bss: 0x00819200-0x0081dd04
Downloaded Program u-boot.elf
Setting PC with program start addr = 0x00800100
PC reset to 0x00800100, Clearing MSR Register
3. XMD% run
------------------------------------------------------------------
output on the serial port
------------------------------------------------------------------
U-Boot 1.2.0 (Aug 28 2007 - 11:56:19)
U-Boot: checkboard
DRAM: U-Boot: initdram
32 MB
Using default environment
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
=>
U-Boot 1.2.0 (Aug 27 2007 - 14:23:15)
U-Boot: checkboard
DRAM: U-Boot: initdram
32 MB
Using default environment
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
=> bootelf 0xe00000
Loading .text @ 0x00400000 (14028 bytes)
Loading .data @ 0x00404000 (995328 bytes)
Clearing .bss @ 0x004f7000 (8504 bytes)
## Starting application at 0x00400000 ...
loaded at: 00400000 004F9138
board data at: 004F7120 004F7138
relocated to: 004040B4 004040CC
zimage at: 00404E59 004F6EE8
avail ram: 004FA000 01FFFFFF
Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...
After that system just hangs.
I do not understand why it is possible to run zImage.elf straight from jtag
but it hangs when started from u-boot.
Is it any fundamental problem with running Linux from u-boot on ML403
(Virtex-4) boards?
Best Regards
Mirek
^ permalink raw reply
* ppc/powerpc, remote debugging (ptrace), floating point variables
From: Visser, Udo RD-IS-E23 @ 2007-08-28 9:40 UTC (permalink / raw)
To: linuxppc-embedded
Hello world, ;-)
when stepping through my own software, which is using floating point =
variables, gdb showed weird results (mostly NAN=B4s) for these =
variables. Running the software without gdb did not show any problems. =
The software is compiled with floating point instructions and the =
results (without gdb) are OK.
My setup:
MPC8349 target, "home grown", much like the MPC8349EMDS, running 2.6.16 =
(ppc)
GDB, gdbserver 6.3 connected via ethernet with my Linux Host.
What I did to get rid of the described problem:
In module: arch/powerpc/kernel/process.c
In function: void flush_fp_to_thread(struct tast_struct *tsk)
I changed the line: giveup_fpu(current);
to: giveup_fpu(tsk);
Now my questions: Has anybody else had such problems?
Have I found a bug, or will I encounter any yet =
unknown problems in the near future?
I would appreciate any comment on my changes, especially from the =
maintainers.
Thank you very much
Udo Visser
Heidelberger Druckmaschinen AG
RD IMAGING SYSTEMS RD-IS-E23
Confidentiality note:
The information in this email and any attachment may contain =
confidential and proprietary information of Heidelberger Druckmaschinen =
AG and/or its affiliates and may be privileged or otherwise protected =
from disclosure. If you are not the intended recipient, you are hereby =
notified that any review, reliance or distribution by others or =
forwarding without express permission is strictly prohibited and may =
cause liability. In case you have received this message due to an error =
in transmission, we kindly ask you to notify the sender immediately and =
to delete this email and any attachment from your system.
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: James Chapman @ 2007-08-28 9:22 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, linux-kernel, raisch,
linuxppc-dev, akepner, meder, ossthema, shemminger
In-Reply-To: <20070827.145600.102570576.davem@davemloft.net>
David Miller wrote:
> From: James Chapman <jchapman@katalix.com>
> Date: Mon, 27 Aug 2007 22:41:43 +0100
>
>> I don't recall saying anything in previous posts about this. Are you
>> confusing my posts with Jan-Bernd's?
>
> Yes, my bad.
>
>> Jan-Bernd has been talking about using hrtimers to _reschedule_
>> NAPI. My posts are suggesting an alternative mechanism that keeps
>> NAPI active (with interrupts disabled) for a jiffy or two after it
>> would otherwise have gone idle in order to avoid too many interrupts
>> when the packet rate is such that NAPI thrashes between poll-on and
>> poll-off.
>
> So in this scheme what runs ->poll() to process incoming packets?
> The hrtimer?
No, the regular NAPI networking core calls ->poll() as usual; no timers
are involved. This scheme simply delays the napi_complete() from the
driver so the device stays in the poll list longer. It means that its
->poll() will be called when there is no work to do for 1-2 jiffies,
hence the optimization at the top of ->poll() to efficiently handle that
case. The device's ->poll() is called by the NAPI core until it has
continuously done no work for 1-2 jiffies, at which point it finally
does the netif_rx_complete() and re-enables its interrupts.
If people feel that holding the device in the poll list for 1-2 jiffies
is too long (because there are too many wasted polls), a counter could
be used to to delay the netif_rx_complete() by N polls instead. N would
be a value depending on CPU speed. I use the jiffy sampling method
because it results in some natural randomization of the actual delay
depending on when the jiffy value was sampled in relation to the jiffy tick.
Here is the tg3 patch again that illustrates the idea. The patch changes
only the ->poll() routine; note how the netif_rx_complete() call is delayed.
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 710dccc..59e151b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3473,6 +3473,24 @@ static int tg3_poll(struct napi_struct *napi,
struct tg3_hw_status *sblk = tp->hw_status;
int work_done = 0;
+ /* fastpath having no work while we're holding ourself in
+ * polled mode
+ */
+ if ((tp->exit_poll_time) && (!tg3_has_work(tp))) {
+ if (time_after(jiffies, tp->exit_poll_time)) {
+ tp->exit_poll_time = 0;
+ /* tell net stack and NIC we're done */
+ netif_rx_complete(netdev, napi);
+ tg3_restart_ints(tp);
+ }
+ return 0;
+ }
+
+ /* if we get here, there might be work to do so disable the
+ * poll hold fastpath above
+ */
+ tp->exit_poll_time = 0;
+
/* handle link change and other phy events */
if (!(tp->tg3_flags &
(TG3_FLAG_USE_LINKCHG_REG |
@@ -3511,11 +3529,11 @@ static int tg3_poll(struct napi_struct *napi,
} else
sblk->status &= ~SD_STATUS_UPDATED;
- /* if no more work, tell net stack and NIC we're done */
- if (!tg3_has_work(tp)) {
- netif_rx_complete(netdev, napi);
- tg3_restart_ints(tp);
- }
+ /* if no more work, set the time in jiffies when we should
+ * exit polled mode
+ */
+ if (!tg3_has_work(tp))
+ tp->exit_poll_time = jiffies + 2;
return work_done;
}
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index a6a23bb..a0d24d3 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2163,6 +2163,7 @@ struct tg3 {
u32 last_tag;
u32 msg_enable;
+ unsigned long exit_poll_time;
/* begin "tx thread" cacheline section */
void (*write32_tx_mbox) (struct tg3 *, u32,
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply related
* RE: STK5200 pci_enable_device problem
From: Mustafa Cayir @ 2007-08-28 8:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20070827191419.9A9CE24044@gemini.denx.de>
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
Hi,
i build Linux-2.6.22-gbcfc8d37 kernel lastest kernel from denx git for the board (STK5200 with TQM5200-AB).
ELDK 4.1 version is used.
make mrproper
export ARCH=powerpc
make tqm5200_defconfig
make uImage
It hangs on after following line
Uncompressing Kernel Image ... OK
Our u-boot version : U-Boot 1.1.3 (Apr 7 2005 - 14:42:37)
Any idea will be appreciated.
Regards.
done
Bytes transferred = 1454056 (162fe8 hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.22-gbcfc8d37
Created: 2007-08-28 19:41:27 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1453992 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Mon 8/27/2007 10:14 PM
To: Mustafa Cayir
Cc: Oliver Rutsch; linuxppc-embedded@ozlabs.org
Subject: Re: STK5200 pci_enable_device problem
In message <7B9A8FF57DBB524190E98CABF6E56F070B927E@itri.bte.mam.gov.tr> you wrote:
>
> i use 2.4.25 kernel and eldk 3.1.1 on TQM5200 board. i tried denx 2.6.19
> kernel to port on TQM5200 but i couldn't.
> Did you port 2.6 kernel on TQM5200? Did pci device start working
> succesfully after porting 2.6 kernel to TQM5200 board.
Current top-of-tree in our git repo has been tested with a Intel
EEPRO100 network card in the ST5200's PCI slot. It's working.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Unsichtbar macht sich die Dummheit, indem sie immer größere Ausmaße
annimmt. -- Bertold Brecht: Der Tui-Roman
[-- Attachment #2: Type: text/html, Size: 2905 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] Add an optional device_node pointer to the irq_host
From: Michael Ellerman @ 2007-08-28 8:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <460e86e8b5a08c23dcbedb5d4bd484a519246dd3.1188290811.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]
On Tue, 2007-08-28 at 18:47 +1000, Michael Ellerman wrote:
> The majority of irq_host implementations (3 out of 4) are associated
> with a device_node, and need to stash it somewhere. Rather than having
> it somewhere different for each host, add an optional device_node pointer
> to the irq_host structure.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
This series is basically unchanged since I last sent it, but applies
cleanly now onto the powerpc-for-2.6.24 branch.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 5/5] Export virq mapping via debugfs
From: Michael Ellerman @ 2007-08-28 8:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <460e86e8b5a08c23dcbedb5d4bd484a519246dd3.1188290811.git.michael@ellerman.id.au>
This patch adds a debugfs file "powerpc/virq_mapping", which shows the virtual
to real mapping of irq numbers. Enable it with CONFIG_VIRQ_DEBUG.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Chen Gong <G.Chen@freescale.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig.debug | 10 +++++++
arch/powerpc/kernel/irq.c | 63 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 22acece..c38bc22 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -124,6 +124,16 @@ config IRQSTACKS
for handling hard and soft interrupts. This can help avoid
overflowing the process kernel stacks.
+config VIRQ_DEBUG
+ bool "Expose hardware/virtual IRQ mapping via debugfs"
+ depends on DEBUG_FS && PPC_MERGE
+ help
+ This option will show the mapping relationship between hardware irq
+ numbers and virtual irq numbers. The mapping is exposed via debugfs
+ in the file powerpc/virq_mapping.
+
+ If you don't know what this means you don't need it.
+
config BDI_SWITCH
bool "Include BDI-2000 user context switcher"
depends on DEBUG_KERNEL && PPC32
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 1339f32..0e47c8c 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -52,6 +52,7 @@
#include <linux/mutex.h>
#include <linux/bootmem.h>
#include <linux/pci.h>
+#include <linux/debugfs.h>
#include <asm/uaccess.h>
#include <asm/system.h>
@@ -1006,6 +1007,68 @@ static int irq_late_init(void)
}
arch_initcall(irq_late_init);
+#ifdef CONFIG_VIRQ_DEBUG
+static int virq_debug_show(struct seq_file *m, void *private)
+{
+ unsigned long flags;
+ irq_desc_t *desc;
+ const char *p;
+ char none[] = "none";
+ int i;
+
+ seq_printf(m, "%-5s %-7s %-15s %s\n", "virq", "hwirq",
+ "chip name", "host name");
+
+ for (i = 1; i < NR_IRQS; i++) {
+ desc = get_irq_desc(i);
+ spin_lock_irqsave(&desc->lock, flags);
+
+ if (desc->action && desc->action->handler) {
+ seq_printf(m, "%5d ", i);
+ seq_printf(m, "0x%05lx ", virq_to_hw(i));
+
+ if (desc->chip && desc->chip->typename)
+ p = desc->chip->typename;
+ else
+ p = none;
+ seq_printf(m, "%-15s ", p);
+
+ if (irq_map[i].host && irq_map[i].host->of_node)
+ p = irq_map[i].host->of_node->full_name;
+ else
+ p = none;
+ seq_printf(m, "%s\n", p);
+ }
+
+ spin_unlock_irqrestore(&desc->lock, flags);
+ }
+
+ return 0;
+}
+
+static int virq_debug_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, virq_debug_show, inode->i_private);
+}
+
+static const struct file_operations virq_debug_fops = {
+ .open = virq_debug_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static int __init irq_debugfs_init(void)
+{
+ if (debugfs_create_file("virq_mapping", S_IRUGO, powerpc_debugfs_root,
+ NULL, &virq_debug_fops))
+ return -ENOMEM;
+
+ return 0;
+}
+__initcall(irq_debugfs_init);
+#endif /* CONFIG_VIRQ_DEBUG */
+
#endif /* CONFIG_PPC_MERGE */
#ifdef CONFIG_PPC64
--
1.5.1.3.g7a33b
^ permalink raw reply related
* [PATCH 4/5] Initialise hwirq for legacy irqs
From: Michael Ellerman @ 2007-08-28 8:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <460e86e8b5a08c23dcbedb5d4bd484a519246dd3.1188290811.git.michael@ellerman.id.au>
Although no one uses the hwirq value for legacy irqs at the moment, we
should really setup the correct value in the irq_map.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/irq.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index d5c7e4c..1339f32 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -487,7 +487,7 @@ __init_refok struct irq_host *irq_alloc_host(struct device_node *of_node,
host->inval_irq = 0;
/* setup us as the host for all legacy interrupts */
for (i = 1; i < NUM_ISA_INTERRUPTS; i++) {
- irq_map[i].hwirq = 0;
+ irq_map[i].hwirq = i;
smp_wmb();
irq_map[i].host = host;
smp_wmb();
--
1.5.1.3.g7a33b
^ permalink raw reply related
* [PATCH 3/5] Provide a default irq_host match, which matches on an exact of_node
From: Michael Ellerman @ 2007-08-28 8:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <460e86e8b5a08c23dcbedb5d4bd484a519246dd3.1188290811.git.michael@ellerman.id.au>
The most common match semantic is an exact match based on the device node.
So provide a default implementation that does this, and hook it up if no
match routine is specified.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/irq.c | 10 +++++++++-
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 7 -------
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 6 ------
arch/powerpc/platforms/cell/axon_msi.c | 6 ------
arch/powerpc/platforms/cell/spider-pic.c | 6 ------
arch/powerpc/sysdev/commproc.c | 6 ------
arch/powerpc/sysdev/cpm2_pic.c | 6 ------
arch/powerpc/sysdev/mpc8xx_pic.c | 6 ------
arch/powerpc/sysdev/mv64x60_pic.c | 6 ------
arch/powerpc/sysdev/tsi108_pci.c | 6 ------
arch/powerpc/sysdev/uic.c | 6 ------
11 files changed, 9 insertions(+), 62 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 30fb8e2..d5c7e4c 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -418,6 +418,11 @@ irq_hw_number_t virq_to_hw(unsigned int virq)
}
EXPORT_SYMBOL_GPL(virq_to_hw);
+static int default_irq_host_match(struct irq_host *h, struct device_node *np)
+{
+ return h->of_node != NULL && h->of_node == np;
+}
+
__init_refok struct irq_host *irq_alloc_host(struct device_node *of_node,
unsigned int revmap_type,
unsigned int revmap_arg,
@@ -449,6 +454,9 @@ __init_refok struct irq_host *irq_alloc_host(struct device_node *of_node,
host->ops = ops;
host->of_node = of_node;
+ if (host->ops->match == NULL)
+ host->ops->match = default_irq_host_match;
+
spin_lock_irqsave(&irq_big_lock, flags);
/* If it's a legacy controller, check for duplicates and
@@ -523,7 +531,7 @@ struct irq_host *irq_find_host(struct device_node *node)
*/
spin_lock_irqsave(&irq_big_lock, flags);
list_for_each_entry(h, &irq_hosts, link)
- if (h->ops->match != NULL && h->ops->match(h, node)) {
+ if (h->ops->match(h, node)) {
found = h;
break;
}
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
index 1d793e4..0f4ca8a 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -241,12 +241,6 @@ static struct irq_chip mpc52xx_sdma_irqchip = {
* irq_host
*/
-static int mpc52xx_irqhost_match(struct irq_host *h, struct device_node *node)
-{
- pr_debug("%s: node=%p\n", __func__, node);
- return h->of_node == node;
-}
-
static int mpc52xx_irqhost_xlate(struct irq_host *h, struct device_node *ct,
u32 * intspec, unsigned int intsize,
irq_hw_number_t * out_hwirq,
@@ -367,7 +361,6 @@ static int mpc52xx_irqhost_map(struct irq_host *h, unsigned int virq,
}
static struct irq_host_ops mpc52xx_irqhost_ops = {
- .match = mpc52xx_irqhost_match,
.xlate = mpc52xx_irqhost_xlate,
.map = mpc52xx_irqhost_map,
};
diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
index 91ddbd2..4008795 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
@@ -398,11 +398,6 @@ m82xx_pci_irq_demux(unsigned int irq, struct irq_desc *desc)
}
}
-static int pci_pic_host_match(struct irq_host *h, struct device_node *node)
-{
- return h->of_node == node;
-}
-
static int pci_pic_host_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
@@ -418,7 +413,6 @@ static void pci_host_unmap(struct irq_host *h, unsigned int virq)
}
static struct irq_host_ops pci_pic_host_ops = {
- .match = pci_pic_host_match,
.map = pci_pic_host_map,
.unmap = pci_host_unmap,
};
diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index bdd97bb..74407af 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -294,13 +294,7 @@ static int msic_host_map(struct irq_host *h, unsigned int virq,
return 0;
}
-static int msic_host_match(struct irq_host *host, struct device_node *dn)
-{
- return host->of_node == dn;
-}
-
static struct irq_host_ops msic_host_ops = {
- .match = msic_host_match,
.map = msic_host_map,
};
diff --git a/arch/powerpc/platforms/cell/spider-pic.c b/arch/powerpc/platforms/cell/spider-pic.c
index 4309c2c..3f4b4ae 100644
--- a/arch/powerpc/platforms/cell/spider-pic.c
+++ b/arch/powerpc/platforms/cell/spider-pic.c
@@ -175,11 +175,6 @@ static struct irq_chip spider_pic = {
.set_type = spider_set_irq_type,
};
-static int spider_host_match(struct irq_host *h, struct device_node *node)
-{
- return h->of_node == node;
-}
-
static int spider_host_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
@@ -206,7 +201,6 @@ static int spider_host_xlate(struct irq_host *h, struct device_node *ct,
}
static struct irq_host_ops spider_host_ops = {
- .match = spider_host_match,
.map = spider_host_map,
.xlate = spider_host_xlate,
};
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index 05dc30b..b562afc 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -94,11 +94,6 @@ int cpm_get_irq(void)
return irq_linear_revmap(cpm_pic_host, cpm_vec);
}
-static int cpm_pic_host_match(struct irq_host *h, struct device_node *node)
-{
- return h->of_node == node;
-}
-
static int cpm_pic_host_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
@@ -126,7 +121,6 @@ static struct irqaction cpm_error_irqaction = {
};
static struct irq_host_ops cpm_pic_host_ops = {
- .match = cpm_pic_host_match,
.map = cpm_pic_host_map,
};
diff --git a/arch/powerpc/sysdev/cpm2_pic.c b/arch/powerpc/sysdev/cpm2_pic.c
index d9ab30c..d5b36e0 100644
--- a/arch/powerpc/sysdev/cpm2_pic.c
+++ b/arch/powerpc/sysdev/cpm2_pic.c
@@ -205,11 +205,6 @@ unsigned int cpm2_get_irq(void)
return irq_linear_revmap(cpm2_pic_host, irq);
}
-static int cpm2_pic_host_match(struct irq_host *h, struct device_node *node)
-{
- return h->of_node == node;
-}
-
static int cpm2_pic_host_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
@@ -233,7 +228,6 @@ static int cpm2_pic_host_xlate(struct irq_host *h, struct device_node *ct,
}
static struct irq_host_ops cpm2_pic_host_ops = {
- .match = cpm2_pic_host_match,
.map = cpm2_pic_host_map,
.xlate = cpm2_pic_host_xlate,
};
diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c b/arch/powerpc/sysdev/mpc8xx_pic.c
index f20a4d4..565156a 100644
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -119,11 +119,6 @@ unsigned int mpc8xx_get_irq(void)
}
-static int mpc8xx_pic_host_match(struct irq_host *h, struct device_node *node)
-{
- return h->of_node == node;
-}
-
static int mpc8xx_pic_host_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
@@ -157,7 +152,6 @@ static int mpc8xx_pic_host_xlate(struct irq_host *h, struct device_node *ct,
static struct irq_host_ops mpc8xx_pic_host_ops = {
- .match = mpc8xx_pic_host_match,
.map = mpc8xx_pic_host_map,
.xlate = mpc8xx_pic_host_xlate,
};
diff --git a/arch/powerpc/sysdev/mv64x60_pic.c b/arch/powerpc/sysdev/mv64x60_pic.c
index a145bfd..19e6ef2 100644
--- a/arch/powerpc/sysdev/mv64x60_pic.c
+++ b/arch/powerpc/sysdev/mv64x60_pic.c
@@ -202,11 +202,6 @@ static struct irq_chip mv64x60_chip_gpp = {
* mv64x60_host_ops functions
*/
-static int mv64x60_host_match(struct irq_host *h, struct device_node *np)
-{
- return h->of_node == np;
-}
-
static struct irq_chip *mv64x60_chips[] = {
[MV64x60_LEVEL1_LOW] = &mv64x60_chip_low,
[MV64x60_LEVEL1_HIGH] = &mv64x60_chip_high,
@@ -228,7 +223,6 @@ static int mv64x60_host_map(struct irq_host *h, unsigned int virq,
}
static struct irq_host_ops mv64x60_host_ops = {
- .match = mv64x60_host_match,
.map = mv64x60_host_map,
};
diff --git a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
index b41492a..31d3d33 100644
--- a/arch/powerpc/sysdev/tsi108_pci.c
+++ b/arch/powerpc/sysdev/tsi108_pci.c
@@ -404,13 +404,7 @@ static int pci_irq_host_map(struct irq_host *h, unsigned int virq,
return 0;
}
-static int pci_irq_host_match(struct irq_host *h, struct device_node *node)
-{
- return h->of_node == node;
-}
-
static struct irq_host_ops pci_irq_host_ops = {
- .match = pci_irq_host_match,
.map = pci_irq_host_map,
.xlate = pci_irq_host_xlate,
};
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index bf37667..5149716 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -215,11 +215,6 @@ out_unlock:
spin_unlock(&desc->lock);
}
-static int uic_host_match(struct irq_host *h, struct device_node *node)
-{
- return h->of_node == node;
-}
-
static int uic_host_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
@@ -249,7 +244,6 @@ static int uic_host_xlate(struct irq_host *h, struct device_node *ct,
}
static struct irq_host_ops uic_host_ops = {
- .match = uic_host_match,
.map = uic_host_map,
.xlate = uic_host_xlate,
};
--
1.5.1.3.g7a33b
^ permalink raw reply related
* [PATCH 2/5] Invert null match behaviour for irq_hosts
From: Michael Ellerman @ 2007-08-28 8:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <460e86e8b5a08c23dcbedb5d4bd484a519246dd3.1188290811.git.michael@ellerman.id.au>
Currently if you don't specify a match callback for your irq_host it's
assumed you match everything. This is a kind of opt-out approach, and
turns out to be the exception rather than the rule.
So change the semantics to be opt-in, ie. you don't match anything unless
you provide a match callback. This in itself isn't very useful, but will
allow us to provide a default match implementation in a subsequent patch.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/irq.c | 2 +-
arch/powerpc/platforms/celleb/interrupt.c | 7 +++++++
arch/powerpc/platforms/iseries/irq.c | 7 +++++++
arch/powerpc/platforms/ps3/interrupt.c | 7 +++++++
4 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 79b4512..30fb8e2 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -523,7 +523,7 @@ struct irq_host *irq_find_host(struct device_node *node)
*/
spin_lock_irqsave(&irq_big_lock, flags);
list_for_each_entry(h, &irq_hosts, link)
- if (h->ops->match == NULL || h->ops->match(h, node)) {
+ if (h->ops->match != NULL && h->ops->match(h, node)) {
found = h;
break;
}
diff --git a/arch/powerpc/platforms/celleb/interrupt.c b/arch/powerpc/platforms/celleb/interrupt.c
index 4ecdf06..c7c68ca 100644
--- a/arch/powerpc/platforms/celleb/interrupt.c
+++ b/arch/powerpc/platforms/celleb/interrupt.c
@@ -175,11 +175,18 @@ static int beatic_pic_host_xlate(struct irq_host *h, struct device_node *ct,
return 0;
}
+static int beatic_pic_host_match(struct irq_host *h, struct device_node *np)
+{
+ /* Match all */
+ return 1;
+}
+
static struct irq_host_ops beatic_pic_host_ops = {
.map = beatic_pic_host_map,
.remap = beatic_pic_host_remap,
.unmap = beatic_pic_host_unmap,
.xlate = beatic_pic_host_xlate,
+ .match = beatic_pic_host_match,
};
/*
diff --git a/arch/powerpc/platforms/iseries/irq.c b/arch/powerpc/platforms/iseries/irq.c
index 3666746..701d929 100644
--- a/arch/powerpc/platforms/iseries/irq.c
+++ b/arch/powerpc/platforms/iseries/irq.c
@@ -346,8 +346,15 @@ static int iseries_irq_host_map(struct irq_host *h, unsigned int virq,
return 0;
}
+static int iseries_irq_host_match(struct irq_host *h, struct device_node *np)
+{
+ /* Match all */
+ return 1;
+}
+
static struct irq_host_ops iseries_irq_host_ops = {
.map = iseries_irq_host_map,
+ .match = iseries_irq_host_match,
};
/*
diff --git a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c
index 30b9f4c..3a6db04 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -673,9 +673,16 @@ static int ps3_host_map(struct irq_host *h, unsigned int virq,
return 0;
}
+static int ps3_host_match(struct irq_host *h, struct device_node *np)
+{
+ /* Match all */
+ return 1;
+}
+
static struct irq_host_ops ps3_host_ops = {
.map = ps3_host_map,
.unmap = ps3_host_unmap,
+ .match = ps3_host_match,
};
void __init ps3_register_ipi_debug_brk(unsigned int cpu, unsigned int virq)
--
1.5.1.3.g7a33b
^ 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