* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Gabriel Paubert @ 2008-05-05 11:55 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080503.005510.88048425.davem@davemloft.net>
On Sat, May 03, 2008 at 12:55:10AM -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Sat, 03 May 2008 17:50:17 +1000
>
> > Best would be if we could get those runtime bits linked in the module
> > itself, but I don't know enough about our toolchain to know if that's
> > easy (I suppose everything is always possible :-)
>
> The only downside is that you'd have N copies of these
> routines, one for every module that emmited the libcalls.
It's probably not as bad as it seems:
1) it will be smaller than having the saved/restore inlined in every
function prologue and epilogue
2) as soon as you have ten functions or so that call them, it might
even be smaller than the size of all the trampolines. Unless I'm
mistaken, you would need at least two trampolines for every entry
point that you use in the save/restore routines, which have an entry
point at every instruction boundary or so. That's about 32 bytes
(8 instructions) per set of save/restore functions IIRC.
The ultimate solution might be lo link all these routines at a fixed
large absolute address (between -32M and -1UL) so that you can
call them with a bla instruction. But this requires memory layout
changes which would be quite painful.
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH 1/4 V3] MSI support on 83xx/85xx/86xx board
From: Michael Ellerman @ 2008-05-05 11:24 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev
In-Reply-To: <1209973634-1699-1-git-send-email-Jason.jin@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 4485 bytes --]
On Mon, 2008-05-05 at 15:47 +0800, Jason Jin wrote:
> This MSI driver can be used on 83xx/85xx/86xx board.
> In this driver, virtual interrupt host and chip were
> setup. There are 256 MSI interrupts in this host, Every 32
> MSI interrupts cascaded to one IPIC/MPIC interrupt.
> The chip was treated as edge sensitive and some necessary
> functions were setup for this chip.
>
> Before using the MSI interrupt, PCI/PCIE device need to
> ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
> bitmap show which MSI interrupt was used, reserve bit in
> the bitmap can be used to force the device use some designate
> MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
> for testing the all the MSI interrupts. The msi-available-ranges
> property in the dts file was used for this purpose.
>
> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Hi Jason,
Just a couple of comments below:
> diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
> new file mode 100644
> index 0000000..c53f716
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_msi.c
> @@ -0,0 +1,442 @@
> +/*
> + * Copyright (C) 2007-2008 Freescale Semiconductor, Inc. All rights reserved.
> + *
> + * Author: Tony Li <tony.li@freescale.com>
> + * Jason Jin <Jason.jin@freescale.com>
> + *
> + * 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; version 2 of the
> + * License.
> + *
> + */
> +#include <linux/irq.h>
> +#include <linux/bootmem.h>
> +#include <linux/bitmap.h>
> +#include <linux/msi.h>
> +#include <linux/pci.h>
> +#include <linux/of_platform.h>
> +#include <sysdev/fsl_soc.h>
> +#include <asm/prom.h>
> +#include <asm/hw_irq.h>
> +#include <asm/ppc-pci.h>
> +#include "fsl_msi.h"
> +
> +struct fsl_msi_feature {
> + u32 fsl_pic_ip;
> + u32 msiir_offset;
> +};
> +
> +/* A bit ugly, can we get this from the pci_dev somehow? */
This comment is old (from my code) and should go.
> +static struct fsl_msi *fsl_msi;
> +
> +static inline u32 fsl_msi_read(u32 __iomem *base, unsigned int reg)
> +{
> + return in_be32(base + (reg >> 2));
> +}
> +
> +static inline void fsl_msi_write(u32 __iomem *base,
> + unsigned int reg, u32 value)
> +{
> + out_be32(base + (reg >> 2), value);
> +}
> +
> +/*
> + * We do not need this actually. The MSIR register has been read once
> + * in the cascade interrupt. So, this MSI interrupt has been acked
> +*/
> +static void fsl_msi_end_irq(unsigned int virq)
> +{
> +}
> +
> +static struct irq_chip fsl_msi_chip = {
> + .mask = mask_msi_irq,
> + .unmask = unmask_msi_irq,
> + .ack = fsl_msi_end_irq,
> + .typename = " FSL-MSI ",
> +};
> +
> +static int fsl_msi_host_match(struct irq_host *h, struct device_node *node)
> +{
> + /* Exact match, unless node is NULL */
> + return h->of_node == NULL || h->of_node == node;
> +}
Are you sure you want this as your match routine? It looks wrong to me.
You won't ever create a fsl_msi in your probe routine unless you have a
device node, so AFAICT the of_node == NULL is only ever going to match
some _other_ irqhost.
> diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
> new file mode 100644
> index 0000000..0449c96
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_msi.h
> @@ -0,0 +1,31 @@
> +#ifndef _POWERPC_SYSDEV_FSL_MSI_H
> +#define _POWERPC_SYSDEV_FSL_MSI_H
This should have a copyright header.
> +#define NR_MSI_REG 8
> +#define IRQS_PER_MSI_REG 32
> +#define NR_MSI_IRQS (NR_MSI_REG * IRQS_PER_MSI_REG)
> +
> +#define FSL_PIC_IP_MASK 0x0000000F
> +#define FSL_PIC_IP_MPIC 0x00000001
> +#define FSL_PIC_IP_IPIC 0x00000002
> +
> +struct fsl_msi {
> + /* Device node of the MSI interrupt*/
> + struct device_node *of_node;
> +
> + struct irq_host *irqhost;
> +
> + unsigned long cascade_irq;
> +
> + u32 msi_addr_lo;
> + u32 msi_addr_hi;
> + void __iomem *msi_regs;
> + u32 feature;
> +
> + unsigned long *fsl_msi_bitmap;
> + spinlock_t bitmap_lock;
> + const char *name;
I don't see where this is used?
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
* Re: on the topic of of_device resources...
From: Benjamin Herrenschmidt @ 2008-05-05 8:55 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080505.014405.179523103.davem@davemloft.net>
On Mon, 2008-05-05 at 01:44 -0700, David Miller wrote:
>
> My plan on the sparc side is to remove the SBUS device type and bus
> entirely, as well as the EBUS layer I have. All of it can use
> of_device nodes on of_platform_bus. Even the DMA stuff just falls out
> of everything transparently because even that's all done via
> dev_archdata.
>
> If you look at the SBUS layer, it's simply replicating OF device
> node objects for things that sit underneath SBUS bus nodes. And
> it's like this because 32-bit sparc doesn't do the DMA stuff
> transparently like 64-bit sparc does.
>
> The of_platform_bus probing layer is extremely clean and I like
> how simple it is to write drivers using it. The drivers look
> like normal PCI device drivers, both in terms of matching
> and in terms of resource/irq fetching.
>
> I even use this for the core timeofday clock probing on sparc64.
Well, I agree it's nice and sleek for bus types you have complete
control on. The problem is when you start sharing with other
architecture :-) (well, other than powerpc & sparc !).
Which is why I might just stick to macio_device the way it is since
that's a totally local bus type, despite moving toward the different
approach I exposed for other things.
I think we need to continue supporting both approaches in the long run,
but that also means that low level parsers should as much as possible
remain based stictly on device node.
Now regarding using some kind of device for the timeofday clock probing,
well that's a different issue :-) We do need to get rid of our ppc_md.
stuff for that and move toward the new RTC infrastructure, which means
that our TODs will be proved like other devices.
Now, how so will depend on what TOD we have... i2c TODs (very common in
embedded) already have the necessary bits to be probed via the OF/i2c
bindings, creating i2c_device objects. Platform custom things like
PowerMac CUDA or PMU could be of_platform_devices. Etc...
Cheers,
Ben.
^ permalink raw reply
* RE: SKB corruption on heavy traffic
From: Franca, Jose (NSN - PT/Portugal - MiniMD) @ 2008-05-05 8:54 UTC (permalink / raw)
To: matvejchikov, Myron.Dixon; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <8496f91a0805030707q136a7d5cv6e9472997c041cff@mail.gmail.com>
Hi!
Thanks for your contribution! We will try it right away! :))
As for patches, we also installed some patches provided by freescale =
and nothing so far... Still the same problems.
I will post the results as soon as I can...
Thanks U ALL!
Filipe.
-----Original Message-----
From: ext Matvejchikov Ilya [mailto:matvejchikov@gmail.com]=20
Sent: s=E1bado, 3 de Maio de 2008 15:08
To: Myron.Dixon@l-3com.com
Cc: Franca, Jose (NSN - PT/Portugal - MiniMD); linuxppc-dev@ozlabs.org; =
linuxppc-embedded@ozlabs.org
Subject: Re: SKB corruption on heavy traffic
Hi all!
The same problem! I've tried 2.4.xx and 2.6.xx kernels. Nothing changed!
BUT. After many days of fucking with fs_enet driver I've found a
stable (as I see) solution. The bugs I've had:
- kernel oopses
- SKB data corruption
- BDs status corruption
- SKB ring full message
- too many RX errors
- may be something else :)
For now I have a 2.4.35 fs_enet driver that works on heavy load
24/7... I don't know what happens with my 8260 board, but with this
code it be very stable. I supposed that there are some errors in 8260
CPM core, but errata don't know about it :)
I've append an attachment with my 2.4.35 kernel patch. Sorry for a big
file and not for only fs_enet file. Moreover I've used CPM111 errata
microcode and NAPI in fs_enet driver.
If you have any questions I'm glad to hear it.
2008/5/2 <Myron.Dixon@l-3com.com>:
> We have experience a very similar problem using a 2.4.18 kernel on an =
8260 ppc processor.
> We have a telecomunication product that for some time only used the =
fec for TCP/IP ethernet
> traffic only and worked just fine.
>
> After we upgraded our product to implement TDM data over IP we =
started to notice an occasional
> kernel oops. We began to evaluate all of our products and determined =
that only some of the units
> exhibted this behaviour at various rates of occurrence. Further =
evaluation revealed that the pointers
> located in dpram pointing to the fec's buffer descriptors were some =
how getting corrupted.
> Note that the 8260 has 4 internal scc/fccs and we use all four for =
various aspects of our application
> and each shares dpram for pointers to buffer descriptors that reside =
in sdram. However, only the
> fec that is used for IP experiences this buffer descriptor corruption =
and, then, apparently, only under
> heavy traffic load. We spent about six months evaluating this =
problem including contacting freescale,
> but never found a solution. We finally, decided to use an external =
ethernet chip on a daughter card
> for our IP channel.
>
> It is, however, our belief that our problem relates to a possible bug =
in the 8260 CPM, but have yet to
> absolutely prove this.
>
> If we are experiencing the same problem (and potentially others) and =
there is a solution we would be
> very interested, as, we are not happy about the daughter card =
solution.
>
>
> Myron L. Dixon
> Sr. Software Engineer
> L-3 Communications, GNS
> 1519 Grundy's Lane
> Bristol, PA 19007
> Phone: 215 957 3739
> Fax: 215 957 3790
> email: Myron.Dixon@L-3Com.com
>
> -----Original Message-----
> From: linuxppc-dev-bounces+myron.dixon=3Dl-3com.com@ozlabs.org =
[mailto:linuxppc-dev-bounces+myron.dixon=3Dl-3com.com@ozlabs.org] On =
Behalf Of Franca, Jose (NSN - PT/Portugal - MiniMD)
> Sent: Wednesday, April 30, 2008 5:07 AM
> To: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: FW: SKB corruption on heavy traffic
>
> From our latest debugs we found that the problem occurs mainly on =
skbuff code. After some variable time kfree or kalloc result in kernel =
oops.
>
> -----Original Message-----
> From: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Sent: quarta-feira, 30 de Abril de 2008 9:44
> To: 'ext Scott Wood'
> Cc:
> Subject: RE: SKB corruption on heavy traffic
>
> Hello!
>
> Thank you for replying!
> It't quite dificult to say if the problem exists without our =
changes, since the all software is dependent on this changes so to work =
with the hardware. I can't answer to that right now on that, but I =
forgot to add one thing: we have ring buffer full problems on our =
fcc_enet driver from time to time. So, I think the problem could be on =
linux configurations (related to hw) because there is a lot of posts on =
the web related to problems similar to this (none of them has really =
solved the bottom problem).
>
> Regards,
> Filipe
>
> -----Original Message-----
> From: ext Scott Wood [mailto:scottwood@freescale.com]
> Sent: ter=E7a-feira, 29 de Abril de 2008 20:15
> To: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: SKB corruption on heavy traffic
>
> On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - =
PT/Portugal - MiniMD) wrote:
> > We are developing a MPC8247 based telecom board (512MB), =
using linux
> > 2.4 with some proprietary changes on IP stack and we are facing =
some
> > problems when we have heavy traffic on our Ethernet interfaces...
>
> Do you see these problems without the proprietary changes, and with a =
current kernel?
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: on the topic of of_device resources...
From: David Miller @ 2008-05-05 8:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1209975971.21644.58.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon, 05 May 2008 18:26:11 +1000
> Well, we aren't totally clear as to whether we'll use of_device much or
> not in the long term. For bus types that already have their own
> descendant of struct device (such as PCI, but also i2c, USB, etc...) it
> makes little sense to create a "special" version with OF device...
>
> That leaves platform devices, and there, experience has shown that it's
> not very practical neither when a driver is shared between powerpc and
> some other non-OF arch.
>
> So we are trying to move toward a slightly different approach: Any
> device can optionally be linked to a device_node (via dev_archdata), and
> we provide "constructors" to build the various kind of struct device
> descendants based on the device nodes.
I see, thanks for the info.
> This is in no way something done though. As you may have noticed,
> macio_device is still around, though on the other hand, we have code to
> build the PCI tree from the ground up straight off the OF nodes (that
> you may want to use too at one point ...) though it's not using the
> "constructor" approach. Some work hsa been done in the i2c layer to
> create i2c devices based on device nodes, and there are other areas like
> that.
I already build the PCI device tree on sparc64 strictly using
the OF device tree. :-)
My plan on the sparc side is to remove the SBUS device type and bus
entirely, as well as the EBUS layer I have. All of it can use
of_device nodes on of_platform_bus. Even the DMA stuff just falls out
of everything transparently because even that's all done via
dev_archdata.
If you look at the SBUS layer, it's simply replicating OF device
node objects for things that sit underneath SBUS bus nodes. And
it's like this because 32-bit sparc doesn't do the DMA stuff
transparently like 64-bit sparc does.
The of_platform_bus probing layer is extremely clean and I like
how simple it is to write drivers using it. The drivers look
like normal PCI device drivers, both in terms of matching
and in terms of resource/irq fetching.
I even use this for the core timeofday clock probing on sparc64.
^ permalink raw reply
* Re: [PATCH]: PPC_OF protect USB driver...
From: Benjamin Herrenschmidt @ 2008-05-05 8:26 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080505.005715.215572318.davem@davemloft.net>
On Mon, 2008-05-05 at 00:57 -0700, David Miller wrote:
> This uses APIs that are not generic, or at least not part of
> what Sparc provides yet.
>
> So just PPC_OF this for now just like the EHCI_OF driver.
>
> This fixes allmodconfig build errors on sparc.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 33b467a..1ef6df3 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -129,7 +129,7 @@ config USB_ISP1760_PCI
>
> config USB_ISP1760_OF
> bool "Support for the OF platform bus"
> - depends on USB_ISP1760_HCD && OF
> + depends on USB_ISP1760_HCD && PPC_OF
> ---help---
> Enables support for the device present on the PowerPC
> OpenFirmware platform bus.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: on the topic of of_device resources...
From: Benjamin Herrenschmidt @ 2008-05-05 8:26 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080505.005958.186160264.davem@davemloft.net>
On Mon, 2008-05-05 at 00:59 -0700, David Miller wrote:
> Since it came to my attention due to the build error fix
> I just had to fix, I figured I'd mention some things.
>
> Right now, powerpc and sparc differ in how they resolve
> interrupts and resources.
>
> Powerpc uses an on-demand model, whereas Sparc pre-resolves
> everything at bootup when parsing the OF tree.
We used to do that but moved away from that model for various reasons.
> Unfortunately they operate on differing objects too, otherwise I could
> provide routines to match the interfaces that powerpc OF drivers want
> :-/
Yeah, we have more/less "generic" parsers that operate on raw device
nodes. I prefer that because we don't necessarily have of_devices in all
cases (or rather, there's a whole lot of cases where we want to resolve
things without having an of_device).
> Powerpc drivers want device_node objects, whereas sparc roots all
> driver usable objects under of_platform_bus using of_device objects
> (which point to the device_node if the driver needs that).
You should easily be able to use device_node based parsers to fill up
your of_platform_bus objects no ?
> Inside of the of_device is where we hang the fully resolved resources
> and interrupts.
>
> I'd like to see consolidation in this area, and in return I'll be
> compiling all of your PPC_OF devices in my allmodconfig builds on
> sparc :-)
Heh :-)
Well, we aren't totally clear as to whether we'll use of_device much or
not in the long term. For bus types that already have their own
descendant of struct device (such as PCI, but also i2c, USB, etc...) it
makes little sense to create a "special" version with OF device...
That leaves platform devices, and there, experience has shown that it's
not very practical neither when a driver is shared between powerpc and
some other non-OF arch.
So we are trying to move toward a slightly different approach: Any
device can optionally be linked to a device_node (via dev_archdata), and
we provide "constructors" to build the various kind of struct device
descendants based on the device nodes.
This is in no way something done though. As you may have noticed,
macio_device is still around, though on the other hand, we have code to
build the PCI tree from the ground up straight off the OF nodes (that
you may want to use too at one point ...) though it's not using the
"constructor" approach. Some work hsa been done in the i2c layer to
create i2c devices based on device nodes, and there are other areas like
that.
Note that I haven't done much in that area myself other than
implementing some of the parsers a while ago, this is mostly driven by
others on the list, look around embedded folks and freescale :-)
It would be nice to find a nice generic way to "register" constructors
for devices based on OF nodes, and have them called automagically,
though there are a few pitfalls that may look like details at first but
can be nasty to do that properly. The main one is that the rules to
create a device can depend either on the bus it sits on (ie pci_dev)
rather than properties within the device node itself, or on the contrary
within the device node itself (platform devices typically). We might
need something "special" for a second-pass lookup for platform devices.
In addition, keeping track of parents would be nice to lay things out
properly in sysfs.
Cheers,
Ben.
^ permalink raw reply
* MPC52xx and SPI (native one, NOT psc)
From: Fabrizio Garetto @ 2008-05-05 8:00 UTC (permalink / raw)
To: linuxppc-dev
Hello to everyone,
I was trying to enable the SPI of a lite5200 board. I've seen that
there's something related to this in
arch/powerpc/boot/dts/lite5200b.dts
>spi@f00 {
> device_type = "spi";
> compatible = "mpc5200b-spi\0mpc5200-spi";
> reg = <f00 20>;
> interrupts = <2 d 0 2 e 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
but I'm not able to find where to enable it in menuconfig. Under
device drivers -> Spi support there only the PSC SPI.
Where am I wrong?
Thanks in advance,
Fabrizio Garetto
^ permalink raw reply
* on the topic of of_device resources...
From: David Miller @ 2008-05-05 7:59 UTC (permalink / raw)
To: linuxppc-dev
Since it came to my attention due to the build error fix
I just had to fix, I figured I'd mention some things.
Right now, powerpc and sparc differ in how they resolve
interrupts and resources.
Powerpc uses an on-demand model, whereas Sparc pre-resolves
everything at bootup when parsing the OF tree.
Unfortunately they operate on differing objects too, otherwise I could
provide routines to match the interfaces that powerpc OF drivers want
:-/
Powerpc drivers want device_node objects, whereas sparc roots all
driver usable objects under of_platform_bus using of_device objects
(which point to the device_node if the driver needs that).
Inside of the of_device is where we hang the fully resolved resources
and interrupts.
I'd like to see consolidation in this area, and in return I'll be
compiling all of your PPC_OF devices in my allmodconfig builds on
sparc :-)
^ permalink raw reply
* [PATCH]: PPC_OF protect USB driver...
From: David Miller @ 2008-05-05 7:57 UTC (permalink / raw)
To: linuxppc-dev
This uses APIs that are not generic, or at least not part of
what Sparc provides yet.
So just PPC_OF this for now just like the EHCI_OF driver.
This fixes allmodconfig build errors on sparc.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 33b467a..1ef6df3 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -129,7 +129,7 @@ config USB_ISP1760_PCI
config USB_ISP1760_OF
bool "Support for the OF platform bus"
- depends on USB_ISP1760_HCD && OF
+ depends on USB_ISP1760_HCD && PPC_OF
---help---
Enables support for the device present on the PowerPC
OpenFirmware platform bus.
^ permalink raw reply related
* [PATCH 4/4] booting-without-of for Freescale MSI
From: Jason Jin @ 2008-05-05 7:47 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Jason Jin
In-Reply-To: <1209973634-1699-3-git-send-email-Jason.jin@freescale.com>
Binding document adding for Freescale MSI support.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
Documentation/powerpc/booting-without-of.txt | 37 +++++++++++++++++++++++++-
1 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 1d2a772..9c496f6 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -57,7 +57,10 @@ Table of Contents
n) 4xx/Axon EMAC ethernet nodes
o) Xilinx IP cores
p) Freescale Synchronous Serial Interface
- q) USB EHCI controllers
+ q) USB EHCI controllers
+ r) Freescale Display Interface Unit
+ s) Freescale on board FPGA
+ t) Freescael MSI interrupt controller
VII - Marvell Discovery mv64[345]6x System Controller chips
1) The /system-controller node
@@ -2870,6 +2873,38 @@ platforms are moved over to use the flattened-device-tree model.
reg = <0xe8000000 32>;
};
+ t) Freescale MSI interrupt controller
+
+ Reguired properities:
+ - compatible : should be "fsl,MPIC-MSI" for 85xx/86xx cpu,
+ and "fsl,IPIC-MSI" for 83xx cpu.
+ - reg : should contain the address and the length of the shared message
+ interrupt register set.
+ - msi-available-ranges: use <start count> style section to define which
+ msi interrupt can be used in the 256 msi interrupts.
+ - interrupts : should contain the msi interrupts cascade to the host
+ interrupt controller.
+ - interrupt-parent: should be "&mpic" for 85xx/86xx cpu and "&ipic"
+ for 83xx cpu.
+
+ Example (85xx/86xx)
+ msi@41600 {
+ compatible = "fsl,MPIC-MSI";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
+
VII - Marvell Discovery mv64[345]6x System Controller chips
===========================================================
--
1.5.4
^ permalink raw reply related
* [PATCH 3/4] Enable MSI support for 85xxds board.
From: Jason Jin @ 2008-05-05 7:47 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Jason Jin
In-Reply-To: <1209973634-1699-2-git-send-email-Jason.jin@freescale.com>
This patch enabled MSI on 8544ds and 8572ds board.
only one MSI interrupt can generate on 8544 board.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
arch/powerpc/boot/dts/mpc8544ds.dts | 16 ++++++++++++++++
arch/powerpc/boot/dts/mpc8572ds.dts | 16 ++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 7 ++++++-
3 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts
index 6a0d8db..1059281 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -219,6 +219,22 @@
device_type = "open-pic";
big-endian;
};
+
+ msi@41600 {
+ compatible = "fsl,MPIC-MSI";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
};
pci0: pci@e0008000 {
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/boot/dts/mpc8572ds.dts
index 66f27ab..1c5ae9d 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -221,6 +221,22 @@
fsl,has-rstcr;
};
+ msi@41600 {
+ compatible = "fsl,MPIC-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
mpic: pic@40000 {
clock-frequency = <0>;
interrupt-controller;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index dfd8b4a..2696d2f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -79,9 +79,13 @@ void __init mpc85xx_ds_pic_init(void)
mpic = mpic_alloc(np, r.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
- 0, 256, " OpenPIC ");
+ 64, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
+ mpic_assign_isu(mpic, 0, r.start + 0x10000);
+ mpic_assign_isu(mpic, 1, r.start + 0x10800);
+ mpic_assign_isu(mpic, 2, r.start + 0x11600);
+
mpic_init(mpic);
#ifdef CONFIG_PPC_I8259
@@ -195,6 +199,7 @@ static int __init mpc85xxds_publish_devices(void)
return of_platform_bus_probe(NULL, mpc85xxds_ids, NULL);
}
machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices);
+machine_device_initcall(mpc8572_ds, mpc85xxds_publish_devices);
/*
* Called very early, device-tree isn't unflattened
--
1.5.4
^ permalink raw reply related
* [PATCH 2/4 V2] Enable MSI support for MPC8610HPCD board
From: Jason Jin @ 2008-05-05 7:47 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Jason Jin
In-Reply-To: <1209973634-1699-1-git-send-email-Jason.jin@freescale.com>
This patch enable the MSI on 8610hpcd board.
Through the msi-available-ranges property, All the 256
msi interrupts can be tested on this board.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
V2 version deleted the PEX2 dts node according the updated git tree
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 16 ++++++++++++++++
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 6 +++++-
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index bba234e..266e1b8 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -128,6 +128,22 @@
big-endian;
};
+ msi@41600 {
+ compatible = "fsl,MPIC-MSI";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
global-utilities@e0000 {
compatible = "fsl,mpc8610-guts";
reg = <0xe0000 0x1000>;
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 5e1e8cf..59f75f7 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -70,9 +70,13 @@ static void __init mpc86xx_hpcd_init_irq(void)
/* Alloc mpic structure and per isu has 16 INT entries. */
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
- 0, 256, " MPIC ");
+ 64, 256, " MPIC ");
BUG_ON(mpic1 == NULL);
+ mpic_assign_isu(mpic1, 0, res.start + 0x10000);
+ mpic_assign_isu(mpic1, 1, res.start + 0x10800);
+ mpic_assign_isu(mpic1, 2, res.start + 0x11600);
+
mpic_init(mpic1);
}
--
1.5.4
^ permalink raw reply related
* [PATCH 1/4 V3] MSI support on 83xx/85xx/86xx board
From: Jason Jin @ 2008-05-05 7:47 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Jason Jin
This MSI driver can be used on 83xx/85xx/86xx board.
In this driver, virtual interrupt host and chip were
setup. There are 256 MSI interrupts in this host, Every 32
MSI interrupts cascaded to one IPIC/MPIC interrupt.
The chip was treated as edge sensitive and some necessary
functions were setup for this chip.
Before using the MSI interrupt, PCI/PCIE device need to
ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
bitmap show which MSI interrupt was used, reserve bit in
the bitmap can be used to force the device use some designate
MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
for testing the all the MSI interrupts. The msi-available-ranges
property in the dts file was used for this purpose.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
V3 version updated per Kumar's suggestions.
arch/powerpc/sysdev/Makefile | 3 +-
arch/powerpc/sysdev/fsl_msi.c | 442 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_msi.h | 31 +++
arch/powerpc/sysdev/fsl_pci.c | 14 ++
4 files changed, 489 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_msi.c
create mode 100644 arch/powerpc/sysdev/fsl_msi.h
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 6d386d0..98b6b8e 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,7 @@ endif
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+fsl-msi-obj-$(CONFIG_PCI_MSI) += fsl_msi.o
obj-$(CONFIG_PPC_MPC106) += grackle.o
obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
@@ -11,7 +12,7 @@ obj-$(CONFIG_PPC_PMI) += pmi.o
obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
-obj-$(CONFIG_FSL_PCI) += fsl_pci.o
+obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
new file mode 100644
index 0000000..c53f716
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -0,0 +1,442 @@
+/*
+ * Copyright (C) 2007-2008 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Tony Li <tony.li@freescale.com>
+ * Jason Jin <Jason.jin@freescale.com>
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ */
+#include <linux/irq.h>
+#include <linux/bootmem.h>
+#include <linux/bitmap.h>
+#include <linux/msi.h>
+#include <linux/pci.h>
+#include <linux/of_platform.h>
+#include <sysdev/fsl_soc.h>
+#include <asm/prom.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+#include "fsl_msi.h"
+
+struct fsl_msi_feature {
+ u32 fsl_pic_ip;
+ u32 msiir_offset;
+};
+
+/* A bit ugly, can we get this from the pci_dev somehow? */
+static struct fsl_msi *fsl_msi;
+
+static inline u32 fsl_msi_read(u32 __iomem *base, unsigned int reg)
+{
+ return in_be32(base + (reg >> 2));
+}
+
+static inline void fsl_msi_write(u32 __iomem *base,
+ unsigned int reg, u32 value)
+{
+ out_be32(base + (reg >> 2), value);
+}
+
+/*
+ * We do not need this actually. The MSIR register has been read once
+ * in the cascade interrupt. So, this MSI interrupt has been acked
+*/
+static void fsl_msi_end_irq(unsigned int virq)
+{
+}
+
+static struct irq_chip fsl_msi_chip = {
+ .mask = mask_msi_irq,
+ .unmask = unmask_msi_irq,
+ .ack = fsl_msi_end_irq,
+ .typename = " FSL-MSI ",
+};
+
+static int fsl_msi_host_match(struct irq_host *h, struct device_node *node)
+{
+ /* Exact match, unless node is NULL */
+ return h->of_node == NULL || h->of_node == node;
+}
+
+
+static int fsl_msi_host_map(struct irq_host *h, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ struct irq_chip *chip = &fsl_msi_chip;
+
+ get_irq_desc(virq)->status |= IRQ_TYPE_EDGE_FALLING;
+
+ set_irq_chip_and_handler(virq, chip, handle_edge_irq);
+
+ return 0;
+}
+
+static struct irq_host_ops fsl_msi_host_ops = {
+ .match = fsl_msi_host_match,
+ .map = fsl_msi_host_map,
+};
+
+irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
+{
+ unsigned long flags;
+ int offset, order = get_count_order(num);
+
+ spin_lock_irqsave(&msi->bitmap_lock, flags);
+
+ offset = bitmap_find_free_region(msi->fsl_msi_bitmap,
+ NR_MSI_IRQS, order);
+
+ spin_unlock_irqrestore(&msi->bitmap_lock, flags);
+
+ pr_debug("%s: allocated 0x%x (2^%d) at offset 0x%x\n",
+ __func__, num, order, offset);
+
+ return offset;
+}
+
+void fsl_msi_free_hwirqs(struct fsl_msi *msi, int offset, int num)
+{
+ unsigned long flags;
+ int order = get_count_order(num);
+
+ pr_debug("%s: freeing 0x%x (2^%d) at offset 0x%x\n",
+ __func__, num, order, offset);
+
+ spin_lock_irqsave(&msi->bitmap_lock, flags);
+ bitmap_release_region(msi->fsl_msi_bitmap, offset, order);
+ spin_unlock_irqrestore(&msi->bitmap_lock, flags);
+}
+
+static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
+{
+ int i, len;
+ const u32 *p;
+
+ p = of_get_property(msi->of_node, "msi-available-ranges", &len);
+ if (!p) {
+ pr_debug("fsl_msi: no msi-available-ranges property found \
+ on %s\n", msi->of_node->full_name);
+ return -ENODEV;
+ }
+
+ if ((len % 0x8) != 0) {
+ printk(KERN_WARNING "fsl_msi: Malformed msi-available-ranges "
+ "property on %s\n", msi->of_node->full_name);
+ return -EINVAL;
+ }
+
+ bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
+ get_count_order(NR_MSI_IRQS));
+
+ /* Format is: (<u32 start> <u32 count>)+ */
+ len /= sizeof(u32);
+ len /= 2;
+ for (i = 0; i < len; i++, p += 2)
+ fsl_msi_free_hwirqs(msi, *p, *(p + 1));
+
+ return 0;
+}
+
+static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
+{
+ int rc, size;
+
+ size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(u32);
+
+ msi_data->fsl_msi_bitmap = kzalloc(size, GFP_KERNEL);
+
+ if (msi_data->fsl_msi_bitmap == NULL) {
+ pr_debug("%s: ENOMEM allocating allocator bitmap!\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ rc = fsl_msi_free_dt_hwirqs(msi_data);
+ if (rc)
+ goto out_free;
+
+ return 0;
+out_free:
+ kfree(msi_data->fsl_msi_bitmap);
+
+ msi_data->fsl_msi_bitmap = NULL;
+ return rc;
+
+}
+
+static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
+{
+ if (type == PCI_CAP_ID_MSIX)
+ pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
+
+ return 0;
+}
+
+static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
+{
+ struct msi_desc *entry;
+ struct fsl_msi *msi_data = fsl_msi;
+
+ list_for_each_entry(entry, &pdev->msi_list, list) {
+ if (entry->irq == NO_IRQ)
+ continue;
+ set_irq_msi(entry->irq, NULL);
+ fsl_msi_free_hwirqs(msi_data, virq_to_hw(entry->irq), 1);
+ irq_dispose_mapping(entry->irq);
+ }
+
+ return;
+}
+
+static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
+ struct msi_msg *msg)
+{
+ struct fsl_msi *msi_data = fsl_msi;
+
+ msg->address_lo = msi_data->msi_addr_lo;
+ msg->address_hi = msi_data->msi_addr_hi;
+ msg->data = hwirq;
+
+ pr_debug("%s: allocated srs: %d, ibs: %d\n",
+ __func__, hwirq / IRQS_PER_MSI_REG, hwirq % IRQS_PER_MSI_REG);
+}
+
+static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
+{
+ irq_hw_number_t hwirq;
+ int rc;
+ unsigned int virq;
+ struct msi_desc *entry;
+ struct msi_msg msg;
+ struct fsl_msi *msi_data = fsl_msi;
+
+ list_for_each_entry(entry, &pdev->msi_list, list) {
+ hwirq = fsl_msi_alloc_hwirqs(msi_data, 1);
+ if (hwirq < 0) {
+ rc = hwirq;
+ pr_debug("%s: fail allocating msi interrupt\n",
+ __func__);
+ goto out_free;
+ }
+
+ virq = irq_create_mapping(msi_data->irqhost, hwirq);
+
+ if (virq == NO_IRQ) {
+ pr_debug("%s: fail mapping hwirq 0x%lx\n",
+ __func__, hwirq);
+ fsl_msi_free_hwirqs(msi_data, hwirq, 1);
+ rc = -ENOSPC;
+ goto out_free;
+ }
+ set_irq_msi(virq, entry);
+
+ fsl_compose_msi_msg(pdev, hwirq, &msg);
+ write_msi_msg(virq, &msg);
+ }
+ return 0;
+
+out_free:
+ return rc;
+}
+
+void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq;
+ struct fsl_msi *msi_data = fsl_msi;
+ int msir_index = -1;
+ u32 msir_value = 0;
+ u32 intr_index;
+ u32 have_shift = 0;
+
+ spin_lock(&desc->lock);
+ if ((msi_data->feature & FSL_PIC_IP_MASK) == FSL_PIC_IP_IPIC) {
+ if (desc->chip->mask_ack)
+ desc->chip->mask_ack(irq);
+ else {
+ desc->chip->mask(irq);
+ desc->chip->ack(irq);
+ }
+ }
+
+ if (unlikely(desc->status & IRQ_INPROGRESS))
+ goto unlock;
+
+ msir_index = (int)(desc->handler_data);
+
+ if (msir_index >= NR_MSI_REG)
+ cascade_irq = NO_IRQ;
+
+ desc->status |= IRQ_INPROGRESS;
+ switch (fsl_msi->feature & FSL_PIC_IP_MASK) {
+ case FSL_PIC_IP_MPIC:
+ msir_value = fsl_msi_read(msi_data->msi_regs,
+ msir_index * 0x10);
+ break;
+ case FSL_PIC_IP_IPIC:
+ msir_value = fsl_msi_read(msi_data->msi_regs, msir_index * 0x4);
+ break;
+ }
+
+ while (msir_value) {
+ intr_index = ffs(msir_value) - 1;
+
+ cascade_irq = irq_linear_revmap(msi_data->irqhost,
+ (msir_index * IRQS_PER_MSI_REG +
+ intr_index + have_shift));
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+ have_shift += (intr_index + 1);
+ msir_value = (msir_value >> (intr_index + 1));
+ }
+ desc->status &= ~IRQ_INPROGRESS;
+
+ switch (msi_data->feature & FSL_PIC_IP_MASK) {
+ case FSL_PIC_IP_MPIC:
+ desc->chip->eoi(irq);
+ break;
+ case FSL_PIC_IP_IPIC:
+ if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+ desc->chip->unmask(irq);
+ break;
+ }
+unlock:
+ spin_unlock(&desc->lock);
+}
+
+static int __devinit fsl_of_msi_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ struct fsl_msi *msi;
+ struct resource res;
+ int err, i, count;
+ int rc;
+ int virt_msir;
+ const u32 *p;
+ struct fsl_msi_feature *tmp_data;
+
+ printk(KERN_DEBUG "Setting up fsl msi support\n");
+
+ msi = kzalloc(sizeof(struct fsl_msi), GFP_KERNEL);
+ if (!msi) {
+ dev_err(&dev->dev, "No memory for MSI structure\n");
+ err = -ENOMEM;
+ goto error_out;
+ }
+
+ msi->of_node = dev->node;
+
+ msi->irqhost = irq_alloc_host(of_node_get(dev->node),
+ IRQ_HOST_MAP_LINEAR,
+ NR_MSI_IRQS, &fsl_msi_host_ops, 0);
+ if (msi->irqhost == NULL) {
+ dev_err(&dev->dev, "No memory for MSI irqhost\n");
+ of_node_put(dev->node);
+ err = -ENOMEM;
+ goto error_out;
+ }
+
+ /* Get the MSI reg base */
+ err = of_address_to_resource(dev->node, 0, &res);
+ if (err) {
+ dev_err(&dev->dev, "%s resource error!\n",
+ dev->node->full_name);
+ goto error_out;
+ }
+
+ msi->msi_regs = ioremap(res.start, res.end - res.start + 1);
+ if (!msi->msi_regs) {
+ dev_err(&dev->dev, "ioremap problem failed\n");
+ goto error_out;
+ }
+
+ tmp_data = (struct fsl_msi_feature *)match->data;
+
+ msi->feature = tmp_data->fsl_pic_ip;
+
+ msi->irqhost->host_data = msi;
+
+ msi->msi_addr_hi = 0x0;
+ msi->msi_addr_lo = res.start + tmp_data->msiir_offset;
+
+ rc = fsl_msi_init_allocator(msi);
+ if (rc) {
+ dev_err(&dev->dev, "Error allocating MSI bitmap\n");
+ goto error_out;
+ }
+
+ p = of_get_property(dev->node, "interrupts", &count);
+ if (!p) {
+ dev_err(&dev->dev, "no interrupts property found on %s\n",
+ dev->node->full_name);
+ err = -ENODEV;
+ goto error_out;
+ }
+ if (count % 8 != 0) {
+ dev_err(&dev->dev, "Malformed interrupts property on %s\n",
+ dev->node->full_name);
+ err = -EINVAL;
+ goto error_out;
+ }
+
+ count /= sizeof(u32);
+ for (i = 0; i < count / 2; i++) {
+ if (i > NR_MSI_REG)
+ break;
+ virt_msir = irq_of_parse_and_map(dev->node, i);
+ if (virt_msir != NO_IRQ) {
+ set_irq_data(virt_msir, (void *)i);
+ set_irq_chained_handler(virt_msir, fsl_msi_cascade);
+ }
+ }
+
+ fsl_msi = msi;
+
+ WARN_ON(ppc_md.setup_msi_irqs);
+ ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
+ ppc_md.msi_check_device = fsl_msi_check_device;
+ return 0;
+error_out:
+ kfree(msi);
+ return err;
+}
+
+static const struct fsl_msi_feature mpic_msi_feature = {
+ .fsl_pic_ip = FSL_PIC_IP_MPIC,
+ .msiir_offset = 0x140,
+};
+
+
+static const struct fsl_msi_feature ipic_msi_feature = {
+ .fsl_pic_ip = FSL_PIC_IP_IPIC,
+ .msiir_offset = 0x38,
+};
+
+static const struct of_device_id fsl_of_msi_ids[] = {
+ {
+ .compatible = "fsl,MPIC-MSI",
+ .data = (void *)&mpic_msi_feature,
+ },
+ {
+ .compatible = "fsl,IPIC-MSI",
+ .data = (void *)&ipic_msi_feature,
+ },
+ {}
+};
+
+static struct of_platform_driver fsl_of_msi_driver = {
+ .name = "fsl-of-msi",
+ .match_table = fsl_of_msi_ids,
+ .probe = fsl_of_msi_probe,
+};
+
+static __init int fsl_of_msi_init(void)
+{
+ return of_register_platform_driver(&fsl_of_msi_driver);
+}
+
+subsys_initcall(fsl_of_msi_init);
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
new file mode 100644
index 0000000..0449c96
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -0,0 +1,31 @@
+#ifndef _POWERPC_SYSDEV_FSL_MSI_H
+#define _POWERPC_SYSDEV_FSL_MSI_H
+
+#define NR_MSI_REG 8
+#define IRQS_PER_MSI_REG 32
+#define NR_MSI_IRQS (NR_MSI_REG * IRQS_PER_MSI_REG)
+
+#define FSL_PIC_IP_MASK 0x0000000F
+#define FSL_PIC_IP_MPIC 0x00000001
+#define FSL_PIC_IP_IPIC 0x00000002
+
+struct fsl_msi {
+ /* Device node of the MSI interrupt*/
+ struct device_node *of_node;
+
+ struct irq_host *irqhost;
+
+ unsigned long cascade_irq;
+
+ u32 msi_addr_lo;
+ u32 msi_addr_hi;
+ void __iomem *msi_regs;
+ u32 feature;
+
+ unsigned long *fsl_msi_bitmap;
+ spinlock_t bitmap_lock;
+ const char *name;
+};
+
+#endif /* _POWERPC_SYSDEV_FSL_MSI_H */
+
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index bf13c21..fede767 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -106,6 +106,16 @@ void __init setup_pci_cmd(struct pci_controller *hose)
}
}
+#ifdef CONFIG_PCI_MSI
+void __init setup_pci_pcsrbar(struct pci_controller *hose)
+{
+ phys_addr_t immr_base;
+
+ immr_base = get_immrbase();
+ early_write_config_dword(hose, 0, 0, PCI_BASE_ADDRESS_0, immr_base);
+}
+#endif
+
static int fsl_pcie_bus_fixup;
static void __init quirk_fsl_pcie_header(struct pci_dev *dev)
@@ -211,6 +221,10 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
/* Setup PEX window registers */
setup_pci_atmu(hose, &rsrc);
+ /*Setup PEXCSRBAR */
+#ifdef CONFIG_PCI_MSI
+ setup_pci_pcsrbar(hose);
+#endif
return 0;
}
--
1.5.4
^ permalink raw reply related
* [PATCH] [POWERPC] 4xx: Fix problem with new TLB storage attibute fields on 440x6 core
From: Stefan Roese @ 2008-05-05 6:53 UTC (permalink / raw)
To: linuxppc-dev
The new 440x6 core used on AMCC 460EX/GT introduces new storage attibure
fields to the TLB2 word. Those are:
Bit 11 12 13 14 15
WL1 IL1I IL1D IL2I IL2D
With these bits the cache (L1 and L2) can be configured in a more flexible
way, instruction- and data-cache independently now. The "old" I and W bits
are still available and setting these old bits will automically set these
new bits too (for backward compatibilty).
The current code does not clear these fields resulting in disabling the cache
by chance. This patch now makes sure that these new bits are cleared when
the TLB2 word is written.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/kernel/head_44x.S | 9 ++++++++-
include/asm-powerpc/pgtable-ppc32.h | 7 +++++++
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index ad071a1..5485000 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -653,7 +653,14 @@ finish_tlb_load:
rlwimi r10, r11, 0, 26, 26 /* UX = HWEXEC & USER */
rlwimi r12, r10, 0, 26, 31 /* Insert static perms */
- rlwinm r12, r12, 0, 20, 15 /* Clear U0-U3 */
+
+ /*
+ * Clear U0-U3 and WL1 IL1I IL1D IL2I IL2D bits which are added
+ * on newer 440 cores like the 440x6 used on AMCC 460EX/460GT (see
+ * include/asm-powerpc/pgtable-ppc32.h for details).
+ */
+ rlwinm r12, r12, 0, 20, 10
+
tlbwe r12, r13, PPC44x_TLB_ATTRIB /* Write ATTRIB */
/* Done...restore registers and get out of here.
diff --git a/include/asm-powerpc/pgtable-ppc32.h b/include/asm-powerpc/pgtable-ppc32.h
index 2c79f55..a30e081 100644
--- a/include/asm-powerpc/pgtable-ppc32.h
+++ b/include/asm-powerpc/pgtable-ppc32.h
@@ -212,6 +212,13 @@ extern int icache_44x_need_flush;
* 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
* - - - - - - U0 U1 U2 U3 W I M G E - UX UW UR SX SW SR
*
+ * Newer 440 cores (440x6 as used on AMCC 460EX/460GT) have additional
+ * TLB2 storage attibute fields. Those are:
+ *
+ * TLB2:
+ * 0...10 11 12 13 14 15 16...31
+ * no change WL1 IL1I IL1D IL2I IL2D no change
+ *
* There are some constrains and options, to decide mapping software bits
* into TLB entry.
*
--
1.5.5.1
^ permalink raw reply related
* Re: WARNING: mutexes are preferred for single holder semaphores
From: Christoph Hellwig @ 2008-05-05 6:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Sean MacLennan, linuxppc-dev
In-Reply-To: <18462.27991.229693.188377@cargo.ozlabs.ibm.com>
On Mon, May 05, 2008 at 12:13:43PM +1000, Paul Mackerras wrote:
> Sean MacLennan writes:
>
> > This is a bit OT, but I got the warning in the subject from
> > checkpatch.pl for a piece of code. The code *is* using a mutex. Does it
> > actually mean I shouldn't use a mutex?
>
> I don't require zero checkpatch warnings or errors on patches before I
> accept them. If what checkpatch is saying is rubbish, just ignore it.
Current versions don't spew much rubbish anymore, and this one certainly
isn't.
^ permalink raw reply
* Re: [patch 2/5] macintosh: qindfarm_smu_sat: semaphore to mutex
From: Benjamin Herrenschmidt @ 2008-05-05 5:44 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev, paulus, dwalker
In-Reply-To: <200805022034.m42KY3Wn013261@imap1.linux-foundation.org>
On Fri, 2008-05-02 at 13:34 -0700, akpm@linux-foundation.org wrote:
> From: Daniel Walker <dwalker@mvista.com>
>
> Signed-off-by: Daniel Walker <dwalker@mvista.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
^ permalink raw reply
* Re: [patch 3/5] machintosh: ADB driver: adb_handler_sem semaphore to mutex
From: Benjamin Herrenschmidt @ 2008-05-05 5:45 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev, paulus, dwalker
In-Reply-To: <200805022034.m42KY3gD013264@imap1.linux-foundation.org>
On Fri, 2008-05-02 at 13:34 -0700, akpm@linux-foundation.org wrote:
> From: Daniel Walker <dwalker@mvista.com>
>
> Signed-off-by: Daniel Walker <dwalker@mvista.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
^ permalink raw reply
* Re: [patch 1/5] macintosh: therm_pm72: driver_lock semaphore to mutex
From: Benjamin Herrenschmidt @ 2008-05-05 5:42 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev, paulus, dwalker
In-Reply-To: <200805022034.m42KY234013256@imap1.linux-foundation.org>
On Fri, 2008-05-02 at 13:34 -0700, akpm@linux-foundation.org wrote:
> From: Daniel Walker <dwalker@mvista.com>
>
> Signed-off-by: Daniel Walker <dwalker@mvista.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
^ permalink raw reply
* [PATCH] [POWERPC] More useful cputable defaults
From: Benjamin Herrenschmidt @ 2008-05-05 5:22 UTC (permalink / raw)
To: linuxppc-dev
Changes the cputable so that various CPU families that have an exclusive
CONFIG_ option have a more sensible default entry to patch if the specific
processor hasn't been identified.
This makes the kernel more generally useful when booted on an unknown
PVR for things like new 4xx variants.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/cputable.c | 53 +++++++++++++++++++++++++++++++++--------
1 file changed, 43 insertions(+), 10 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/cputable.c 2008-05-05 13:43:02.000000000 +1000
+++ linux-work/arch/powerpc/kernel/cputable.c 2008-05-05 13:47:52.000000000 +1000
@@ -1207,6 +1207,18 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_4xx,
.platform = "ppc405",
},
+ { /* default match */
+ .pvr_mask = 0x00000000,
+ .pvr_value = 0x00000000,
+ .cpu_name = "(generic 40x PPC)",
+ .cpu_features = CPU_FTRS_40X,
+ .cpu_user_features = PPC_FEATURE_32 |
+ PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc405",
+ }
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
@@ -1397,8 +1409,18 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_440A,
.platform = "ppc440",
},
+ { /* default match */
+ .pvr_mask = 0x00000000,
+ .pvr_value = 0x00000000,
+ .cpu_name = "(generic 44x PPC)",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc440",
+ }
#endif /* CONFIG_44x */
-#ifdef CONFIG_FSL_BOOKE
#ifdef CONFIG_E200
{ /* e200z5 */
.pvr_mask = 0xfff00000,
@@ -1427,7 +1449,19 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_e200,
.platform = "ppc5554",
},
-#elif defined(CONFIG_E500)
+ { /* default match */
+ .pvr_mask = 0x00000000,
+ .pvr_value = 0x00000000,
+ .cpu_name = "(generic E200 PPC)",
+ .cpu_features = CPU_FTRS_E200,
+ .cpu_user_features = COMMON_USER_BOOKE |
+ PPC_FEATURE_HAS_EFP_SINGLE |
+ PPC_FEATURE_UNIFIED_CACHE,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_e200,
+ .platform = "ppc5554",
+#endif /* CONFIG_E200 */
+#ifdef CONFIG_E500
{ /* e500 */
.pvr_mask = 0xffff0000,
.pvr_value = 0x80200000,
@@ -1463,20 +1497,19 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_e500,
.platform = "ppc8548",
},
-#endif
-#endif
-#if !CLASSIC_PPC
{ /* default match */
.pvr_mask = 0x00000000,
.pvr_value = 0x00000000,
- .cpu_name = "(generic PPC)",
- .cpu_features = CPU_FTRS_GENERIC_32,
- .cpu_user_features = PPC_FEATURE_32,
+ .cpu_name = "(generic E500 PPC)",
+ .cpu_features = CPU_FTRS_E500,
+ .cpu_user_features = COMMON_USER_BOOKE |
+ PPC_FEATURE_HAS_SPE_COMP |
+ PPC_FEATURE_HAS_EFP_SINGLE_COMP,
.icache_bsize = 32,
.dcache_bsize = 32,
+ .machine_check = machine_check_e500,
.platform = "powerpc",
- }
-#endif /* !CLASSIC_PPC */
+#endif /* CONFIG_E500 */
#endif /* CONFIG_PPC32 */
};
^ permalink raw reply
* Re: WARNING: mutexes are preferred for single holder semaphores
From: Sean MacLennan @ 2008-05-05 4:40 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1209958719.21644.32.camel@pasglop>
On Mon, 05 May 2008 13:38:39 +1000
"Benjamin Herrenschmidt" <benh@kernel.crashing.org> wrote:
> Show us the code... It could be a bug in checkpatch or you using
> the wrong functions somewhere ...
The change to DEFINE_MUTEX and changing up/down to
mutex_lock/mutex_unlock solved the problem.
The code is GPLed but not currently available on the net. It is
basically a little driver that registers a character device and
then passes out the minor numbers to the PIKA board drivers.
It was written to isolate all the character/sysfs code to one place
since we have five drivers, and many debug drivers, that use it.
If anybody is really interested, I can post it here. I doubt it will
ever be submitted to the mainline kernel however.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix of_i2c include for module compilation
From: Paul Mackerras @ 2008-05-05 4:15 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Stephen Rothwell, linuxppc-dev list, Kernel, Linux, Scott Wood,
Linux I2C, Jean Delvare, David Miller
In-Reply-To: <481C5DD0.5090503@scram.de>
Jochen Friedrich writes:
> -#ifdef CONFIG_OF_I2C
> +#if defined(CONFIG_OF_I2C) || defined(CONFIG_OF_I2C_MODULE)
>
> void of_register_i2c_devices(struct i2c_adapter *adap,
> struct device_node *adap_node);
Why do we have that ifdef there at all? There's only that one
external declaration within it, so the #ifdef and #endif could just be
removed. If the ifdef hadn't been there in the first place we
wouldn't have had this problem.
Paul.
^ permalink raw reply
* Re: WARNING: mutexes are preferred for single holder semaphores
From: Benjamin Herrenschmidt @ 2008-05-05 3:38 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080504204104.7eea7618@lappy.seanm.ca>
On Sun, 2008-05-04 at 20:41 -0400, Sean MacLennan wrote:
> This is a bit OT, but I got the warning in the subject from
> checkpatch.pl for a piece of code. The code *is* using a mutex. Does it
> actually mean I shouldn't use a mutex?
>
> The code declares a global mutex:
>
> static DECLARE_MUTEX(list_lock);
>
> The odds of two accesses to the list_lock at the same time are zero.
> But it would be Very Bad(tm) if it did happen. Since the odds of
> contention are near zero, the cost of the mutex is near zero, so I put
> it in.
>
> I think I can safely ignore the warning, but I want to make sure....
Show us the code... It could be a bug in checkpatch or you using
the wrong functions somewhere ...
Ben.
^ permalink raw reply
* Re: WARNING: mutexes are preferred for single holder semaphores
From: Paul Mackerras @ 2008-05-05 2:13 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080504204104.7eea7618@lappy.seanm.ca>
Sean MacLennan writes:
> This is a bit OT, but I got the warning in the subject from
> checkpatch.pl for a piece of code. The code *is* using a mutex. Does it
> actually mean I shouldn't use a mutex?
I don't require zero checkpatch warnings or errors on patches before I
accept them. If what checkpatch is saying is rubbish, just ignore it.
Paul.
^ permalink raw reply
* Re: WARNING: mutexes are preferred for single holder semaphores
From: Sean MacLennan @ 2008-05-05 1:31 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1209949615.8159.7.camel@localhost>
On Mon, 05 May 2008 11:06:55 +1000
"Michael Ellerman" <michael@ellerman.id.au> wrote:
> On Sun, 2008-05-04 at 20:41 -0400, Sean MacLennan wrote:
> > This is a bit OT, but I got the warning in the subject from
> > checkpatch.pl for a piece of code. The code *is* using a mutex.
> > Does it actually mean I shouldn't use a mutex?
> >
> > The code declares a global mutex:
> >
> > static DECLARE_MUTEX(list_lock);
>
> .. which is a semaphore :( [see include/linux/semaphore.h]
>
> I think you want DEFINE_MUTEX().
>
> Yes, this is completely ridiculous.
>
> cheers
>
Ok, that fixed it, once I changed all the up and down calls :p
Thanks.
Cheers,
Sean
^ 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