* Xilinx Linux git server
From: Wolfgang Reissnegger @ 2007-11-14 1:38 UTC (permalink / raw)
To: linuxppc-embedded, uclinux-dev
Hi all,
I'm happy to announce that the Xilinx Linux Kernel git server is finally up and running and available to the public.
The Xilinx Linux Kernel is based on the mainline Linux Kernel from kernel.org and adds driver support for various Xilinx IP cores and Xilinx reference boards. It contains many (but not all) of the MicroBlaze contributions and enhancements from John Williams' PetaLogix Linux distribution and some PPC work from Grant Likely. It also contains contributions from Stephen Neuendorffer, Joachim Foerster and Brian Hill, to name a few.
The kernel includes drivers to support the following Xilinx IP cores:
* EMAC, EMACLITE, TEMAC, LLTEMAC
* UART, UARTLITE
* SYSACE
* SPI, GPIO, FB, GPIO, HWICAP, AC97
and support for the following boards:
* ML40x, ML4x0
* Spartan 3E 1600, XUPV2P
In a couple weeks we will be adding MicroBlaze v7 MMU support.
The kernel is licensed under the GPL version 2 and is provided AS IS. It is _not_ supported in any way or form by the Xilinx Support Center. If you call the Xilinx Support center, they will not be able to help you. For those interested in a supported Linux distribution, please contact one of the many partner companies at:
http://www.xilinx.com/ise/embedded/epartners/listing.htm
Please, also keep in mind that the kernel is not actively being tested and will may set your house on fire.
The git URL for the Xilinx Linux Kernel sources is:
git://git.xilinx.com/linux-2.6-xlnx.git
The Web front-end for this server can be found at:
http://git.xilinx.com
At this time there are two branches available:
* lin26-xlnx
This branch is based on the latest stable kernel release (currently 2.6.23)
* lin26-xlnx-rc
This branch tracks the leading edge mainline (currently 2.6.24-rc2)
The git server also hosts a clone of Grant Likely's OF device tree generation tool with additions by Stephen Neuendorffer to support MicroBlaze systems. The git URL for this repository is:
git://git.xilinx.com/gen-mhs-devtree.git
If you have suggestions or want to contribute to the Xilinx Linux Kernel, please send your feedback, patches or other contributions to:
git _at_ xilinx.com
Hope to hear from you soon :-)
Thanks,
Wolfgang
^ permalink raw reply
* Xilinx Linux git server available
From: Wolfgang Reissnegger @ 2007-11-14 1:56 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm happy to announce that the Xilinx Linux Kernel git server is finally up and running and available to the public.
The Xilinx Linux Kernel is based on the mainline Linux Kernel from kernel.org and adds driver support for various Xilinx IP cores and Xilinx reference boards. It contains many (but not all) of the MicroBlaze contributions and enhancements from John Williams' PetaLogix Linux distribution and some PPC work from Grant Likely. It also contains contributions from Stephen Neuendorffer, Joachim Foerster and Brian Hill, to name a few.
The kernel includes drivers to support the following Xilinx IP cores:
* EMAC, EMACLITE, TEMAC, LLTEMAC
* UART, UARTLITE
* SYSACE
* SPI, GPIO, FB, GPIO, HWICAP, AC97
and support for the following boards:
* ML40x, ML4x0
* Spartan 3E 1600, XUPV2P
In a couple weeks we will be adding MicroBlaze v7 MMU support.
The kernel is licensed under the GPL version 2 and is provided AS IS. It is _not_ supported in any way or form by the Xilinx Support Center. If you call the Xilinx Support center, they will not be able to help you. For those interested in a supported Linux distribution, please contact one of the many partner companies at:
http://www.xilinx.com/ise/embedded/epartners/listing.htm
Please, also keep in mind that the kernel is not actively being tested and will may set your house on fire.
The git URL for the Xilinx Linux Kernel sources is:
git://git.xilinx.com/linux-2.6-xlnx.git
The Web front-end for this server can be found at:
http://git.xilinx.com
At this time there are two branches available:
* lin26-xlnx
This branch is based on the latest stable kernel release (currently 2.6.23)
* lin26-xlnx-rc
This branch tracks the leading edge mainline (currently 2.6.24-rc2)
The git server also hosts a clone of Grant Likely's OF device tree generation tool with additions by Stephen Neuendorffer to support MicroBlaze systems. The git URL for this repository is:
git://git.xilinx.com/gen-mhs-devtree.git
If you have suggestions or want to contribute to the Xilinx Linux Kernel, please send your feedback, patches or other contributions to:
git _at_ xilinx.com
Hope to hear from you soon :-)
Thanks,
Wolfgang
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: 4xx uic updates
From: Josh Boyer @ 2007-11-14 2:05 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, dwg
In-Reply-To: <20071113201559.GA26172@ru.mvista.com>
On Tue, 13 Nov 2007 23:15:59 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> These patches update 4xx uic code. The first one
> fixes a minor issue with edge-triggered interrupts,
> while the second one makes it use generic level and edge irq
> handlers. I've added irq ack'ing to the unmask callback for
> level-triggered interrupts, because to de-assert them we have
> to do 2 things is the exact order as below:
> 1. de-assert the external source in the ISR.
> 2. ack the IRQ on the UIC.
> So, ack'ing level interrupts before unmasking them makes possible
> to use generic level irq handler and it doesn't hurt, cause
> we can never miss a level-triggered interrupt. It always stays
> asserted untill the external source is removed and ack'ed on UIC.
>
> These have been tested on Sequoia PowerPC 440EPx board.
Is my mail server slow, or did patch 2 of 2 never make it out?
josh
^ permalink raw reply
* Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
From: David Gibson @ 2007-11-14 2:13 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071113202731.GA26319@ru.mvista.com>
On Tue, Nov 13, 2007 at 11:27:31PM +0300, Valentine Barshak wrote:
> This patch makes PowerPC 4xx UIC use generic edge and level irq handlers
> instead of a custom handle_uic_irq() function. Acking a level irq on UIC
> has no effect if the interrupt is still asserted by the device, even if
> the interrupt is already masked. So, to really de-assert the interrupt
> we need to de-assert the external source first *and* ack it on UIC then.
> The handle_level_irq() function masks and ack's the interrupt with mask_ack
> callback prior to calling the actual ISR and unmasks it at the end.
> So, to use it with UIC level interrupts we need to ack in the unmask
> callback instead, after the ISR has de-asserted the external interrupt source.
> Even if we ack the interrupt that we didn't handle (unmask/ack it at
> the end of the handler, while next irq is already pending) it will not
> de-assert the irq, untill we de-assert its exteral source.
Hrm. I *think* I'm convinced this is safe, although acking in a
callback which doesn't say it acks is rather yucky. Essentially this
code is trading flow readability (because just reading
handle_level_irq will tell you something other than what it does in
our case) for smaller code size. I'm not sure if this is a good trade
or not.
There's also one definite problem: according to the discussions I had
with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what
we want for edge interrupts.
Apparently handle_edge_irq is only for edge interrupts on "broken"
PICs which won't latch new interrupts while the irq is masked. UIC is
not in this category, so handle_level_irq is actually what we want,
even for an edge irq.
Yes, I thought the naming was more than a little confusing, too.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: 4xx uic updates
From: David Gibson @ 2007-11-14 2:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071113200514.72d03792@zod.rchland.ibm.com>
On Tue, Nov 13, 2007 at 08:05:14PM -0600, Josh Boyer wrote:
> On Tue, 13 Nov 2007 23:15:59 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> > These patches update 4xx uic code. The first one
> > fixes a minor issue with edge-triggered interrupts,
> > while the second one makes it use generic level and edge irq
> > handlers. I've added irq ack'ing to the unmask callback for
> > level-triggered interrupts, because to de-assert them we have
> > to do 2 things is the exact order as below:
> > 1. de-assert the external source in the ISR.
> > 2. ack the IRQ on the UIC.
> > So, ack'ing level interrupts before unmasking them makes possible
> > to use generic level irq handler and it doesn't hurt, cause
> > we can never miss a level-triggered interrupt. It always stays
> > asserted untill the external source is removed and ack'ed on UIC.
> >
> > These have been tested on Sequoia PowerPC 440EPx board.
>
> Is my mail server slow, or did patch 2 of 2 never make it out?
It reached me eventually, but only to my ibm address, not via the
list (whereas I got both copies of 0 and 1).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: printk/console_init - baud rate setting
From: Siva Prasad @ 2007-11-14 2:28 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.62.0711130915480.31003@pademelon.sonytel.be>
Thanks a lot Geert and Benjamin for your response.
Code is indeed calling register_console from three different places=20
1) con_init()[name-tty],=20
2) serial8250_console_init()[name-ttyS],=20
3) early_uart_console_init()[name-uart].=20
Among these, 8250 must be the active one. Also
serial8250_console_write() keeps hitting the BDI2000 break point with
same address and count again and again.
I am getting garbage on the screen. So, I presume this must be some sort
of baud rate issue. Can some one help me out understand how this baud is
set for serial drivers? I want to run at 115200.
Thanks
Siva
-----Original Message-----
From: geert@sonytel.be [mailto:geert@sonytel.be] On Behalf Of Geert
Uytterhoeven
Sent: Tuesday, November 13, 2007 12:17 AM
To: Siva Prasad
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: printk/console_init
On Mon, 12 Nov 2007, Siva Prasad wrote:
> I am using 2.6.19 Linux on 8641D based system.
>=20
> I am using early printk's and it works fine until console_init() is
> executed. After that it does not, as the early printk's get disabled,
> which is fine. However, I don't see any prints after that at all, that
> are based on regular printk statements. I looked directly into the
> memory at __log_buf and found all the print messages. It is just not
> coming out to the serial port properly.
>=20
> It would be great if some one can tell me various parameters that I
need
> to consider changing, to successfully port the serial driver for a new
> board.
>=20
> Based on the early printk's, I am getting the following messages...
>=20
> Using MPC86xx HPCN machine description
> Total memory =3D 1024MB; using 2048kB for hash table (at cfe00000)
> Linux version 2.6.19 (sprasad@cider.bivio.net) (gcc version 4.1.1
> 20060525 (Red Hat 4.1.1-1)) #115 SMP Mon Nov 12 18:21:43 PST 2007
> Found legacy serial port 0 for /soc8641@ff700000/serial@4500
> mem=3Dff704500, taddr=3Dff704500, irq=3D1a, clk=3D1496250, speed=3D0
> Found MPC86xx PCIE host bridge at 0x00000000ff708000. Firmware bus
> number: 0->254
> Found MPC86xx PCIE host bridge at 0x00000000ff709000. Firmware bus
> number: 0->255
> MPC86xx HPCN board from Freescale Semiconductor
> Zone PFN ranges:
> DMA 0 -> 196608
> Normal 196608 -> 196608
> HighMem 196608 -> 262144
> early_node_map[1] active PFN ranges
> 0: 0 -> 262144
> start_kernel: 8 22000000.
> Built 1 zonelists. Total pages: 260096
> Kernel command line: console=3DttyS0,115200 root=3D/dev/sda8
^^^^^^^^^^^^
> mpic: Setting up MPIC " MPIC " version 1.2 at ff740000, max 2 CPUs
> mpic: ISU size: 16, shift: 4, mask: f
> mpic: Initializing for 80 sources
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> time_init: decrementer frequency =3D 150.000000 MHz
> time_init: processor frequency =3D 1496.250000 MHz
> <........ Nothing gets printed after this .......>
Did your serial driver (a) call register_console() (b) using the correct
name?
With kind regards,
=20
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village * Da Vincilaan 7-D1 * B-1935 Zaventem * Belgium
=20
Phone: +32 (0)2 700 8453=09
Fax: +32 (0)2 700 8622=09
E-mail: Geert.Uytterhoeven@sonycom.com=09
Internet: http://www.sony-europe.com/
=09
Sony Network and Software Technology Center Europe=09
A division of Sony Service Centre (Europe) N.V.=09
Registered office: Technologielaan 7 * B-1840 Londerzeel * Belgium=09
VAT BE 0413.825.160 * RPR Brussels=09
Fortis Bank Zaventem * Swift GEBABEBB08A * IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] pci hotplug: fix rpaphp directory naming
From: Greg KH @ 2007-11-14 3:26 UTC (permalink / raw)
To: Linas Vepstas
Cc: rick.jones2, pcihpd-discuss, Alex Chiang, Matthew Wilcox, gregkh,
linux-kernel, linuxppc-dev, linux-acpi, Kristen Carlson Accardi,
linux-pci, strosake, lenb
In-Reply-To: <20071114003455.GD8509@austin.ibm.com>
On Tue, Nov 13, 2007 at 06:34:55PM -0600, Linas Vepstas wrote:
>
>
> Fix presentation of the slot number in the /sys/bus/pci/slots
> directory to match that used in the majority of other drivers.
We need a signed-off-by: to be able to apply this...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
From: Benjamin Herrenschmidt @ 2007-11-14 3:43 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071114021326.GB19378@localhost.localdomain>
On Wed, 2007-11-14 at 13:13 +1100, David Gibson wrote:
> Hrm. I *think* I'm convinced this is safe, although acking in a
> callback which doesn't say it acks is rather yucky. Essentially this
> code is trading flow readability (because just reading
> handle_level_irq will tell you something other than what it does in
> our case) for smaller code size. I'm not sure if this is a good trade
> or not.
>
> There's also one definite problem: according to the discussions I had
> with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what
> we want for edge interrupts.
>
> Apparently handle_edge_irq is only for edge interrupts on "broken"
> PICs which won't latch new interrupts while the irq is masked. UIC is
> not in this category, so handle_level_irq is actually what we want,
> even for an edge irq.
>
> Yes, I thought the naming was more than a little confusing, too.
Hrm... handle_edge_irq works for both and you have a small performance
benefit in not masking, and thus using handle_edge_irq, so I don't
totally agree here. Basically, what handle_edge_irq() does is lazy
masking. Now there -is- an issue here is that if you do lazy masking,
you need to be able to re-emit in some convenient way.
Ben.
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: 4xx uic updates
From: Benjamin Herrenschmidt @ 2007-11-14 3:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, dwg
In-Reply-To: <20071113200514.72d03792@zod.rchland.ibm.com>
On Tue, 2007-11-13 at 20:05 -0600, Josh Boyer wrote:
> On Tue, 13 Nov 2007 23:15:59 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> > These patches update 4xx uic code. The first one
> > fixes a minor issue with edge-triggered interrupts,
> > while the second one makes it use generic level and edge irq
> > handlers. I've added irq ack'ing to the unmask callback for
> > level-triggered interrupts, because to de-assert them we have
> > to do 2 things is the exact order as below:
> > 1. de-assert the external source in the ISR.
> > 2. ack the IRQ on the UIC.
> > So, ack'ing level interrupts before unmasking them makes possible
> > to use generic level irq handler and it doesn't hurt, cause
> > we can never miss a level-triggered interrupt. It always stays
> > asserted untill the external source is removed and ack'ed on UIC.
> >
> > These have been tested on Sequoia PowerPC 440EPx board.
>
> Is my mail server slow, or did patch 2 of 2 never make it out?
It never reached me neither.
Ben
^ permalink raw reply
* [PATCH] [POWERPC] pSeries: make pseries_defconfig minus PCI build again
From: Stephen Rothwell @ 2007-11-14 4:07 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/pseries/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 16e4e40..306a9d0 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -21,7 +21,7 @@ config PPC_SPLPAR
config EEH
bool "PCI Extended Error Handling (EEH)" if EMBEDDED
- depends on PPC_PSERIES
+ depends on PPC_PSERIES && PCI
default y if !EMBEDDED
config SCANLOG
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
From: Stephen Rothwell @ 2007-11-14 4:11 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1Irw8I-0000b4-5e@jdl.com>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Tue, 13 Nov 2007 07:48:50 -0600 Jon Loeliger <jdl@jdl.com> wrote:
>
> I'm assuming I can chip away at _all_ of these,
> including the ones in the drivers/ directories as well.
Knock yourself out! :-)
> I haven't a clue who will really pick all these up.
> We could arrange for Paul to grab the arch/powerpc.
> But the rest? Mr Morton perhaps?
Just keep in mind that some of these changes may affect Sparc and
Sparc64, so Dave Miller is you man for those.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Fix fs_enet module build
From: David Miller @ 2007-11-14 5:09 UTC (permalink / raw)
To: jochen; +Cc: jeff, netdev, linux-kernel, linuxppc-embedded, akpm
In-Reply-To: <4739EDA8.6020800@scram.de>
From: Jochen Friedrich <jochen@scram.de>
Date: Tue, 13 Nov 2007 19:32:08 +0100
> If fs_enet is build as module, on PPC_CPM_NEW_BINDING platforms
> mii-fec/mii-bitbang should be build as module, as well. On other
> platforms, mii-fec/mii-bitbang must be included into the main module.
> Otherwise some symbols remain undefined. Additionally, fs_enet uses
> libphy, so add a select PHYLIB.
>
> Building modules, stage 2.
> MODPOST 5 modules
> ERROR: "fs_scc_ops" [drivers/net/fs_enet/fs_enet.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
This is truly ugly and creates an unnecessarily hard to
maintain and complex driver.
Please find a way to fix this for real, so that the
PPC_CPM_NEW_BINDING ifdef is not necessary at all and
things get built modular or not naturally as we handle
things for other cases like this.
THanks.
^ permalink raw reply
* Re: I2C on mpc8248 / device tree
From: Kumar Gala @ 2007-11-14 7:17 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0711131539n228f9f21q7b2acc896499b80d@mail.gmail.com>
On Nov 13, 2007, at 5:39 PM, Alan Bennett wrote:
> I've got four devices on i2c that I need to read. Simple thermal
> and voltage monitors. I2c works fine in uboot, and now I'm trying
> to get things to work in linux.
>
> In the kernel .config I enable
> I2C
> and
> I2C_MPC
This driver isn't for the I2C on 8248. You need a cpm2 i2c driver
for that controller.
- k
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Gerhard Pircher @ 2007-11-14 9:20 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1195003029.28865.16.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Wed, 14 Nov 2007 12:17:09 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: Jon Smirl <jonsmirl@gmail.com>, grant.likely@secretlab.ca, linuxppc-dev@ozlabs.org
> Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs
>
> On Tue, 2007-11-13 at 23:21 +0100, Gerhard Pircher wrote:
> > -------- Original-Nachricht --------
> > > Datum: Tue, 13 Nov 2007 17:10:29 -0500
> > > Von: "Jon Smirl" <jonsmirl@gmail.com>
> > > An: "Grant Likely" <grant.likely@secretlab.ca>
> > > CC: "Gerhard Pircher" <gerhard_pircher@gmx.net>,
> linuxppc-dev@ozlabs.org
> > > Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs
> > >
> > > Here are the choices:
> > > http://www.macraigor.com/cpus.htm
> > Looks like the Abatron BDI-2000 is the cheapest hardware debugger that
> > supports 74xx G4 CPUs. :-(
>
> Do you have the appropriate connector for it on the motherboard as
> well ? If not, then you are out of luck...
>
> Ben.
Yes, the connector is on the CPU module.
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-14 9:39 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194997072.28865.5.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Wed, 14 Nov 2007 10:37:52 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
> Add printk's to things :-) It's a UP kernel so there should be no
> spinlocks anyway.
>
> Best is to try to get a 100% reprocase and printk your way toward the
> origin of the problem if you don't have a HW debugger. Unless you manage
> to sneak in an irq to xmon but if you are totally locked up, you
> probably can't.
Also xmon seems to lockup the machine. I was able to active it through the
magic sysrq key, but the machine died afterwards.
> Could also be something you do that your buggy northbridge doesn't like.
> For example, maybe it dislikes M bit in the hash table and you end up
> with it set due to other reasons (I know we had changes in this area).
Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
prefetch engines (I don't care about the performance loss).
I couldn't find any other code that sets the M bit, except for huge TLB
page support, but isn't that only for PPC64?
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Virtex TEMAC 1000Mb/s trouble, but 100b/s is working
From: alex_snippet @ 2007-11-14 9:45 UTC (permalink / raw)
To: linuxppc-embedded
Hi all!
I'm porting Linux for custom board based on Virtex4 FX, vanilla kernel
2.6.22.5 , Xilinx EDK 9.1 BSP,
ELDK41 - cross-compiler
target nfs-root pointed to ELDK41/ppc_4xx
Kernel command line:
Linux/PPC load: root=/dev/nfs rw console=ttyS0,9600
nfsroot=192.168.0.1:/target
ip=on
All work successfully was done, i tested all at 100Mb's connection speed,
but yesterday my customer said that with 1Gbit connection it did't work :(
end of log following:
3.341532] eth0: XTemac: Options: 0xb8f2
[ 11.855386] eth0: XTemac: We renegotiated the speed to: 1000
[ 11.923237] eth0: XTemac: speed set to 1000Mb/s
[ 13.000064] Sending DHCP requests ......, OK
[ 65.484075] IP-Config: Got DHCP answer from 0.0.0.0, my address is
192.168.0.
192
[ 65.573684] IP-Config: Complete:
[ 65.610416] device=eth0, addr=192.168.0.192, mask=255.255.255.0,
gw=192
.168.0.1,
[ 65.705572] host=192.168.0.192, domain=, nis-domain=(none),
[ 65.777872] bootserver=0.0.0.0, rootserver=192.168.0.1, rootpath=
[ 65.861982] Looking up port of RPC 100003/2 on 192.168.0.1
[ 65.929093] Looking up port of RPC 100005/1 on 192.168.0.1
[ 66.024134] VFS: Mounted root (nfs filesystem).
[ 66.079160] Freeing unused kernel memory: 104k init
[ 71.640314] nfs: server 192.168.0.1 not responding, still trying
[ 76.040311] nfs: server 192.168.0.1 not responding, still trying
Load process was friezed at this point. When connection speed is 100Mb/s
everything is ok.
Please advise me what to do, i tried to increase ppc core frequency from 100
to 300 MHz - the same problem.
When i'm using virtual machine instead of real hardware it's working on
1000Gb/s :) but isn't on real hardware.
I'm using Fedora 7 as a host.
May be there are some nfs-demon settings?
My MHS file fragment:
BEGIN hard_temac
PARAMETER INSTANCE = hard_temac_0
PARAMETER HW_VER = 3.00.b
PARAMETER C_PHY_TYPE = 1
PARAMETER C_EMAC1_PRESENT = 0
BUS_INTERFACE V4EMACDST0 = V4EMAC0
PORT GMII_TXD_0 = GMII_TXD0
PORT GMII_TX_EN_0 = GMII_TX_EN0
PORT GMII_TX_ER_0 = GMII_TX_ER0
PORT GMII_TX_CLK_0 = GMII_TX_CLK0
PORT GMII_RXD_0 = GMII_RXD0
PORT GMII_RX_DV_0 = GMII_RX_DV0
PORT GMII_RX_ER_0 = GMII_RX_ER0
PORT GMII_RX_CLK_0 = GMII_RX_CLK0
PORT MDC_0 = MDC0
PORT MDIO_0 = MDIO0
PORT GTX_CLK_0 = GTX_CLK0
PORT MII_TX_CLK_0 = MII_TX_CLK0
PORT RESET = Emac_Reset
PORT REFCLK = sys_clk_s
END
BEGIN plb_temac
PARAMETER INSTANCE = TriMode_MAC_GMII
PARAMETER HW_VER = 3.00.a
PARAMETER C_BASEADDR = 0x81200000
PARAMETER C_HIGHADDR = 0x8120ffff
PARAMETER C_MAC_FIFO_DEPTH = 64
PARAMETER C_RX_DRE_TYPE = 0
PARAMETER C_TX_DRE_TYPE = 0
PARAMETER C_DMA_TYPE = 1
PARAMETER C_PLB_CLK_PERIOD_PS = 10000
BUS_INTERFACE MSPLB = plb
BUS_INTERFACE V4EMACSRC = V4EMAC0
PORT IP2INTC_Irpt = TEMAC_Interrupt
PORT Emac_Reset = Emac_Reset
PORT PhyResetN = PhyResetN
END
--
View this message in context: http://www.nabble.com/Virtex-TEMAC-1000Mb-s-trouble%2C-but-100b-s-is-working-tf4803823.html#a13743302
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-14 10:04 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071114093939.297890@gmx.net>
On Wed, 2007-11-14 at 10:39 +0100, Gerhard Pircher wrote:
> Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
> masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
> prefetch engines (I don't care about the performance loss).
> I couldn't find any other code that sets the M bit, except for huge
> TLB
> page support, but isn't that only for PPC64?
Right, it's only 64 bits. You've double checked nothing broke the M bit
thing ? In which case, I don't know what else...
Ben.
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-14 10:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1195034697.28865.34.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Wed, 14 Nov 2007 21:04:57 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
> On Wed, 2007-11-14 at 10:39 +0100, Gerhard Pircher wrote:
> > Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
> > masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
> > prefetch engines (I don't care about the performance loss).
> > I couldn't find any other code that sets the M bit, except for huge
> > TLB
> > page support, but isn't that only for PPC64?
>
> Right, it's only 64 bits. You've double checked nothing broke the M bit
> thing ? In which case, I don't know what else...
Yes, I did. Otherwise the machine dies much earlier in the boot process.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* [PATCH v5 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-14 10:21 UTC (permalink / raw)
To: linuxppc-dev
This patch adds support for 'mpc5200-simple-platform' compatible
boards which do not need a platform specific setup. Such boards
are supported assuming the following:
- GPIO pins are configured by the firmware,
- CDM configuration (clocking) is setup correctly by firmware,
- if the 'fsl,has-wdt' property is present in one of the
gpt nodes, then it is safe to use such gpt to reset the board,
- PCI is supported if enabled in the kernel configuration
and if there is a PCI bus node defined in the device tree.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
This is a updated version of the patch 04/13 from the patchset that
adds arch/powerpc support for three MPC5200 based boards:
TQ-Components TQM5200, Schindler CM5200 and Promess Motion-PRO.
Supported boards table was made static __initdata and
sorted alphabetically.
Cheers,
Marian Balakowicz
arch/powerpc/boot/dts/lite5200.dts | 2 -
arch/powerpc/boot/dts/lite5200b.dts | 2 -
arch/powerpc/platforms/52xx/Kconfig | 22 ++++++-
arch/powerpc/platforms/52xx/Makefile | 1
arch/powerpc/platforms/52xx/mpc5200_simple.c | 84 ++++++++++++++++++++++++++
5 files changed, 107 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc5200_simple.c
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index 6731763..5902362 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200";
// revision = "1.0";
- compatible = "fsl,lite5200","generic-mpc5200";
+ compatible = "fsl,lite5200";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index b540388..b509129 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200b";
// revision = "1.0";
- compatible = "fsl,lite5200b","generic-mpc5200";
+ compatible = "fsl,lite5200b";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 2938d49..36e880b 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -19,6 +19,26 @@ config PPC_MPC5200_BUGFIX
It is safe to say 'Y' here
+config PPC_MPC5200_SIMPLE
+ bool "Generic support for simple MPC5200 based boards"
+ depends on PPC_MULTIPLATFORM && PPC32
+ select PPC_MPC5200
+ default n
+ help
+ This option enables support for a simple MPC52xx based boards which
+ do not need a custom platform specific setup. Such boards are
+ supported assuming the following:
+
+ - GPIO pins are configured by the firmware,
+ - CDM configuration (clocking) is setup correctly by firmware,
+ - if the 'fsl,has-wdt' property is present in one of the
+ gpt nodes, then it is safe to use such gpt to reset the board,
+ - PCI is supported if enabled in the kernel configuration
+ and if there is a PCI bus node defined in the device tree.
+
+ Boards that are compatible with this generic platform support
+ are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200'.
+
config PPC_EFIKA
bool "bPlan Efika 5k2. MPC5200B based computer"
depends on PPC_MULTIPLATFORM && PPC32
@@ -34,5 +54,3 @@ config PPC_LITE5200
select WANT_DEVICE_TREE
select PPC_MPC5200
default n
-
-
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index 307dbc1..fe1b81b 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -6,6 +6,7 @@ obj-y += mpc52xx_pic.o mpc52xx_common.o
obj-$(CONFIG_PCI) += mpc52xx_pci.o
endif
+obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
obj-$(CONFIG_PPC_EFIKA) += efika.o
obj-$(CONFIG_PPC_LITE5200) += lite5200.o
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
new file mode 100644
index 0000000..049c03d
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -0,0 +1,84 @@
+/*
+ * Support for 'mpc5200-simple-platform' compatible boards.
+ *
+ * Written by Marian Balakowicz <m8@semihalf.com>
+ * Copyright (C) 2007 Semihalf
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Description:
+ * This code implements support for a simple MPC52xx based boards which
+ * do not need a custom platform specific setup. Such boards are
+ * supported assuming the following:
+ *
+ * - GPIO pins are configured by the firmware,
+ * - CDM configuration (clocking) is setup correctly by firmware,
+ * - if the 'fsl,has-wdt' property is present in one of the
+ * gpt nodes, then it is safe to use such gpt to reset the board,
+ * - PCI is supported if enabled in the kernel configuration
+ * and if there is a PCI bus node defined in the device tree.
+ *
+ * Boards that are compatible with this generic platform support
+ * are listed in a 'board' table.
+ */
+
+#undef DEBUG
+#include <asm/time.h>
+#include <asm/machdep.h>
+#include <asm/mpc52xx.h>
+
+/*
+ * Setup the architecture
+ */
+static void __init mpc5200_simple_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("mpc5200_simple_setup_arch()", 0);
+
+ /* Some mpc5200 & mpc5200b related configuration */
+ mpc5200_setup_xlb_arbiter();
+
+ /* Map wdt for mpc52xx_restart() */
+ mpc52xx_map_wdt();
+
+ mpc52xx_setup_pci();
+}
+
+/* list of the supported boards */
+static const char *board[] __initdata = {
+ "promess,motionpro",
+ "schindler,cm5200",
+ "tqc,tqm5200",
+ NULL
+};
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init mpc5200_simple_probe(void)
+{
+ unsigned long node = of_get_flat_dt_root();
+ int i = 0;
+
+ while (board[i]) {
+ if (of_flat_dt_is_compatible(node, board[i]))
+ break;
+ i++;
+ }
+
+ return (board[i] != NULL);
+}
+
+define_machine(mpc5200_simple_platform) {
+ .name = "mpc5200-simple-platform",
+ .probe = mpc5200_simple_probe,
+ .setup_arch = mpc5200_simple_setup_arch,
+ .init = mpc52xx_declare_of_platform_devices,
+ .init_IRQ = mpc52xx_init_irq,
+ .get_irq = mpc52xx_get_irq,
+ .restart = mpc52xx_restart,
+ .calibrate_decr = generic_calibrate_decr,
+};
^ permalink raw reply related
* [PATCH] 2.6.24-rc2-mm1 powerpc (iseries)- build failure - mm/stab.c
From: Kamalesh Babulal @ 2007-11-14 10:54 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev, anton, paulus, linux-kernel
Hi Andrew,
The kernel builds fails with following error, with randconfig
CC arch/powerpc/mm/stab.o
arch/powerpc/mm/stab.c: In function ‘stab_initialize’:
arch/powerpc/mm/stab.c:282: error: implicit declaration of function ‘HvCall1’
arch/powerpc/mm/stab.c:282: error: ‘HvCallBaseSetASR’ undeclared (first use in this function)
arch/powerpc/mm/stab.c:282: error: (Each undeclared identifier is reported only once
arch/powerpc/mm/stab.c:282: error: for each function it appears in.)
make[1]: *** [arch/powerpc/mm/stab.o] Error 1
make: *** [arch/powerpc/mm] Error 2
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
--- linux-2.6.24-rc2/arch/powerpc/mm/stab.c 2007-11-14 05:22:55.000000000 -0500
+++ linux-2.6.24-rc2/arch/powerpc/mm/~stab.c 2007-11-14 05:23:18.000000000 -0500
@@ -21,6 +21,10 @@
#include <asm/abs_addr.h>
#include <asm/firmware.h>
+#ifdef CONFIG_PPC_ISERIES
+#include <asm/iseries/hv_call.h>
+#endif /* CONFIG_PPC_ISERIES */
+
struct stab_entry {
unsigned long esid_data;
unsigned long vsid_data;
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: printk/console_init - baud rate setting
From: Segher Boessenkool @ 2007-11-14 11:30 UTC (permalink / raw)
To: Siva Prasad; +Cc: Geert Uytterhoeven, linuxppc-dev, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D7F73D5F@corpexc01.corp.networkrobots.com>
> I am getting garbage on the screen. So, I presume this must be some
> sort
> of baud rate issue. Can some one help me out understand how this baud
> is
> set for serial drivers? I want to run at 115200.
console=ttyS0,115200
See Documentation/kernel-parameters.txt; depending on exactly what
early console you are using, that one might have it hardcoded. Have
a look around.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Fix fs_enet module build
From: Jochen Friedrich @ 2007-11-14 11:59 UTC (permalink / raw)
To: David Miller; +Cc: jeff, netdev, linux-kernel, linuxppc-embedded, akpm
In-Reply-To: <20071113.210926.97725854.davem@davemloft.net>
Hi David,
> This is truly ugly and creates an unnecessarily hard to
> maintain and complex driver.
>
> Please find a way to fix this for real, so that the
> PPC_CPM_NEW_BINDING ifdef is not necessary at all and
> things get built modular or not naturally as we handle
> things for other cases like this.
I know it's ugly, however, module building is completely
broken right now and I just want to provide a quick and
ugly fix until both that ppc->powerpc transition and the
new binding transition are over. Noone wants to touch the
old stuff any more as it's a pita and it's already scheduled
for removal in a couple of months.
Thanks,
Jochen
^ permalink raw reply
* Re: Virtex TEMAC 1000Mb/s trouble, but 100b/s is working
From: schardt @ 2007-11-14 12:03 UTC (permalink / raw)
To: alex_snippet; +Cc: linuxppc-embedded
In-Reply-To: <13743302.post@talk.nabble.com>
I have the same problem with the FX12 Minimodul, runing 2.6.23 kernel...
running the nfs-kernel-server on the host, i could mount the
nfs-directory from the target with -o nolock,tcp
running the nfs-user-kernel failed
with both server i could not mount root-fs in the boot process
i gave up at this moment and take the root-fs to flash memory
regards
georg
alex_snippet wrote:
> Hi all!
>
> I'm porting Linux for custom board based on Virtex4 FX, vanilla kernel
> 2.6.22.5 , Xilinx EDK 9.1 BSP,
> ELDK41 - cross-compiler
> target nfs-root pointed to ELDK41/ppc_4xx
>
> Kernel command line:
> Linux/PPC load: root=/dev/nfs rw console=ttyS0,9600
> nfsroot=192.168.0.1:/target
> ip=on
>
> All work successfully was done, i tested all at 100Mb's connection speed,
> but yesterday my customer said that with 1Gbit connection it did't work :(
> end of log following:
>
> 3.341532] eth0: XTemac: Options: 0xb8f2
> [ 11.855386] eth0: XTemac: We renegotiated the speed to: 1000
> [ 11.923237] eth0: XTemac: speed set to 1000Mb/s
> [ 13.000064] Sending DHCP requests ......, OK
> [ 65.484075] IP-Config: Got DHCP answer from 0.0.0.0, my address is
> 192.168.0.
> 192
> [ 65.573684] IP-Config: Complete:
> [ 65.610416] device=eth0, addr=192.168.0.192, mask=255.255.255.0,
> gw=192
> .168.0.1,
> [ 65.705572] host=192.168.0.192, domain=, nis-domain=(none),
> [ 65.777872] bootserver=0.0.0.0, rootserver=192.168.0.1, rootpath=
> [ 65.861982] Looking up port of RPC 100003/2 on 192.168.0.1
> [ 65.929093] Looking up port of RPC 100005/1 on 192.168.0.1
> [ 66.024134] VFS: Mounted root (nfs filesystem).
> [ 66.079160] Freeing unused kernel memory: 104k init
> [ 71.640314] nfs: server 192.168.0.1 not responding, still trying
> [ 76.040311] nfs: server 192.168.0.1 not responding, still trying
>
> Load process was friezed at this point. When connection speed is 100Mb/s
> everything is ok.
>
> Please advise me what to do, i tried to increase ppc core frequency from 100
> to 300 MHz - the same problem.
> When i'm using virtual machine instead of real hardware it's working on
> 1000Gb/s :) but isn't on real hardware.
> I'm using Fedora 7 as a host.
> May be there are some nfs-demon settings?
>
> My MHS file fragment:
>
> BEGIN hard_temac
> PARAMETER INSTANCE = hard_temac_0
> PARAMETER HW_VER = 3.00.b
> PARAMETER C_PHY_TYPE = 1
> PARAMETER C_EMAC1_PRESENT = 0
> BUS_INTERFACE V4EMACDST0 = V4EMAC0
> PORT GMII_TXD_0 = GMII_TXD0
> PORT GMII_TX_EN_0 = GMII_TX_EN0
> PORT GMII_TX_ER_0 = GMII_TX_ER0
> PORT GMII_TX_CLK_0 = GMII_TX_CLK0
> PORT GMII_RXD_0 = GMII_RXD0
> PORT GMII_RX_DV_0 = GMII_RX_DV0
> PORT GMII_RX_ER_0 = GMII_RX_ER0
> PORT GMII_RX_CLK_0 = GMII_RX_CLK0
> PORT MDC_0 = MDC0
> PORT MDIO_0 = MDIO0
> PORT GTX_CLK_0 = GTX_CLK0
> PORT MII_TX_CLK_0 = MII_TX_CLK0
> PORT RESET = Emac_Reset
> PORT REFCLK = sys_clk_s
> END
>
> BEGIN plb_temac
> PARAMETER INSTANCE = TriMode_MAC_GMII
> PARAMETER HW_VER = 3.00.a
> PARAMETER C_BASEADDR = 0x81200000
> PARAMETER C_HIGHADDR = 0x8120ffff
> PARAMETER C_MAC_FIFO_DEPTH = 64
> PARAMETER C_RX_DRE_TYPE = 0
> PARAMETER C_TX_DRE_TYPE = 0
> PARAMETER C_DMA_TYPE = 1
> PARAMETER C_PLB_CLK_PERIOD_PS = 10000
> BUS_INTERFACE MSPLB = plb
> BUS_INTERFACE V4EMACSRC = V4EMAC0
> PORT IP2INTC_Irpt = TEMAC_Interrupt
> PORT Emac_Reset = Emac_Reset
> PORT PhyResetN = PhyResetN
> END
>
>
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
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
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
From: Valentine Barshak @ 2007-11-13 20:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dwg
In-Reply-To: <20071113201559.GA26172@ru.mvista.com>
This patch makes PowerPC 4xx UIC use generic edge and level irq handlers
instead of a custom handle_uic_irq() function. Acking a level irq on UIC
has no effect if the interrupt is still asserted by the device, even if
the interrupt is already masked. So, to really de-assert the interrupt
we need to de-assert the external source first *and* ack it on UIC then.
The handle_level_irq() function masks and ack's the interrupt with mask_ack
callback prior to calling the actual ISR and unmasks it at the end.
So, to use it with UIC level interrupts we need to ack in the unmask
callback instead, after the ISR has de-asserted the external interrupt source.
Even if we ack the interrupt that we didn't handle (unmask/ack it at
the end of the handler, while next irq is already pending) it will not
de-assert the irq, untill we de-assert its exteral source.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/sysdev/uic.c | 89 ++++++++++++----------------------------------
1 files changed, 24 insertions(+), 65 deletions(-)
--- linux-2.6/arch/powerpc/sysdev/uic.c 2007-11-13 22:28:01.000000000 +0300
+++ linux-2.6.o/arch/powerpc/sysdev/uic.c 2007-11-13 22:27:20.000000000 +0300
@@ -60,14 +60,19 @@ struct uic {
static void uic_unmask_irq(unsigned int virq)
{
+ struct irq_desc *desc = get_irq_desc(virq);
struct uic *uic = get_irq_chip_data(virq);
unsigned int src = uic_irq_to_hw(virq);
unsigned long flags;
- u32 er;
+ u32 er, sr;
+ sr = 1 << (31-src);
spin_lock_irqsave(&uic->lock, flags);
+ /* ack level interrupts here */
+ if (desc->status & IRQ_LEVEL)
+ mtdcr(uic->dcrbase + UIC_SR, sr);
er = mfdcr(uic->dcrbase + UIC_ER);
- er |= 1 << (31 - src);
+ er |= sr;
mtdcr(uic->dcrbase + UIC_ER, er);
spin_unlock_irqrestore(&uic->lock, flags);
}
@@ -99,6 +104,7 @@ static void uic_ack_irq(unsigned int vir
static void uic_mask_ack_irq(unsigned int virq)
{
+ struct irq_desc *desc = get_irq_desc(virq);
struct uic *uic = get_irq_chip_data(virq);
unsigned int src = uic_irq_to_hw(virq);
unsigned long flags;
@@ -109,7 +115,16 @@ static void uic_mask_ack_irq(unsigned in
er = mfdcr(uic->dcrbase + UIC_ER);
er &= ~sr;
mtdcr(uic->dcrbase + UIC_ER, er);
- mtdcr(uic->dcrbase + UIC_SR, sr);
+ /* on the uic, acking (i.e. clearing the sr bit)
+ * a level irq will have no effect if the interrupt
+ * is still asserted by the device, even if
+ * the interrupt is already masked. therefore
+ * we only ack the egde interrupts here, while
+ * level interrupts are ack'ed after the actual
+ * isr call in the uic_unmask_irq()
+ */
+ if (!(desc->status & IRQ_LEVEL))
+ mtdcr(uic->dcrbase + UIC_SR, sr);
spin_unlock_irqrestore(&uic->lock, flags);
}
@@ -156,8 +171,11 @@ static int uic_set_irq_type(unsigned int
desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
- if (!trigger)
+ if (!trigger) {
desc->status |= IRQ_LEVEL;
+ set_irq_handler(virq, handle_level_irq);
+ } else
+ set_irq_handler(virq, handle_edge_irq);
spin_unlock_irqrestore(&uic->lock, flags);
@@ -173,73 +191,14 @@ static struct irq_chip uic_irq_chip = {
.set_type = uic_set_irq_type,
};
-/**
- * handle_uic_irq - irq flow handler for UIC
- * @irq: the interrupt number
- * @desc: the interrupt description structure for this irq
- *
- * This is modified version of the generic handle_level_irq() suitable
- * for the UIC. On the UIC, acking (i.e. clearing the SR bit) a level
- * irq will have no effect if the interrupt is still asserted by the
- * device, even if the interrupt is already masked. Therefore, unlike
- * the standard handle_level_irq(), we must ack the interrupt *after*
- * invoking the ISR (which should have de-asserted the interrupt in
- * the external source). For edge interrupts we ack at the beginning
- * instead of the end, to keep the window in which we can miss an
- * interrupt as small as possible.
- */
-void fastcall handle_uic_irq(unsigned int irq, struct irq_desc *desc)
-{
- unsigned int cpu = smp_processor_id();
- struct irqaction *action;
- irqreturn_t action_ret;
-
- spin_lock(&desc->lock);
- if (desc->status & IRQ_LEVEL)
- desc->chip->mask(irq);
- else
- desc->chip->mask_ack(irq);
-
- if (unlikely(desc->status & IRQ_INPROGRESS))
- goto out_unlock;
- desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
- kstat_cpu(cpu).irqs[irq]++;
-
- /*
- * If its disabled or no action available
- * keep it masked and get out of here
- */
- action = desc->action;
- if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
- desc->status |= IRQ_PENDING;
- goto out_unlock;
- }
-
- desc->status |= IRQ_INPROGRESS;
- desc->status &= ~IRQ_PENDING;
- spin_unlock(&desc->lock);
-
- action_ret = handle_IRQ_event(irq, action);
-
- spin_lock(&desc->lock);
- desc->status &= ~IRQ_INPROGRESS;
- if (desc->status & IRQ_LEVEL)
- desc->chip->ack(irq);
- if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
- desc->chip->unmask(irq);
-out_unlock:
- spin_unlock(&desc->lock);
-}
-
static int uic_host_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
struct uic *uic = h->host_data;
set_irq_chip_data(virq, uic);
- /* Despite the name, handle_level_irq() works for both level
- * and edge irqs on UIC. FIXME: check this is correct */
- set_irq_chip_and_handler(virq, &uic_irq_chip, handle_uic_irq);
+ /* appropriate irq handler is set by set_irq_type() */
+ set_irq_chip(virq, &uic_irq_chip);
/* Set default irq type */
set_irq_type(virq, IRQ_TYPE_NONE);
^ permalink raw reply
* Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
From: Valentine Barshak @ 2007-11-14 12:31 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1195011796.28865.28.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2007-11-14 at 13:13 +1100, David Gibson wrote:
>> Hrm. I *think* I'm convinced this is safe, although acking in a
>> callback which doesn't say it acks is rather yucky. Essentially this
>> code is trading flow readability (because just reading
>> handle_level_irq will tell you something other than what it does in
>> our case) for smaller code size. I'm not sure if this is a good trade
>> or not.
>>
It's not just code size. Actually, I was having problems with Ingo's
real-time patch, that works on all platforms that use generic hard irq
handlers and doesn't work just on 4xx since we use a custom one here.
And I thought that using generic handlers would be easier to maintain.
I agree that ack'ing in a callback which doesn't say it ack's looks odd,
but ack'ing level-triggered interrupts is quirky on UIC itself. So, I
just thought that adding a couple of quirks to mask_ack and unmask
callbacks was not that bad.
>> There's also one definite problem: according to the discussions I had
>> with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what
>> we want for edge interrupts.
>>
>> Apparently handle_edge_irq is only for edge interrupts on "broken"
>> PICs which won't latch new interrupts while the irq is masked. UIC is
>> not in this category, so handle_level_irq is actually what we want,
>> even for an edge irq.
>>
>> Yes, I thought the naming was more than a little confusing, too.
>
> Hrm... handle_edge_irq works for both and you have a small performance
> benefit in not masking, and thus using handle_edge_irq, so I don't
> totally agree here. Basically, what handle_edge_irq() does is lazy
> masking. Now there -is- an issue here is that if you do lazy masking,
> you need to be able to re-emit in some convenient way.
With the ack quirks added we can use handle_level_irq for edge-triggered
interrupts. I'll test and resubmit the patch.
>
> Ben.
>
>
Thanks,
Valentine.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox