* Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
From: Vitaly Bordug @ 2007-08-27 6:50 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070827015417.GB12804@localhost.localdomain>
On Mon, 27 Aug 2007 11:54:17 +1000
David Gibson wrote:
> On Sat, Aug 25, 2007 at 01:29:54PM +0400, Vitaly Bordug wrote:
> >
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > Signed-off-by: Stefan Roese <sr@denx.de>
> >
> > ---
> >
> > arch/powerpc/boot/dts/sequoia.dts | 26 ++++++++++++++++++++++++++
> > 1 files changed, 26 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/sequoia.dts
> > b/arch/powerpc/boot/dts/sequoia.dts index ef6f41c..8eb258f 100644
> > --- a/arch/powerpc/boot/dts/sequoia.dts
> > +++ b/arch/powerpc/boot/dts/sequoia.dts
> > @@ -92,6 +92,32 @@
> > #size-cells = <1>;
> > ranges;
> > clock-frequency = <0>; /* Filled in by zImage */
> > +
> > + pci {
> > + /* irqs are routed to irq67, dependless of
> > devsel/PIRQx */
> > + interrupt-map-mask = <0 0 0 0>;
> > + interrupt-map = <0 0 0 0 &UIC2 3
> > 8>; +
> > + interrupt-parent = <&UIC2>;
> > + interrupts = <3 8>;
> > +
> > + bus-range = <0 0>;
> > +
> > + /*
> > + * mem is at 80000000 set up indirectly
> > + * io is at 0001_e800_0000
> > + */
> > + ranges = <02000000 0 80000000 1 80000000 0
> > 10000000
> > + 01000000 0 00000000 1 e8000000 0
> > 00100000>; +
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > +
> > + reg = <1 eec00000 40 1 ef400000
> > 40>; /* phb cfg, phb reg */
> > + compatible = "ibm, 440epx";
> > + device_type = "pci";
>
> I usually put device_type, compatible and reg at the top of the block,
> to announce what the node actually is before giving all the details.
>
ok
> Also, apart from the stray space in the compatible, I'm guessing that
> the 440EPx bridge is actually more-or-less like the PCI bridges on
> other 4xx chips, so we should have a more general compatible string
> too.
>
heh, with a sole PCI impl on 4xx it does not hurt to have more general
stuff here.
what is proposed, "amcc,4xx"?
> Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
> should be reflected in the name and compatible as well.
>
"The 32-bit PCI bridge is compatible with he PCI Specification, Version
2.2 (it does not support 5V operation) "
so seems to be vanilla PCI.
> > + };
> >
> > SDRAM0: sdram {
> > device_type = "memory-controller";
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
From: Vitaly Bordug @ 2007-08-27 6:55 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070827015719.GD12804@localhost.localdomain>
On Mon, 27 Aug 2007 11:57:19 +1000
David Gibson wrote:
> > + * Free Software Foundation; either version 2 of the License, or
> > (at your
> > + * option) any later version.
> > + */
>
> Unless there really is something peculiar about the EPx bridge
> compared to say the GP, EP and other 4xx bridges, this should have a
> more general name.
well, I'd rather extend the name once/when it would be validated to work on those GR, EP etc.
But, if preferred, it does not hurt to change all the prefixes to ppc4xx_ with such a sole implementation,
and fork() if required later.
opinions?
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Rogério Brito @ 2007-08-27 6:52 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Rogério Brito, linux-kernel, Rafael J. Wysocki, linuxppc-dev,
debian-powerpc, Linux-pm mailing list
In-Reply-To: <6bffcb0e0708261621q25316becqce7b3ae2176f45a8@mail.gmail.com>
Hi, Thanks, Michal.
I didn't know who to include as the wizards of the matter.
On Aug 27 2007, Michal Piotrowski wrote:
> [Adding STR wizards to CC]
>
> On 26/08/07, Rogério Brito <rbrito@gmail.com> wrote:
> > If I, on the other hand, use Debian's kernel 2.6.22 or compile my own
> > kernel with just the necessary parts for my work (version 2.6.23-rc3
> > taken from kernel.org), then I can't make the machine sleep: when I
> > press the button, it acts like if I had, in sequence, pressed anything
> > to wake it up (say, like pressing shift).
Things are getting now a little bit fishy.
Before, I was using gnome and all the little daemons that come with it
(even though I just prefer a plain window manager), but, as I mentioned
before, it didn't matter if I pressed the power button on X or on a
console.
I had the gnomee power-thingy sounding like an alarm (an ambulance!) on me
when I pressed the power button with Debian kernels 2.6.22, for instance. I
compiled my own (this time, from kernel.org) 2.6.23-rc3, with many modules
and subsystems removed (e.g., bluetooth, as this laptop doesn't have it)
and I got the exact same behavior.
If I booted, OTOH, with Debian's kernel 2.6.18, things were fine and the
machine would go to sleep without any problems.
I am now suspecting of some module that prevented the machine from going to
sleep and I now using just a fluxbox as my window manager. This time, even
with a 2.6.23-rc3 kernel (again, from kernel.org) the machine went to sleep
normally.
I did 13 compiles with git bisect and some of them were unsucessfuly
compiled, which I am afraid that may miss the real cause if I tag them as
being "bad" (which I did). (This was with just a bare minimum installation
of Debian).
The course of action that I am taking right now is to pull GNOME and see if
my current 23-rc3 kernel has any problems and see which modules are loaded.
If things progress well, I will incrementally include features on the
kernel that I need (I left out, for instance, the Firewire subsystem, so
that compilation wouldn't take more than an hour here, despite the fact
that I do need Firewire support on the kernel) and see the point where
things are not normal.
Again, I am willing to test anything that is useful to getting PowerPC
working as well as it should with the final 2.6.23 release.
Please, don't hesitate to ask for any further information.
Regards, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Tim Teulings @ 2007-08-27 7:14 UTC (permalink / raw)
To: Michal Piotrowski, Rogério Brito, linux-kernel, linuxppc-dev,
debian-powerpc, Rafael J. Wysocki, Linux-pm mailing list
In-Reply-To: <20070827065246.GA21220@ime.usp.br>
Hallo!
I also have 800MHz iBook (2.2, 2 USB) and had the same problem with the=20
21.6.22 kernel a while ago and reverted back to 2.6.21. I'm not a kernel =
guy but I think I remember from kernel traces that it looked like (wise=20
chosen words ;-)) that the problems had something to do with=20
deactivating the firewire "subsystem".
I don't have traces at hand and due to lack of time cannot reproduce it=20
up to tomorrow. However this hint may speed up your analysis!
[rather long To-list, is everybody happy with this?]
--=20
Gru=DF...
Tim
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: David Gibson @ 2007-08-27 7:49 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070827103136.4e0ffc43@localhost.localdomain>
On Mon, Aug 27, 2007 at 10:31:36AM +0400, Vitaly Bordug wrote:
> On Mon, 27 Aug 2007 11:15:16 +1000
> David Gibson wrote:
>
> > On Sat, Aug 25, 2007 at 01:29:47PM +0400, Vitaly Bordug wrote:
[snip]
> > > +void __devinit pci_process_bridge_OF_ranges(struct pci_controller
> > > *hose,
> > > + struct device_node
> > > *dev, int prim) +{
> > > + static unsigned int static_lc_ranges[256];
> > > + const unsigned int *ranges;
> > > + unsigned int *lc_ranges;
> > > + unsigned int pci_space;
> > > + unsigned long size = 0;
> >
> > size can be 64-bit on 32-bit systems, at least in theory.
> >
> hm, well, but later, we'll call ioremap (at least for IO region) that has size passed as ulong type. And, such a size could be consumed by the code,only if resource_size_t is 64bit too. I'll look at it further.
You should probably actually test for that condition though, rather
than blithely truncating.
[snip]
> > > + /* Map ranges to struct according to spec. */
> > > + if (na >= 2) {
> > > + ranges64 = (void *)ranges;
> > > + ranges_amnt = rlen / sizeof(*ranges64);
> > > + } else {
> > > + ranges32 = (void *)ranges;
> > > + ranges_amnt = rlen / sizeof(*ranges32);
> > > + }
> > > +
> > > + hose->io_base_phys = 0;
> > > + for (i = 0; i < ranges_amnt; i++) {
> > > + res = NULL;
> > > + if (ranges64) {
> > > + if (ranges64[i].pci_space == 0)
> > > + continue;
> > > +
> > > + pci_space = ranges64[i].pci_space;
> > > + pci_addr =
> > > + (u64) ranges64[i].pci_addr[0] << 32 |
> > > ranges64[i].
> > > + pci_addr[1];
> >
> > Why not just define the pci_addr field in your structures as u64? You
> > would have to define the structure with attribute((packed)), I guess.
> >
> that was in the first approach, but it gets really interesting numbers (and with contents nothing to do with real stuff),
> on platforms that are pure 32bit. I mean,
I'm guessing that's because you didn't put the ((packed)) in: without
it, gcc will align the 64-bit quantity to a 64-bit boundary, inserting
32-bits of padding into the structure between pci_space and pci_addr,
so that it doesn't actually line up with the ranges property.
> u32 foo, foo1;
> u64 foo64;
>
> foo = bar[1];
> foo1 = bar[2];
> foo64 = ((u64)foo << 32) | foo1;
>
> does not seem to work on 32bit board. I may need to write a clear testcase and submit it here, maybe I'm missing something
> very obvious.
!?! shouldn't be anything wrong with that arithmetic...
[snip]
> > > + cpu_phys_addr =
> > > + of_translate_address(dev,
> > > ranges64[i].phys_addr);
> > > + /*
> > > + * I haven't observed 2 significant size
> > > cells in kernel
> > > + * code, so we're accounting only LSB of
> > > size part
> > > + * from ranges. -vitb
> > > + */
> > > + size = ranges64[i].size[1];
> > > +#ifdef CONFIG_PPC64
> > > + if (ranges64[i].size[0])
> > > + size |= ranges64[i].size[0]<<32;
> > > +#endif
> > > + DBG("Observed: pci %llx phys %llx size
> > > %x\n", pci_addr,
> > > + cpu_phys_addr, size);
> > > + } else {
> > > + if (ranges32[i].pci_space == 0)
> > > + continue;
> > > +
> > > + pci_space = (unsigned
> > > int)ranges32[i].pci_space;
> > > + pci_addr = (unsigned
> > > int)ranges32[i].pci_addr[1];
> > > + cpu_phys_addr = (unsigned
> > > int)ranges32[i].phys_addr[0];
> >
> >
> > We should really be using of_translate_address() in all cases - that's
> > what it's for, after all.
> >
> being called, it gives 0 in 32bit branch of if () {. Since, iirc,
> 32bit range parsing does not have it in original, variant,
> I have it put as is. worths a brief investigation...
Then we should fix of_translate_address() for 32-bit....
I don't think this patch is actually required for the 44x pci support,
yes? It might be better to leave this until later - it's only a tiny
piece of all the consolidations we should do between ppc32 and ppc64
PCI code. Currently there are a lot of silly, subtle differences
between them :(.
> > > + size = ranges32[i].size[1];
> > > +
> > > + DBG("Observed: pci %x phys %x size %x\n",
> > > + (u32) pci_addr, (u32) cpu_phys_addr,
> > > size);
> > > + }
> >
> > You don't have any equivalent of the code that exists in both
> > pre-existing versions to coalesce contiguous ranges. You probably
> > want to use the 64-bit version, since that doesn't need a local copy
> > of the ranges.
> >
> correct. yet, the whole aim of the upper seems to use summary size of
> contiguous block and that's it.
> How would we recognize IORESOURCE_PREFETCH then? (I know, my code is missing that prefetch regions so far, but anyway).
> >From the code, it seems to declare each resource that is part of contiguous block, with the size of entire block.
>
> That's prolly from binding, but can you please elaborate the logic for better understanding?
The attributes such as PREFETCH are encoded into cell 0 of the 3-cell
OF PCI address. So, ranges with different attributes won't appear as
contiguous in this space.
--
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 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
From: Stefan Roese @ 2007-08-27 8:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20070827105507.768b1aad@localhost.localdomain>
On Monday 27 August 2007, Vitaly Bordug wrote:
> On Mon, 27 Aug 2007 11:57:19 +1000
>
> David Gibson wrote:
> > > + * Free Software Foundation; either version 2 of the License, or
> > > (at your
> > > + * option) any later version.
> > > + */
> >
> > Unless there really is something peculiar about the EPx bridge
> > compared to say the GP, EP and other 4xx bridges, this should have a
> > more general name.
>
> well, I'd rather extend the name once/when it would be validated to work on
> those GR, EP etc. But, if preferred, it does not hurt to change all the
> prefixes to ppc4xx_ with such a sole implementation, and fork() if required
> later.
>
> opinions?
I would prefer to move to a more generic name now (as already suggest).
Perhaps somebody (Josh?) has a chance to test this on Bamboo (440EP) soon.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Vitaly Bordug @ 2007-08-27 8:31 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070827074955.GE7306@localhost.localdomain>
On Mon, 27 Aug 2007 17:49:55 +1000
David Gibson wrote:
> On Mon, Aug 27, 2007 at 10:31:36AM +0400, Vitaly Bordug wrote:
> > On Mon, 27 Aug 2007 11:15:16 +1000
> > David Gibson wrote:
> >
> > > On Sat, Aug 25, 2007 at 01:29:47PM +0400, Vitaly Bordug wrote:
> [snip]
> > > > +void __devinit pci_process_bridge_OF_ranges(struct
> > > > pci_controller *hose,
> > > > + struct device_node
> > > > *dev, int prim) +{
> > > > + static unsigned int static_lc_ranges[256];
> > > > + const unsigned int *ranges;
> > > > + unsigned int *lc_ranges;
> > > > + unsigned int pci_space;
> > > > + unsigned long size = 0;
> > >
> > > size can be 64-bit on 32-bit systems, at least in theory.
> > >
> > hm, well, but later, we'll call ioremap (at least for IO region)
> > that has size passed as ulong type. And, such a size could be
> > consumed by the code,only if resource_size_t is 64bit too. I'll
> > look at it further.
>
> You should probably actually test for that condition though, rather
> than blithely truncating.
>
ok, makes sense.
> [snip]
> > > > + /* Map ranges to struct according to spec. */
> > > > + if (na >= 2) {
> > > > + ranges64 = (void *)ranges;
> > > > + ranges_amnt = rlen / sizeof(*ranges64);
> > > > + } else {
> > > > + ranges32 = (void *)ranges;
> > > > + ranges_amnt = rlen / sizeof(*ranges32);
> > > > + }
> > > > +
> > > > + hose->io_base_phys = 0;
> > > > + for (i = 0; i < ranges_amnt; i++) {
> > > > + res = NULL;
> > > > + if (ranges64) {
> > > > + if (ranges64[i].pci_space == 0)
> > > > + continue;
> > > > +
> > > > + pci_space = ranges64[i].pci_space;
> > > > + pci_addr =
> > > > + (u64) ranges64[i].pci_addr[0] <<
> > > > 32 | ranges64[i].
> > > > + pci_addr[1];
> > >
> > > Why not just define the pci_addr field in your structures as
> > > u64? You would have to define the structure with
> > > attribute((packed)), I guess.
> > >
> > that was in the first approach, but it gets really interesting
> > numbers (and with contents nothing to do with real stuff), on
> > platforms that are pure 32bit. I mean,
>
> I'm guessing that's because you didn't put the ((packed)) in: without
> it, gcc will align the 64-bit quantity to a 64-bit boundary, inserting
> 32-bits of padding into the structure between pci_space and pci_addr,
> so that it doesn't actually line up with the ranges property.
>
will check, but sounds reasonable.
> > u32 foo, foo1;
> > u64 foo64;
> >
> > foo = bar[1];
> > foo1 = bar[2];
> > foo64 = ((u64)foo << 32) | foo1;
> >
> > does not seem to work on 32bit board. I may need to write a clear
> > testcase and submit it here, maybe I'm missing something very
> > obvious.
>
> !?! shouldn't be anything wrong with that arithmetic...
>
Wrong example, I'll have real snippet if alignment trick won't work (and I hope it will)
> [snip]
> > > > + cpu_phys_addr =
> > > > + of_translate_address(dev,
> > > > ranges64[i].phys_addr);
> > > > + /*
> > > > + * I haven't observed 2 significant
> > > > size cells in kernel
> > > > + * code, so we're accounting only LSB
> > > > of size part
> > > > + * from ranges. -vitb
> > > > + */
> > > > + size = ranges64[i].size[1];
> > > > +#ifdef CONFIG_PPC64
> > > > + if (ranges64[i].size[0])
> > > > + size |=
> > > > ranges64[i].size[0]<<32; +#endif
> > > > + DBG("Observed: pci %llx phys %llx size
> > > > %x\n", pci_addr,
> > > > + cpu_phys_addr, size);
> > > > + } else {
> > > > + if (ranges32[i].pci_space == 0)
> > > > + continue;
> > > > +
> > > > + pci_space = (unsigned
> > > > int)ranges32[i].pci_space;
> > > > + pci_addr = (unsigned
> > > > int)ranges32[i].pci_addr[1];
> > > > + cpu_phys_addr = (unsigned
> > > > int)ranges32[i].phys_addr[0];
> > >
> > >
> > > We should really be using of_translate_address() in all cases -
> > > that's what it's for, after all.
> > >
> > being called, it gives 0 in 32bit branch of if () {. Since, iirc,
> > 32bit range parsing does not have it in original, variant,
> > I have it put as is. worths a brief investigation...
>
> Then we should fix of_translate_address() for 32-bit....
>
> I don't think this patch is actually required for the 44x pci support,
> yes? It might be better to leave this until later - it's only a tiny
> piece of all the consolidations we should do between ppc32 and ppc64
> PCI code. Currently there are a lot of silly, subtle differences
> between them :(.
Well, my point is:
- pci_32.c ranges parsing code is confusing and silly in many
ways
- there is no obvious way to enable 64bit phys addressed
handled correctly there.
possible approaches may bring more problems than solve.
- completely correct is going to be *hard* as David noted, but
we can consider effective merge(with code flow similar to existing funcs) of existing
bits a good starting point. Else, when a lot of stufpci_process_bridge_OF_rangesf would depend on
both functions, it would be too painful to rewrite.
(speaking about pci_process_bridge_OF_ranges here)
>
> > > > + size = ranges32[i].size[1];
> > > > +
> > > > + DBG("Observed: pci %x phys %x size
> > > > %x\n",
> > > > + (u32) pci_addr, (u32)
> > > > cpu_phys_addr, size);
> > > > + }
> > >
> > > You don't have any equivalent of the code that exists in both
> > > pre-existing versions to coalesce contiguous ranges. You probably
> > > want to use the 64-bit version, since that doesn't need a local
> > > copy of the ranges.
> > >
> > correct. yet, the whole aim of the upper seems to use summary size
> > of contiguous block and that's it.
> > How would we recognize IORESOURCE_PREFETCH then? (I know, my code
> > is missing that prefetch regions so far, but anyway).
> > >From the code, it seems to declare each resource that is part of
> > >contiguous block, with the size of entire block.
> >
> > That's prolly from binding, but can you please elaborate the logic
> > for better understanding?
>
> The attributes such as PREFETCH are encoded into cell 0 of the 3-cell
> OF PCI address. So, ranges with different attributes won't appear as
> contiguous in this space.
>
ok, I think there's no problem to implement it in the new func then.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Michel Dänzer @ 2007-08-27 8:37 UTC (permalink / raw)
To: Rogério Brito
Cc: Michal Piotrowski, Rogério Brito, linux-kernel,
Rafael J. Wysocki, linuxppc-dev, debian-powerpc,
Linux-pm mailing list
In-Reply-To: <20070827065246.GA21220@ime.usp.br>
On Mon, 2007-08-27 at 03:52 -0300, Rog=C3=A9rio Brito wrote:
>=20
> I did 13 compiles with git bisect and some of them were unsucessfuly
> compiled, which I am afraid that may miss the real cause if I tag them as
> being "bad" (which I did).
Yes, don't mark such cases as bad or good but look for a nearby commit
that compiles.
--=20
Earthling Michel D=C3=A4nzer | http://tungstengraphics.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* pata_mpc52xx - no interrupts when using bestcomm/dma?
From: Domen Puncer @ 2007-08-27 9:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I'm taking a stab at adding DMA support to pata_mpc52xx driver.
It's based on patches from Freescale's ltib (old ide driver).
The problem is that I can't seem to get any interrupts
(not ata, not bestcomm task), when setting up MWDMA/UDMA mode.
Ideas?
My current patch:
---
drivers/ata/pata_mpc52xx.c | 491 +++++++++++++++++++++++++++++++++++++++++++--
include/linux/libata.h | 2
2 files changed, 477 insertions(+), 16 deletions(-)
Index: work-powerpc.git/drivers/ata/pata_mpc52xx.c
===================================================================
--- work-powerpc.git.orig/drivers/ata/pata_mpc52xx.c
+++ work-powerpc.git/drivers/ata/pata_mpc52xx.c
@@ -4,6 +4,7 @@
* libata driver for the Freescale MPC52xx on-chip IDE interface
*
* Copyright (C) 2006 Sylvain Munaut <tnt@246tNt.com>
+ * Copyright (C) 2005,2006 Freescale - Bernard Kuhn, John Rigby
* Copyright (C) 2003 Mipsys - Benjamin Herrenschmidt
*
* This file is licensed under the terms of the GNU General Public License
@@ -22,6 +23,8 @@
#include <asm/of_platform.h>
#include <asm/mpc52xx.h>
+#include <sysdev/bestcomm/bestcomm.h>
+#include <sysdev/bestcomm/ata.h>
#define DRV_NAME "mpc52xx_ata"
#define DRV_VERSION "0.1.0ac2"
@@ -31,6 +34,14 @@
struct mpc52xx_ata_timings {
u32 pio1;
u32 pio2;
+ u32 mdma1;
+ u32 mdma2;
+ u32 udma1;
+ u32 udma2;
+ u32 udma3;
+ u32 udma4;
+ u32 udma5;
+ int using_udma;
};
struct mpc52xx_ata_priv {
@@ -39,6 +50,12 @@ struct mpc52xx_ata_priv {
int ata_irq;
struct mpc52xx_ata_timings timings[2];
int csel;
+
+ /* dma stuff follows */
+ struct bcom_task * dmatsk;
+ const struct udmaspec * udmaspec;
+ const struct mdmaspec * mdmaspec;
+ int mpc52xx_ata_dma_last_write;
};
@@ -53,6 +70,102 @@ static const int ataspec_ta[5] = { 35
#define CALC_CLKCYC(c,v) ((((v)+(c)-1)/(c)))
+/* ATAPI-4 MDMA specs (in clocks) */
+struct mdmaspec {
+ u32 t0M[3];
+ u32 td[3];
+ u32 th[3];
+ u32 tj[3];
+ u32 tkw[3];
+ u32 tm[3];
+ u32 tn[3];
+};
+
+// -----------------------------------------------------------------------------------------------
+
+static const struct mdmaspec mdmaspec66 = {
+ {32, 10, 8},
+ {15, 6, 5},
+ {2, 1, 1},
+ {2, 1, 1},
+ {15, 4, 2},
+ {4, 2, 2},
+ {1, 1, 1}
+};
+
+static const struct mdmaspec mdmaspec132 = {
+ {64, 20, 16},
+ {29, 11, 10},
+ {3, 2, 2},
+ {3, 1, 1},
+ {29, 7, 4},
+ {7, 4, 4},
+ {2, 1, 1}
+};
+
+
+/* ATAPI-4 UDMA specs (in clocks) */
+struct udmaspec {
+ u32 tcyc[6];
+ u32 t2cyc[6];
+ u32 tds[6];
+ u32 tdh[6];
+ u32 tdvs[6];
+ u32 tdvh[6];
+ u32 tfs_min[6];
+ u32 tli_max[6];
+ u32 tmli[6];
+ u32 taz[6];
+ u32 tzah[6];
+ u32 tenv_min[6];
+ u32 tsr[6];
+ u32 trfs[6];
+ u32 trp[6];
+ u32 tack[6];
+ u32 tss[6];
+};
+
+static const struct udmaspec udmaspec66 = {
+ { 8, 5, 4, 3, 2, 2},
+ {16, 11, 8, 6, 4 , 2},
+ { 1, 1, 1, 1, 1, 1},
+ { 1, 1, 1, 1, 1, 1},
+ { 5, 4, 3, 2, 1, 1},
+ { 1, 1, 1, 1, 1, 1},
+ {16, 14, 12, 9, 8, 6},
+ {10, 10, 10, 7, 8, 5},
+ { 2, 2, 2, 2, 2, 2},
+ { 1, 1, 1, 1, 1, 1},
+ { 2, 2, 2, 2, 2, 2},
+ { 2, 2, 2, 2, 2, 2},
+ { 3, 2, 2, 2, 2, 2},
+ { 5, 5, 4, 4, 4, 4},
+ {11, 9, 7, 7, 7, 6},
+ { 2, 2, 2, 2, 2, 2},
+ { 4, 4, 4, 4, 4, 4}
+};
+
+static const struct udmaspec udmaspec132 = {
+ {15, 10, 6, 7, 2, 3},
+ {31, 21, 12, 12, 5, 6},
+ { 2, 2, 1, 1, 0, 1},
+ { 1, 1, 1, 1, 0, 1},
+ {10, 7, 5, 3, 1, 1},
+ { 1, 1, 1, 1, 1, 1},
+ {30, 27, 23, 15, 16, 12},
+ {20, 20, 20, 13, 14, 10},
+ { 3, 3, 3, 3, 2, 3},
+ { 2, 2, 2, 2, 1, 2},
+ { 3, 3, 3, 3, 2, 3},
+ { 3, 3, 3, 3, 2, 3},
+ { 7, 4, 3, 3, 2, 3},
+ {10, 10, 8, 8, 7, 7},
+ {22, 17, 14, 14, 13, 12},
+ { 3, 3, 3, 3, 2, 3},
+ { 7, 7, 7, 7, 6, 7},
+};
+
+// -----------------------------------------------------------------------------------------------
/* Bit definitions inside the registers */
#define MPC52xx_ATA_HOSTCONF_SMR 0x80000000UL /* State machine reset */
@@ -76,6 +189,10 @@ static const int ataspec_ta[5] = { 35
#define MPC52xx_ATA_DMAMODE_HUT 0x40 /* Host UDMA burst terminate */
+#define MAX_DMA_BUFFERS 128
+#define MAX_DMA_BUFFER_SIZE 0x20000u
+
+
/* Structure of the hardware registers */
struct mpc52xx_ata {
@@ -141,6 +258,19 @@ struct mpc52xx_ata {
/* MPC52xx low level hw control */
+static inline void
+mpc52xx_ata_wait_tip_bit_clear(struct mpc52xx_ata __iomem *regs)
+{
+ int timeout = 1000;
+
+ while (in_be32(®s->host_status) & MPC52xx_ATA_HOSTSTAT_TIP)
+ if (timeout-- == 0) {
+ printk(KERN_ERR "mpc52xx-ide: Timeout waiting for TIP clear\n");
+ break;
+ }
+ udelay(10); /* FIXME: Necessary ??? */
+}
+
static int
mpc52xx_ata_compute_pio_timings(struct mpc52xx_ata_priv *priv, int dev, int pio)
{
@@ -165,6 +295,96 @@ mpc52xx_ata_compute_pio_timings(struct m
return 0;
}
+static int
+mpc52xx_ata_compute_mdma_timings(struct mpc52xx_ata_priv *priv, int dev, int speed)
+{
+ struct mpc52xx_ata_timings *timing = &priv->timings[dev];
+ u32 t0M, td, tkw, tm, th, tj, tn;
+
+ if (speed < 0 || speed > 2)
+ return -EINVAL;
+
+ t0M = priv->mdmaspec->t0M[speed];
+ td = priv->mdmaspec->td[speed];
+ tkw = priv->mdmaspec->tkw[speed];
+ tm = priv->mdmaspec->tm[speed];
+ th = priv->mdmaspec->th[speed];
+ tj = priv->mdmaspec->tj[speed];
+ tn = priv->mdmaspec->tn[speed];
+
+ /*
+ DPRINTK ("t0M = %d\n", t0M);
+ DPRINTK ("td = %d\n", td);
+ DPRINTK ("tkw = %d\n", tkw);
+ DPRINTK ("tm = %d\n", tm);
+ DPRINTK ("th = %d\n", th);
+ DPRINTK ("tj = %d\n", tj);
+ DPRINTK ("tn = %d\n", tn);
+ */
+ timing->mdma1 = (t0M << 24) | (td << 16) | (tkw << 8) | (tm);
+ timing->mdma2 = (th << 24) | (tj << 16) | (tn << 8);
+
+ timing->using_udma = 0;
+
+ return 0;
+}
+
+static int
+mpc52xx_ata_compute_udma_timings(struct mpc52xx_ata_priv *priv, int dev, int speed)
+{
+ struct mpc52xx_ata_timings *timing = &priv->timings[dev];
+ u32 t2cyc, tcyc, tds, tdh, tdvs, tdvh, tfs, tli, tmli, taz, tenv, tsr, tss, trfs, trp, tack, tzah;
+
+ if (speed < 0 || speed > 2)
+ return -EINVAL;
+
+ t2cyc = priv->udmaspec->t2cyc[speed];
+ tcyc = priv->udmaspec->tcyc[speed];
+ tds = priv->udmaspec->tds[speed];
+ tdh = priv->udmaspec->tdh[speed];
+ tdvs = priv->udmaspec->tdvs[speed];
+ tdvh = priv->udmaspec->tdvh[speed];
+ tfs = priv->udmaspec->tfs_min[speed];
+ tmli = priv->udmaspec->tmli[speed];
+ tenv = priv->udmaspec->tenv_min[speed];
+ tss = priv->udmaspec->tss[speed];
+ trp = priv->udmaspec->trp[speed];
+ tack = priv->udmaspec->tack[speed];
+ tzah = priv->udmaspec->tzah[speed];
+ taz = priv->udmaspec->taz[speed];
+ trfs = priv->udmaspec->trfs[speed];
+ tsr = priv->udmaspec->tsr[speed];
+ tli = priv->udmaspec->tli_max[speed];
+/*
+ DPRINTK ("UDMA t2cyc = %d\n", t2cyc);
+ DPRINTK ("UDMA tcyc = %d\n", tcyc);
+ DPRINTK ("UDMA tds = %d\n", tds);
+ DPRINTK ("UDMA tdh = %d\n", tdh);
+ DPRINTK ("UDMA tdvs = %d\n", tdvs);
+ DPRINTK ("UDMA tdvh = %d\n", tdvh);
+ DPRINTK ("UDMA tfs = %d\n", tfs);
+ DPRINTK ("UDMA tli = %d\n", tli);
+ DPRINTK ("UDMA tmli = %d\n", tmli);
+ DPRINTK ("UDMA taz = %d\n", taz);
+ DPRINTK ("UDMA tenv = %d\n", tenv);
+ DPRINTK ("UDMA tsr = %d\n", tsr);
+ DPRINTK ("UDMA tss = %d\n", tss);
+ DPRINTK ("UDMA trfs = %d\n", trfs);
+ DPRINTK ("UDMA trp = %d\n", trp);
+ DPRINTK ("UDMA tack = %d\n", tack);
+ DPRINTK ("UDMA tzah = %d\n", tzah);
+*/
+ timing->udma1 = (t2cyc << 24) | (tcyc << 16) | (tds << 8) | (tdh);
+ timing->udma2 = (tdvs << 24) | (tdvh << 16) | (tfs << 8) | (tli);
+ timing->udma3 = (tmli << 24) | (taz << 16) | (tenv << 8) | (tsr);
+ timing->udma4 = (tss << 24) | (trfs << 16) | (trp << 8) | (tack);
+ timing->udma5 = (tzah << 24);
+
+ timing->using_udma = 1;
+
+ return 0;
+}
+
static void
mpc52xx_ata_apply_timings(struct mpc52xx_ata_priv *priv, int device)
{
@@ -173,13 +393,13 @@ mpc52xx_ata_apply_timings(struct mpc52xx
out_be32(®s->pio1, timing->pio1);
out_be32(®s->pio2, timing->pio2);
- out_be32(®s->mdma1, 0);
- out_be32(®s->mdma2, 0);
- out_be32(®s->udma1, 0);
- out_be32(®s->udma2, 0);
- out_be32(®s->udma3, 0);
- out_be32(®s->udma4, 0);
- out_be32(®s->udma5, 0);
+ out_be32(®s->mdma1, timing->mdma1);
+ out_be32(®s->mdma2, timing->mdma2);
+ out_be32(®s->udma1, timing->udma1);
+ out_be32(®s->udma2, timing->udma2);
+ out_be32(®s->udma3, timing->udma3);
+ out_be32(®s->udma4, timing->udma4);
+ out_be32(®s->udma5, timing->udma5);
priv->csel = device;
}
@@ -234,6 +454,7 @@ mpc52xx_ata_set_piomode(struct ata_port
pio = adev->pio_mode - XFER_PIO_0;
+ // FIXME, can be called for dma mode?
rv = mpc52xx_ata_compute_pio_timings(priv, adev->devno, pio);
if (rv) {
@@ -245,6 +466,28 @@ mpc52xx_ata_set_piomode(struct ata_port
mpc52xx_ata_apply_timings(priv, adev->devno);
}
static void
+mpc52xx_ata_set_dmamode(struct ata_port *ap, struct ata_device *adev)
+{
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ int rv;
+
+ if (adev->dma_mode >= XFER_UDMA_0) {
+ int dma = adev->dma_mode - XFER_UDMA_0;
+ rv = mpc52xx_ata_compute_udma_timings(priv, adev->devno, dma);
+ } else {
+ int dma = adev->dma_mode - XFER_MW_DMA_0;
+ rv = mpc52xx_ata_compute_mdma_timings(priv, adev->devno, dma);
+ }
+
+ if (rv) {
+ printk(KERN_ERR DRV_NAME
+ ": Trying to select invalid DMA mode %d\n", adev->dma_mode);
+ return;
+ }
+
+ mpc52xx_ata_apply_timings(priv, adev->devno);
+}
+static void
mpc52xx_ata_dev_select(struct ata_port *ap, unsigned int device)
{
struct mpc52xx_ata_priv *priv = ap->host->private_data;
@@ -258,10 +501,174 @@ mpc52xx_ata_dev_select(struct ata_port *
static void
mpc52xx_ata_error_handler(struct ata_port *ap)
{
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+
+ printk(KERN_ALERT "%s: status: %08x; fifo_status_frame: %08x; fifo_status: %08x\n",
+ __func__, in_be32(®s->host_status),
+ in_be32(®s->fifo_status_frame),
+ in_be32(®s->fifo_status));
+
ata_bmdma_drive_eh(ap, ata_std_prereset, ata_std_softreset, NULL,
ata_std_postreset);
}
+static void
+mpc52xx_ata_exec_command(struct ata_port *ap, const struct ata_taskfile *tf)
+{
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+
+ mpc52xx_ata_wait_tip_bit_clear(priv->ata_regs);
+
+ ata_exec_command(ap, tf);
+}
+
+static int
+mpc52xx_ata_build_dmatable(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+ struct scatterlist *sg;
+ unsigned int read = !(qc->tf.flags & ATA_TFLAG_WRITE);
+ int count = 0;
+
+ if (read)
+ bcom_ata_rx_prepare(priv->dmatsk);
+ else
+ bcom_ata_tx_prepare(priv->dmatsk);
+
+
+ ata_for_each_sg(sg, qc) {
+ u32 cur_addr = sg_dma_address(sg);
+ u32 cur_len = sg_dma_len(sg);
+
+ while (cur_len) {
+ unsigned int tc = min(cur_len, MAX_DMA_BUFFER_SIZE);
+ struct bcom_ata_bd *bd;
+
+ bd = (struct bcom_ata_bd *)
+ bcom_prepare_next_buffer(priv->dmatsk);
+
+ if (read) {
+ bd->status = tc;
+ bd->dst_pa = cur_addr;
+ bd->src_pa = (__force u32)®s->fifo_data; // virt_to_phys?
+ } else {
+ bd->status = tc;
+ bd->dst_pa = (__force u32)®s->fifo_data; // virt_to_phys?
+ bd->src_pa = cur_addr;
+
+ /* and how does bestcomm know to increase one, and not other?
+ * XXX TODO */
+ }
+
+ bcom_submit_next_buffer(priv->dmatsk, phys_to_virt(cur_addr)); // qc is just a cookie
+
+ cur_addr += tc;
+ cur_len -= tc;
+ count++;
+
+ if (count == MAX_DMA_BUFFERS) {
+ printk(KERN_ALERT "%s: %i dma table too small\n",
+ __func__, __LINE__);
+ goto use_pio_instead;
+ }
+ }
+ }
+ return 1;
+
+ use_pio_instead:
+ bcom_ata_reset_bd(priv->dmatsk);
+ //pci_unmap_sg ???
+
+ return 0;
+}
+
+static void
+mpc52xx_bmdma_setup(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+ unsigned int read = !(qc->tf.flags & ATA_TFLAG_WRITE);
+ u8 dma_mode;
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+
+ if (!mpc52xx_ata_build_dmatable(qc)) {
+ //ide_map_sg(drive, rq);
+ printk(KERN_ALERT "%s: %i, return 1?\n", __func__, __LINE__);
+ }
+
+ if (read) {
+ dma_mode = MPC52xx_ATA_DMAMODE_IE | MPC52xx_ATA_DMAMODE_READ |
+ MPC52xx_ATA_DMAMODE_FE;
+
+ /* Setup FIFO if direction changed */
+ if (priv->mpc52xx_ata_dma_last_write) {
+ priv->mpc52xx_ata_dma_last_write = 0;
+ mpc52xx_ata_wait_tip_bit_clear(regs);
+ out_8(®s->dma_mode, MPC52xx_ATA_DMAMODE_FR);
+ /* Configure it with granularity to 7 like sample code */
+ out_8(®s->fifo_control, 7);
+ out_be16(®s->fifo_alarm, 128);
+ }
+ } else {
+ dma_mode = MPC52xx_ATA_DMAMODE_IE | MPC52xx_ATA_DMAMODE_WRITE;
+
+ /* Setup FIFO if direction changed */
+ if (!priv->mpc52xx_ata_dma_last_write) {
+ priv->mpc52xx_ata_dma_last_write = 1;
+ mpc52xx_ata_wait_tip_bit_clear(regs);
+ /* Configure FIFO with granularity to 4 like sample code */
+ out_8(®s->fifo_control, 4);
+ //out_be16(®s->fifo_alarm, 256);
+ out_be16(®s->fifo_alarm, 128);
+ }
+ }
+
+ if (priv->timings[qc->dev->devno].using_udma)
+ dma_mode |= MPC52xx_ATA_DMAMODE_UDMA;
+
+ mpc52xx_ata_wait_tip_bit_clear(regs);
+ out_8(®s->dma_mode, dma_mode);
+
+ ap->ops->exec_command(ap, &qc->tf); // added, ata_bmdma_setup has it
+}
+
+static void
+mpc52xx_bmdma_start(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+
+ //xlb_clear(); // WTF
+ bcom_enable(priv->dmatsk);
+}
+
+static void
+mpc52xx_bmdma_stop(struct ata_queued_cmd *qc)
+{
+ // uh? looks like destructor for setup not start
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+
+ bcom_disable(priv->dmatsk);
+ //bcom_clear_irq(priv->dmatsk); //!!
+ bcom_ata_reset_bd(priv->dmatsk);
+
+ // mpc52xx_ata_destroy_dmatable();
+}
+// waiting_for_dma eliminated
+
+static u8
+mpc52xx_bmdma_status(struct ata_port *ap)
+{
+printk(KERN_ALERT "%s: %i TODO\n", __func__, __LINE__);
+ return 0;
+}
static struct scsi_host_template mpc52xx_ata_sht = {
@@ -282,25 +689,47 @@ static struct scsi_host_template mpc52xx
.bios_param = ata_std_bios_param,
};
+static void mpc52xx_ata_bmdma_freeze(struct ata_port *ap)
+{
+ printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+ ata_bmdma_freeze(ap);
+}
+static void mpc52xx_ata_bmdma_thaw(struct ata_port *ap)
+{
+ printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+ ata_bmdma_thaw(ap);
+}
+static void ata_dummy_noret(struct ata_port *ap)
+{
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+}
static struct ata_port_operations mpc52xx_ata_port_ops = {
.port_disable = ata_port_disable,
.set_piomode = mpc52xx_ata_set_piomode,
+ .set_dmamode = mpc52xx_ata_set_dmamode,
.dev_select = mpc52xx_ata_dev_select,
.tf_load = ata_tf_load,
.tf_read = ata_tf_read,
.check_status = ata_check_status,
- .exec_command = ata_exec_command,
- .freeze = ata_bmdma_freeze,
- .thaw = ata_bmdma_thaw,
+ .exec_command = mpc52xx_ata_exec_command,
+ .freeze = mpc52xx_ata_bmdma_freeze,
+ .thaw = mpc52xx_ata_bmdma_thaw,
.error_handler = mpc52xx_ata_error_handler,
.cable_detect = ata_cable_40wire,
.qc_prep = ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
.data_xfer = ata_data_xfer,
- .irq_clear = ata_bmdma_irq_clear,
+// .irq_clear = ata_bmdma_irq_clear,
+ .irq_clear = ata_dummy_noret,
.irq_on = ata_irq_on,
.irq_ack = ata_irq_ack,
.port_start = ata_port_start,
+ .bmdma_setup = mpc52xx_bmdma_setup,
+ .bmdma_start = mpc52xx_bmdma_start,
+ .bmdma_stop = mpc52xx_bmdma_stop,
+ .bmdma_status = mpc52xx_bmdma_status,
+
+// not ide_dma_check int (*check_atapi_dma) (struct ata_queued_cmd *qc);
};
static int __devinit
@@ -309,7 +738,6 @@ mpc52xx_ata_init_one(struct device *dev,
struct ata_host *host;
struct ata_port *ap;
struct ata_ioports *aio;
- int rc;
host = ata_host_alloc(dev, 1);
if (!host)
@@ -317,9 +745,9 @@ mpc52xx_ata_init_one(struct device *dev,
ap = host->ports[0];
ap->flags |= ATA_FLAG_SLAVE_POSS;
- ap->pio_mask = 0x1f; /* Up to PIO4 */
- ap->mwdma_mask = 0x00; /* No MWDMA */
- ap->udma_mask = 0x00; /* No UDMA */
+ ap->pio_mask = ATA_PIO4; /* Up to PIO4 */
+ ap->mwdma_mask = 0x07; /* Up to MWDMA2 */
+ ap->udma_mask = ATA_UDMA2; /* Up to UDMA2 */
ap->ops = &mpc52xx_ata_port_ops;
host->private_data = priv;
@@ -359,6 +787,15 @@ mpc52xx_ata_remove_one(struct device *de
/* OF Platform driver */
/* ======================================================================== */
+static irqreturn_t
+mpc52xx_ata_task_irq(int irq, void *vpriv)
+{
+ struct mpc52xx_ata_priv *priv = vpriv;
+printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+
+ return IRQ_HANDLED;
+}
+
static int __devinit
mpc52xx_ata_probe(struct of_device *op, const struct of_device_id *match)
{
@@ -426,6 +863,30 @@ mpc52xx_ata_probe(struct of_device *op,
priv->ata_irq = ata_irq;
priv->csel = -1;
+ if (ipb_freq/1000000 == 66) {
+ priv->mdmaspec = &mdmaspec66;
+ priv->udmaspec = &udmaspec66;
+ } else {
+ priv->mdmaspec = &mdmaspec132;
+ priv->udmaspec = &udmaspec132;
+ }
+
+ priv->dmatsk = bcom_ata_init(MAX_DMA_BUFFERS, MAX_DMA_BUFFER_SIZE);
+ if (!priv->dmatsk) {
+ printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+ rv = -ENOMEM;
+ goto err;
+ }
+ // XXX task irq? nope, it doesn't get any irq's
+ {
+ int ret;
+ int task_irq = bcom_get_task_irq(priv->dmatsk);
+ printk(KERN_ALERT "%s: ata task irq: %i\n", __func__, task_irq);
+ ret = request_irq(task_irq, &mpc52xx_ata_task_irq, IRQF_DISABLED, "ata task", priv);
+ if (ret)
+ printk(KERN_ALERT "%s: request_irq failed with: %i\n", __func__, ret);
+ }
+
/* Init the hw */
rv = mpc52xx_ata_hw_init(priv);
if (rv) {
Index: work-powerpc.git/include/linux/libata.h
===================================================================
--- work-powerpc.git.orig/include/linux/libata.h
+++ work-powerpc.git/include/linux/libata.h
@@ -51,7 +51,7 @@
* compile-time options: to be removed as soon as all the drivers are
* converted to the new debugging mechanism
*/
-#undef ATA_DEBUG /* debugging output */
+#define ATA_DEBUG /* debugging output */
#undef ATA_VERBOSE_DEBUG /* yet more debugging output */
#undef ATA_IRQ_TRAP /* define to ack screaming irqs */
#undef ATA_NDEBUG /* define to disable quick runtime checks */
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-27 9:47 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070826.185815.93042514.davem@davemloft.net>
On Monday 27 August 2007 03:58, David Miller wrote:
> From: James Chapman <jchapman@katalix.com>
> Date: Sun, 26 Aug 2007 20:36:20 +0100
>
> > David Miller wrote:
> > > From: James Chapman <jchapman@katalix.com>
> > > Date: Fri, 24 Aug 2007 18:16:45 +0100
> > >
> > >> Does hardware interrupt mitigation really interact well with NAPI?
> > >
> > > It interacts quite excellently.
> >
> > If NAPI disables interrupts and keeps them disabled while there are more
> > packets arriving or more transmits being completed, why do hardware
> > interrupt mitigation / coalescing features of the network silicon help?
>
> Because if your packet rate is low enough such that the cpu can
> process the interrupt fast enough and thus only one packet gets
> processed per NAPI poll, the cost of going into and out of NAPI mode
> dominates the packet processing costs.
As far as I understand your argumentation, NAPI is supposed to work well only
for HW with coalescing features (concerning dropping the interrupt rate).
NAPI itself does not provide a reliable functionality to reduce the
number of interrupts, especially not for systems with only 1 NIC.
NAPI will only wait for some time when the budget is exceeded
and the softIRQs don't call net_rx_action again. This seems to be the case
after 10 rounds. That means NAPI really waits after 300 x 10 packets
have been processed in a row (worst case).
As a matter of fact there is HW that does not have this feature. There seems
to be HW which does not work well with plain NAPI.
This HW performs well if the operation system supports HP timers
(and when they are used either in the device driver or polling engine).
So the question is simply: Do we want drivers that need (benefit from)
a timer based polling support to implement their own timers each,
or should there be a generic support?
Thanks,
Jan-Bernd
^ permalink raw reply
* how to debug the linux kernel with a BDI2000
From: jxnuxdy @ 2007-08-27 9:51 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
My kernel hanged in when passed the parameters to it, and I dump nothing from the log_buf, so I guss it is crashed at the very beginning. however I didn't know how to setup the KDB to load the kernel with the BDI2000 ethernet? is there anyone has even loaded and debugged the kernel with the BDI2000 ethernet? if so pls show me how it goes? ,Thanks- Denny
[-- Attachment #2: Type: text/html, Size: 794 bytes --]
^ permalink raw reply
* RE: STK5200 pci_enable_device problem
From: Mustafa Cayir @ 2007-08-27 11:08 UTC (permalink / raw)
To: Oliver Rutsch, linuxppc-embedded
In-Reply-To: <46CD3618.70801@sympatec.com>
[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]
Hi ,
i use 2.4.25 kernel and eldk 3.1.1 on TQM5200 board. i tried denx 2.6.19 kernel to port on TQM5200 but i couldn't.
Did you port 2.6 kernel on TQM5200? Did pci device start working succesfully after porting 2.6 kernel to TQM5200 board.
-----Original Message-----
From: linuxppc-embedded-bounces+mustafa.cayir=bte.mam.gov.tr@ozlabs.org on behalf of Oliver Rutsch
Sent: Thu 8/23/2007 10:24 AM
To: linuxppc-embedded@ozlabs.org
Subject: Re: STK5200 pci_enable_device problem
Hi Mustafa,
> Hi all,
>
[...]
>
> My pci driver is able to scan pci bus and find succesfully the pci
> device. After this point, pci_enable_device function returns
> following error:
>
> PCI: Device 00:18.0 not available because of resource collisions
>
Which ELDK and kernel do you use? I had the same problem on this board
with a PLX9054 based PCI card on a 2.4.25 kernel. I switched to the 2.6
kernel and the 4.1 ELDK and the card was scanned correctly.
But keep in mind that the linux PLX drivers do not work out of the box
with a big endian platform like the MPC5200. Although there is a
BIG_ENDIAN flag in the makefiles there are still some places left in the
driver code which have to be patched (the parts with int64 adresses).
It's not so easy to compile the PLX drivers on the 4.1 ELDK because of
missing headers in the ppc architecture. I managed to build the drivers
for the 2.6.19 kernel and I was able to work with the card except the
DMA routines (still working on this issue).
Hope this helps. Bye,
--
Dipl. Ing. Oliver Rutsch
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 2411 bytes --]
^ permalink raw reply
* MDIO bus hotplug
From: DI BACCO ANTONIO - technolabs @ 2007-08-27 11:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
Hi,
I have an hot pluggable MDIO bus (connected to MDC, MDIO of an MPC880)
and thus I would like to rescan the bus on certain events (for example
fs_enet_open) to access the numerous PHYs I have on this bus. I saw that
it is "simply" a matter of calling mdiobus_register but I would like an
advice how to design the modification
MPC880 with linux-2.6.19.2
Best regards,
Antonio.
[-- Attachment #2: Type: text/html, Size: 1414 bytes --]
^ permalink raw reply
* Re: [PATCH, RFC] linkstation: implement standby
From: Johannes Berg @ 2007-08-27 11:32 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-pm
In-Reply-To: <Pine.LNX.4.60.0708260157330.3809@poirot.grange>
[-- Attachment #1: Type: text/plain, Size: 158 bytes --]
On Sun, 2007-08-26 at 02:03 +0200, Guennadi Liakhovetski wrote:
> +#ifdef CONFIG_PM
some of those probably want to be CONFIG_PM_SLEEP now.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-27 12:55 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
im a student from germany and i try to run linux on a virtex-II with
integrated powerpc.
i use the developer board DS-DB-2VP4/7-FG456 from Memec ( i think its
now avnet)
i hope my questions are not too stupid :-)
what is running :
- Xilinx EDK project (standalone program running fine, and BSP files
are generated)
the project has only one UARTLITE, 82MB SDRAM and a few kByte
blockram, and the systemace interface
- crosscompiler toolchain works
- after modified some defines in the xparameters.h i got a linux 2.4.
kernel (linuxppc) without compiler errors
and yes, the uartlite driver is enabled :)
but, when downloading the zImage.elf via XMD to the SDRAM and starting
it with the run command nothing happens , or i think that nothings
happens because the serial port is quiet.
is it possible to run a kernel that way ? or need i some kind of
bootloader ?
or is this complete the wrong way ?
Regards
Georg
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-27 13:09 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <46D2C9A5.9030708@fz-juelich.de>
On 8/27/07, schardt <g.schardt@fz-juelich.de> wrote:
> im a student from germany and i try to run linux on a virtex-II with
> integrated powerpc.
> i use the developer board DS-DB-2VP4/7-FG456 from Memec ( i think its
> now avnet)
>
> what is running :
>
> - Xilinx EDK project (standalone program running fine, and BSP files
> are generated)
> the project has only one UARTLITE, 82MB SDRAM and a few kByte
> blockram, and the systemace interface
>
> - crosscompiler toolchain works
>
> - after modified some defines in the xparameters.h i got a linux 2.4.
> kernel (linuxppc) without compiler errors
I strongly recommend trying to bring up a 2.6 kernel, it's much easier.
> and yes, the uartlite driver is enabled :)
Don't modify xparams by hand; it's not worth the trouble. Go into
software setting in your EDK project and select 'linux-2.6' as the OS.
Generate the libraries and copy the generated xparameters_ml40x.h
into your kernel tree.
>
>
> but, when downloading the zImage.elf via XMD to the SDRAM and starting
> it with the run command nothing happens , or i think that nothings
> happens because the serial port is quiet.
You can always use System.map in the kernel tree to find out where
__log_buf was linked to. Look at that location with the debugger to
see if there is a crash message that didn't get printed out.
>
> is it possible to run a kernel that way ? or need i some kind of
> bootloader ?
> or is this complete the wrong way ?
Yes, I use this same method to bring up a kernel on Virtex boards
which don't have a bootloader.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Linux doesn not boot from u-boot on ML403
From: Mirek23 @ 2007-08-27 13:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I run Linux 2.6.21 (by Grant) on my Avnet Virtex-4 evaluation board
(ML403 like). When I load zIinux.elf
via jtag to the board it runs properly:
loaded at: 00400000 004F9138
board data at: 004F7120 004F7138
relocated to: 004040B4 004040CC
zimage at: 00404E59 004F6EE6
avail ram: 004FA000 01FFFFFF
Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...done.
Now booting the kernel
[0.000000] Linux version 2.6.21-rc6 (root@pc5215) (gcc version 4.0.2) #11
Tue Aug 7 13:46:19 EST 2007
[0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
.
.
.
.
It goes to the successful end.
I have build u-boot 1.2.0 with uart lite and temac support.
When I am trying to run uImage (build out of zImage) it does not run.
The steps I do are as following:
1. I build uImage withing the kernel tree (make uImage)
2. I load via jtag the u-boot 1.2.0
XMD% dow u-boot.elf
section, .text: 0x00800000-0x0081513c
section, .resetvec: 0x0081513c-0x00815140
section, .rodata: 0x00815140-0x00817ce0
section, .reloc: 0x00817d00-0x00818674
section, .data: 0x00818674-0x00818b08
section, .data.rel: 0x00818b08-0x00818b34
section, .data.rel.local: 0x00818b34-0x00818f6c
section, .u_boot_cmd: 0x00818f6c-0x008191dc
section, .bss: 0x00819200-0x0081dd04
3. I transfer uImage to the RAM memory of my Avnet board:
TFTP from server 129.129.144.113; our IP address is 129.129.144.157
Filename 'uImage'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
################################################################
done
Bytes transferred = 991438 (f20ce hex)
4. I am trying to start the kernel
=> bootm 0x1000000
## Booting image at 01000000 ...
Image Name: Linux-2.6.21-rc6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 991375 Bytes = 968.1 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
After all system hangs
I have tried to change the Load Address and Entry Point to 0x400000 (mkimage
-a 0x400000 -e 0x400000)
but the system hangs like in the first case.
my bootargs are:
console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Those bootargs where tested with zImage.elf and seem to be fine.
Does somebody has some suggestion?
Thank you in advance for any hint on that.
Mirek
--
View this message in context: http://www.nabble.com/Linux-doesn-not-boot-from-u-boot-on-ML403-tf4335322.html#a12347049
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: Newbie and linux on virtex-II ppc
From: Ming Liu @ 2007-08-27 13:54 UTC (permalink / raw)
To: g.schardt, linuxppc-embedded
In-Reply-To: <46D2C9A5.9030708@fz-juelich.de>
Dear Georg,
>is it possible to run a kernel that way ? or need i some kind of
>bootloader ?
>or is this complete the wrong way ?
Yes, you can. Actually what I did is to include a bootloop in the hardware
bitstream and that will keep your CPU waiting until the kernel's running.
BR
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Broadcom HT1000/HT2000 or HT1100 support in IBM PowerPC 970MP/Fx
From: Ashok Hegde @ 2007-08-27 14:06 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
Hi All,
Is any of these broadcom HT1000/HT2000/HT1100 chipsets supported with IBM
970MP/FX?
Could please anyone provide me the Linux kernel link for product with this
combination (IBM 970MP/FX + HT1000/HT2000/HT1100)?
I could able to locate "tetrapower" but not able to get more info on Linux
front.
Thanks in advance.
Regards,
Ashok
[-- Attachment #2: Type: text/html, Size: 3126 bytes --]
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-27 14:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40708270609x453092eye6eaf83b65ac2dee@mail.gmail.com>
Grant Likely wrote:
> On 8/27/07, schardt <g.schardt@fz-juelich.de> wrote:
>
>> im a student from germany and i try to run linux on a virtex-II with
>> integrated powerpc.
>> i use the developer board DS-DB-2VP4/7-FG456 from Memec ( i think its
>> now avnet)
>>
>> what is running :
>>
>> - Xilinx EDK project (standalone program running fine, and BSP files
>> are generated)
>> the project has only one UARTLITE, 82MB SDRAM and a few kByte
>> blockram, and the systemace interface
>>
>> - crosscompiler toolchain works
>>
>> - after modified some defines in the xparameters.h i got a linux 2.4.
>> kernel (linuxppc) without compiler errors
>>
>
> I strongly recommend trying to bring up a 2.6 kernel, it's much easier.
>
okay, i'll try it :)
>
>> and yes, the uartlite driver is enabled :)
>>
>
> Don't modify xparams by hand; it's not worth the trouble. Go into
> software setting in your EDK project and select 'linux-2.6' as the OS.
> Generate the libraries and copy the generated xparameters_ml40x.h
> into your kernel tree.
>
>
i dont have this option. do i need a update ?
G
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-27 14:21 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <46D2DCFC.40401@fz-juelich.de>
On 8/27/07, schardt <g.schardt@fz-juelich.de> wrote:
> > Don't modify xparams by hand; it's not worth the trouble. Go into
> > software setting in your EDK project and select 'linux-2.6' as the OS.
> > Generate the libraries and copy the generated xparameters_ml40x.h
> > into your kernel tree.
> >
> >
> i dont have this option. do i need a update ?
Probably, but you can use the montavista 2.4 option also. You're only
interested in the xparameters.h file, not the whole BSP. (Letting EDK
generate files into your kernel tree is scary)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-08-27 14:24 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <12347049.post@talk.nabble.com>
On 8/27/07, Mirek23 <miroslaw.dach@psi.ch> wrote:
> 4. I am trying to start the kernel
>
> => bootm 0x1000000
>
> ## Booting image at 01000000 ...
> Image Name: Linux-2.6.21-rc6
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 991375 Bytes = 968.1 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
Have you looked in __log_buf for kernel messages?
What does your u-boot env look like?
Do you have 'console=ttyUL0' or 'console=ttyS0' in the kernel command line?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Broadcom HT1000/HT2000 or HT1100 support in IBM PowerPC 970MP/Fx
From: Benjamin Herrenschmidt @ 2007-08-27 14:33 UTC (permalink / raw)
To: Ashok Hegde; +Cc: linuxppc-embedded
In-Reply-To: <52C5E6AE59DB984B9ECCBCADFE1C5E15050DABBB@BNGWNEXC0001.bng.slr.com>
On Mon, 2007-08-27 at 19:36 +0530, Ashok Hegde wrote:
> Hi All,
>
>
>
> Is any of these broadcom HT1000/HT2000/HT1100 chipsets supported with
> IBM 970MP/FX?
>
> Could please anyone provide me the Linux kernel link for product with
> this combination (IBM 970MP/FX + HT1000/HT2000/HT1100)?
You can't plug one of these directly onto a 970, you need a northbridge
first, such as IBM CPC945 :-) But then, yes, those work fine behind that
bridge. Apple and IBM both used these on 970 + CPC945/U4 based products.
Ben.
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-27 14:36 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708270724r3d1a3bd3jccbc161475e93343@mail.gmail.com>
Hi Grant,
Thank you for your response.
My u-boot bootargs is set to:
console=ttyUL0,9600 root=/dev/nfs rw nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp ip=::::virtex4-mirek:eth0:dhcp panic=1
where I can find __log_buf for kernel messages?
Best Regards
Mirek
On Mon, 27 Aug 2007, Grant Likely wrote:
> On 8/27/07, Mirek23 <miroslaw.dach@psi.ch> wrote:
> > 4. I am trying to start the kernel
> >
> > => bootm 0x1000000
> >
> > ## Booting image at 01000000 ...
> > Image Name: Linux-2.6.21-rc6
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 991375 Bytes = 968.1 kB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
>
> Have you looked in __log_buf for kernel messages?
> What does your u-boot env look like?
> Do you have 'console=ttyUL0' or 'console=ttyS0' in the kernel command line?
>
> Cheers,
> g.
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ permalink raw reply
* RFC: [PATCH] Copy over headers from arch/powerpc to arch/ppc to decouple them
From: Kumar Gala @ 2007-08-27 14:49 UTC (permalink / raw)
To: linuxppc-dev
Move over includes files that have CONFIG_PPC_MERGE in them to decouple
to interdepencies between ARCH=powerpc & ARCH=ppc.
Duplicate the following headers in both locations and remove CONFIG_PPC_MERGE:
<asm/dcr.h>
<asm/i8259.h>
<asm/ipic.h>
<asm/irq.h>
---
Not sure what people think about this since removing include asm-powerpc
from ARCH=ppc builds will require a bunch of other copies beyond these
which had a CONFIG_PPC_MERGE in them.
arch/powerpc/sysdev/dcr.c | 2 +
include/asm-powerpc/dcr.h | 7 -
include/asm-powerpc/i8259.h | 5 -
include/asm-powerpc/ipic.h | 8 -
include/asm-powerpc/irq.h | 500 --------------------------------------
include/asm-ppc/dcr-native.h | 72 ++++++
include/asm-ppc/dcr.h | 31 +++
include/asm-ppc/i8259.h | 11 +
include/asm-ppc/ipic.h | 85 +++++++
include/asm-ppc/irq.h | 549 ++++++++++++++++++++++++++++++++++++++++++
10 files changed, 750 insertions(+), 520 deletions(-)
create mode 100644 include/asm-ppc/dcr-native.h
create mode 100644 include/asm-ppc/dcr.h
create mode 100644 include/asm-ppc/i8259.h
create mode 100644 include/asm-ppc/ipic.h
create mode 100644 include/asm-ppc/irq.h
Removed new file creation (since they duplicate the include/asm-powerpc
version, with CONFIG_PPC_MERGE folded out).
diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
index e82d54d..c61557c 100644
--- a/arch/powerpc/sysdev/dcr.c
+++ b/arch/powerpc/sysdev/dcr.c
@@ -23,6 +23,7 @@
#include <asm/prom.h>
#include <asm/dcr.h>
+#ifdef CONFIG_PPC_MERGE
unsigned int dcr_resource_start(struct device_node *np, unsigned int index)
{
unsigned int ds;
@@ -46,6 +47,7 @@ unsigned int dcr_resource_len(struct device_node *np, unsigned int index)
return dr[index * 2 + 1];
}
EXPORT_SYMBOL_GPL(dcr_resource_len);
+#endif
#ifndef CONFIG_PPC_DCR_NATIVE
diff --git a/include/asm-powerpc/dcr.h b/include/asm-powerpc/dcr.h
index 9338d50..2565674 100644
--- a/include/asm-powerpc/dcr.h
+++ b/include/asm-powerpc/dcr.h
@@ -28,18 +28,11 @@
#include <asm/dcr-mmio.h>
#endif
-/*
- * On CONFIG_PPC_MERGE, we have additional helpers to read the DCR
- * base from the device-tree
- */
-#ifdef CONFIG_PPC_MERGE
struct device_node;
extern unsigned int dcr_resource_start(struct device_node *np,
unsigned int index);
extern unsigned int dcr_resource_len(struct device_node *np,
unsigned int index);
-#endif /* CONFIG_PPC_MERGE */
-
#endif /* CONFIG_PPC_DCR */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DCR_H */
diff --git a/include/asm-powerpc/i8259.h b/include/asm-powerpc/i8259.h
index db1362f..105ade2 100644
--- a/include/asm-powerpc/i8259.h
+++ b/include/asm-powerpc/i8259.h
@@ -4,14 +4,9 @@
#include <linux/irq.h>
-#ifdef CONFIG_PPC_MERGE
extern void i8259_init(struct device_node *node, unsigned long intack_addr);
extern unsigned int i8259_irq(void);
extern struct irq_host *i8259_get_host(void);
-#else
-extern void i8259_init(unsigned long intack_addr, int offset);
-extern int i8259_irq(void);
-#endif
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_I8259_H */
diff --git a/include/asm-powerpc/ipic.h b/include/asm-powerpc/ipic.h
index edec79d..263aeec 100644
--- a/include/asm-powerpc/ipic.h
+++ b/include/asm-powerpc/ipic.h
@@ -76,16 +76,8 @@ extern void ipic_enable_mcp(enum ipic_mcp_irq mcp_irq);
extern void ipic_disable_mcp(enum ipic_mcp_irq mcp_irq);
extern u32 ipic_get_mcp_status(void);
extern void ipic_clear_mcp_status(u32 mask);
-
-#ifdef CONFIG_PPC_MERGE
extern struct ipic * ipic_init(struct device_node *node, unsigned int flags);
extern unsigned int ipic_get_irq(void);
-#else
-extern void ipic_init(phys_addr_t phys_addr, unsigned int flags,
- unsigned int irq_offset,
- unsigned char *senses, unsigned int senses_count);
-extern int ipic_get_irq(void);
-#endif
#endif /* __ASM_IPIC_H__ */
#endif /* __KERNEL__ */
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index 0485c53..1c16e47 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -25,8 +25,6 @@
extern atomic_t ppc_n_lost_interrupts;
-#ifdef CONFIG_PPC_MERGE
-
/* This number is used when no interrupt has been assigned */
#define NO_IRQ (0)
@@ -322,504 +320,6 @@ static __inline__ int irq_canonicalize(int irq)
return irq;
}
-
-#else /* CONFIG_PPC_MERGE */
-
-/* This number is used when no interrupt has been assigned */
-#define NO_IRQ (-1)
-#define NO_IRQ_IGNORE (-2)
-
-
-/*
- * These constants are used for passing information about interrupt
- * signal polarity and level/edge sensing to the low-level PIC chip
- * drivers.
- */
-#define IRQ_SENSE_MASK 0x1
-#define IRQ_SENSE_LEVEL 0x1 /* interrupt on active level */
-#define IRQ_SENSE_EDGE 0x0 /* interrupt triggered by edge */
-
-#define IRQ_POLARITY_MASK 0x2
-#define IRQ_POLARITY_POSITIVE 0x2 /* high level or low->high edge */
-#define IRQ_POLARITY_NEGATIVE 0x0 /* low level or high->low edge */
-
-
-#if defined(CONFIG_40x)
-#include <asm/ibm4xx.h>
-
-#ifndef NR_BOARD_IRQS
-#define NR_BOARD_IRQS 0
-#endif
-
-#ifndef UIC_WIDTH /* Number of interrupts per device */
-#define UIC_WIDTH 32
-#endif
-
-#ifndef NR_UICS /* number of UIC devices */
-#define NR_UICS 1
-#endif
-
-#if defined (CONFIG_403)
-/*
- * The PowerPC 403 cores' Asynchronous Interrupt Controller (AIC) has
- * 32 possible interrupts, a majority of which are not implemented on
- * all cores. There are six configurable, external interrupt pins and
- * there are eight internal interrupts for the on-chip serial port
- * (SPU), DMA controller, and JTAG controller.
- *
- */
-
-#define NR_AIC_IRQS 32
-#define NR_IRQS (NR_AIC_IRQS + NR_BOARD_IRQS)
-
-#elif !defined (CONFIG_403)
-
-/*
- * The PowerPC 405 cores' Universal Interrupt Controller (UIC) has 32
- * possible interrupts as well. There are seven, configurable external
- * interrupt pins and there are 17 internal interrupts for the on-chip
- * serial port, DMA controller, on-chip Ethernet controller, PCI, etc.
- *
- */
-
-
-#define NR_UIC_IRQS UIC_WIDTH
-#define NR_IRQS ((NR_UIC_IRQS * NR_UICS) + NR_BOARD_IRQS)
-#endif
-
-#elif defined(CONFIG_44x)
-#include <asm/ibm44x.h>
-
-#define NR_UIC_IRQS 32
-#define NR_IRQS ((NR_UIC_IRQS * NR_UICS) + NR_BOARD_IRQS)
-
-#elif defined(CONFIG_8xx)
-
-/* Now include the board configuration specific associations.
-*/
-#include <asm/mpc8xx.h>
-
-/* The MPC8xx cores have 16 possible interrupts. There are eight
- * possible level sensitive interrupts assigned and generated internally
- * from such devices as CPM, PCMCIA, RTC, PIT, TimeBase and Decrementer.
- * There are eight external interrupts (IRQs) that can be configured
- * as either level or edge sensitive.
- *
- * On some implementations, there is also the possibility of an 8259
- * through the PCI and PCI-ISA bridges.
- *
- * We are "flattening" the interrupt vectors of the cascaded CPM
- * and 8259 interrupt controllers so that we can uniquely identify
- * any interrupt source with a single integer.
- */
-#define NR_SIU_INTS 16
-#define NR_CPM_INTS 32
-#ifndef NR_8259_INTS
-#define NR_8259_INTS 0
-#endif
-
-#define SIU_IRQ_OFFSET 0
-#define CPM_IRQ_OFFSET (SIU_IRQ_OFFSET + NR_SIU_INTS)
-#define I8259_IRQ_OFFSET (CPM_IRQ_OFFSET + NR_CPM_INTS)
-
-#define NR_IRQS (NR_SIU_INTS + NR_CPM_INTS + NR_8259_INTS)
-
-/* These values must be zero-based and map 1:1 with the SIU configuration.
- * They are used throughout the 8xx I/O subsystem to generate
- * interrupt masks, flags, and other control patterns. This is why the
- * current kernel assumption of the 8259 as the base controller is such
- * a pain in the butt.
- */
-#define SIU_IRQ0 (0) /* Highest priority */
-#define SIU_LEVEL0 (1)
-#define SIU_IRQ1 (2)
-#define SIU_LEVEL1 (3)
-#define SIU_IRQ2 (4)
-#define SIU_LEVEL2 (5)
-#define SIU_IRQ3 (6)
-#define SIU_LEVEL3 (7)
-#define SIU_IRQ4 (8)
-#define SIU_LEVEL4 (9)
-#define SIU_IRQ5 (10)
-#define SIU_LEVEL5 (11)
-#define SIU_IRQ6 (12)
-#define SIU_LEVEL6 (13)
-#define SIU_IRQ7 (14)
-#define SIU_LEVEL7 (15)
-
-#define MPC8xx_INT_FEC1 SIU_LEVEL1
-#define MPC8xx_INT_FEC2 SIU_LEVEL3
-
-#define MPC8xx_INT_SCC1 (CPM_IRQ_OFFSET + CPMVEC_SCC1)
-#define MPC8xx_INT_SCC2 (CPM_IRQ_OFFSET + CPMVEC_SCC2)
-#define MPC8xx_INT_SCC3 (CPM_IRQ_OFFSET + CPMVEC_SCC3)
-#define MPC8xx_INT_SCC4 (CPM_IRQ_OFFSET + CPMVEC_SCC4)
-#define MPC8xx_INT_SMC1 (CPM_IRQ_OFFSET + CPMVEC_SMC1)
-#define MPC8xx_INT_SMC2 (CPM_IRQ_OFFSET + CPMVEC_SMC2)
-
-/* The internal interrupts we can configure as we see fit.
- * My personal preference is CPM at level 2, which puts it above the
- * MBX PCI/ISA/IDE interrupts.
- */
-#ifndef PIT_INTERRUPT
-#define PIT_INTERRUPT SIU_LEVEL0
-#endif
-#ifndef CPM_INTERRUPT
-#define CPM_INTERRUPT SIU_LEVEL2
-#endif
-#ifndef PCMCIA_INTERRUPT
-#define PCMCIA_INTERRUPT SIU_LEVEL6
-#endif
-#ifndef DEC_INTERRUPT
-#define DEC_INTERRUPT SIU_LEVEL7
-#endif
-
-/* Some internal interrupt registers use an 8-bit mask for the interrupt
- * level instead of a number.
- */
-#define mk_int_int_mask(IL) (1 << (7 - (IL/2)))
-
-#elif defined(CONFIG_83xx)
-#include <asm/mpc83xx.h>
-
-#define NR_IRQS (NR_IPIC_INTS)
-
-#elif defined(CONFIG_85xx)
-/* Now include the board configuration specific associations.
-*/
-#include <asm/mpc85xx.h>
-
-/* The MPC8548 openpic has 48 internal interrupts and 12 external
- * interrupts.
- *
- * We are "flattening" the interrupt vectors of the cascaded CPM
- * so that we can uniquely identify any interrupt source with a
- * single integer.
- */
-#define NR_CPM_INTS 64
-#define NR_EPIC_INTS 60
-#ifndef NR_8259_INTS
-#define NR_8259_INTS 0
-#endif
-#define NUM_8259_INTERRUPTS NR_8259_INTS
-
-#ifndef CPM_IRQ_OFFSET
-#define CPM_IRQ_OFFSET 0
-#endif
-
-#define NR_IRQS (NR_EPIC_INTS + NR_CPM_INTS + NR_8259_INTS)
-
-/* Internal IRQs on MPC85xx OpenPIC */
-
-#ifndef MPC85xx_OPENPIC_IRQ_OFFSET
-#ifdef CONFIG_CPM2
-#define MPC85xx_OPENPIC_IRQ_OFFSET (CPM_IRQ_OFFSET + NR_CPM_INTS)
-#else
-#define MPC85xx_OPENPIC_IRQ_OFFSET 0
-#endif
-#endif
-
-/* Not all of these exist on all MPC85xx implementations */
-#define MPC85xx_IRQ_L2CACHE ( 0 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_ECM ( 1 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DDR ( 2 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_LBIU ( 3 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DMA0 ( 4 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DMA1 ( 5 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DMA2 ( 6 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DMA3 ( 7 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_PCI1 ( 8 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_PCI2 ( 9 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_RIO_ERROR ( 9 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_RIO_BELL (10 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_RIO_TX (11 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_RIO_RX (12 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC1_TX (13 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC1_RX (14 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC3_TX (15 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC3_RX (16 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC3_ERROR (17 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC1_ERROR (18 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC2_TX (19 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC2_RX (20 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC4_TX (21 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC4_RX (22 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC4_ERROR (23 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC2_ERROR (24 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_FEC (25 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DUART (26 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_IIC1 (27 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_PERFMON (28 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_SEC2 (29 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_CPM (30 + MPC85xx_OPENPIC_IRQ_OFFSET)
-
-/* The 12 external interrupt lines */
-#define MPC85xx_IRQ_EXT0 (48 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT1 (49 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT2 (50 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT3 (51 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT4 (52 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT5 (53 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT6 (54 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT7 (55 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT8 (56 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT9 (57 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT10 (58 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT11 (59 + MPC85xx_OPENPIC_IRQ_OFFSET)
-
-/* CPM related interrupts */
-#define SIU_INT_ERROR ((uint)0x00+CPM_IRQ_OFFSET)
-#define SIU_INT_I2C ((uint)0x01+CPM_IRQ_OFFSET)
-#define SIU_INT_SPI ((uint)0x02+CPM_IRQ_OFFSET)
-#define SIU_INT_RISC ((uint)0x03+CPM_IRQ_OFFSET)
-#define SIU_INT_SMC1 ((uint)0x04+CPM_IRQ_OFFSET)
-#define SIU_INT_SMC2 ((uint)0x05+CPM_IRQ_OFFSET)
-#define SIU_INT_USB ((uint)0x0b+CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER1 ((uint)0x0c+CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER2 ((uint)0x0d+CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER3 ((uint)0x0e+CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER4 ((uint)0x0f+CPM_IRQ_OFFSET)
-#define SIU_INT_FCC1 ((uint)0x20+CPM_IRQ_OFFSET)
-#define SIU_INT_FCC2 ((uint)0x21+CPM_IRQ_OFFSET)
-#define SIU_INT_FCC3 ((uint)0x22+CPM_IRQ_OFFSET)
-#define SIU_INT_MCC1 ((uint)0x24+CPM_IRQ_OFFSET)
-#define SIU_INT_MCC2 ((uint)0x25+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC1 ((uint)0x28+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC2 ((uint)0x29+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC3 ((uint)0x2a+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC4 ((uint)0x2b+CPM_IRQ_OFFSET)
-#define SIU_INT_PC15 ((uint)0x30+CPM_IRQ_OFFSET)
-#define SIU_INT_PC14 ((uint)0x31+CPM_IRQ_OFFSET)
-#define SIU_INT_PC13 ((uint)0x32+CPM_IRQ_OFFSET)
-#define SIU_INT_PC12 ((uint)0x33+CPM_IRQ_OFFSET)
-#define SIU_INT_PC11 ((uint)0x34+CPM_IRQ_OFFSET)
-#define SIU_INT_PC10 ((uint)0x35+CPM_IRQ_OFFSET)
-#define SIU_INT_PC9 ((uint)0x36+CPM_IRQ_OFFSET)
-#define SIU_INT_PC8 ((uint)0x37+CPM_IRQ_OFFSET)
-#define SIU_INT_PC7 ((uint)0x38+CPM_IRQ_OFFSET)
-#define SIU_INT_PC6 ((uint)0x39+CPM_IRQ_OFFSET)
-#define SIU_INT_PC5 ((uint)0x3a+CPM_IRQ_OFFSET)
-#define SIU_INT_PC4 ((uint)0x3b+CPM_IRQ_OFFSET)
-#define SIU_INT_PC3 ((uint)0x3c+CPM_IRQ_OFFSET)
-#define SIU_INT_PC2 ((uint)0x3d+CPM_IRQ_OFFSET)
-#define SIU_INT_PC1 ((uint)0x3e+CPM_IRQ_OFFSET)
-#define SIU_INT_PC0 ((uint)0x3f+CPM_IRQ_OFFSET)
-
-#elif defined(CONFIG_PPC_86xx)
-#include <asm/mpc86xx.h>
-
-#define NR_EPIC_INTS 48
-#ifndef NR_8259_INTS
-#define NR_8259_INTS 16 /*ULI 1575 can route 12 interrupts */
-#endif
-#define NUM_8259_INTERRUPTS NR_8259_INTS
-
-#ifndef I8259_OFFSET
-#define I8259_OFFSET 0
-#endif
-
-#define NR_IRQS 256
-
-/* Internal IRQs on MPC86xx OpenPIC */
-
-#ifndef MPC86xx_OPENPIC_IRQ_OFFSET
-#define MPC86xx_OPENPIC_IRQ_OFFSET NR_8259_INTS
-#endif
-
-/* The 48 internal sources */
-#define MPC86xx_IRQ_NULL ( 0 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_MCM ( 1 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_DDR ( 2 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_LBC ( 3 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_DMA0 ( 4 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_DMA1 ( 5 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_DMA2 ( 6 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_DMA3 ( 7 + MPC86xx_OPENPIC_IRQ_OFFSET)
-
-/* no 10,11 */
-#define MPC86xx_IRQ_UART2 (12 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC1_TX (13 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC1_RX (14 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC3_TX (15 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC3_RX (16 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC3_ERROR (17 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC1_ERROR (18 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC2_TX (19 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC2_RX (20 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC4_TX (21 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC4_RX (22 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC4_ERROR (23 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_TSEC2_ERROR (24 + MPC86xx_OPENPIC_IRQ_OFFSET)
-/* no 25 */
-#define MPC86xx_IRQ_UART1 (26 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_IIC (27 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_PERFMON (28 + MPC86xx_OPENPIC_IRQ_OFFSET)
-/* no 29,30,31 */
-#define MPC86xx_IRQ_SRIO_ERROR (32 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_SRIO_OUT_BELL (33 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_SRIO_IN_BELL (34 + MPC86xx_OPENPIC_IRQ_OFFSET)
-/* no 35,36 */
-#define MPC86xx_IRQ_SRIO_OUT_MSG1 (37 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_SRIO_IN_MSG1 (38 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_SRIO_OUT_MSG2 (39 + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_SRIO_IN_MSG2 (40 + MPC86xx_OPENPIC_IRQ_OFFSET)
-
-/* The 12 external interrupt lines */
-#define MPC86xx_IRQ_EXT_BASE 48
-#define MPC86xx_IRQ_EXT0 (0 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT1 (1 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT2 (2 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT3 (3 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT4 (4 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT5 (5 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT6 (6 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT7 (7 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT8 (8 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT9 (9 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT10 (10 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-#define MPC86xx_IRQ_EXT11 (11 + MPC86xx_IRQ_EXT_BASE \
- + MPC86xx_OPENPIC_IRQ_OFFSET)
-
-#else /* CONFIG_40x + CONFIG_8xx */
-/*
- * this is the # irq's for all ppc arch's (pmac/chrp/prep)
- * so it is the max of them all
- */
-#define NR_IRQS 256
-#define __DO_IRQ_CANON 1
-
-#ifndef CONFIG_8260
-
-#define NUM_8259_INTERRUPTS 16
-
-#else /* CONFIG_8260 */
-
-/* The 8260 has an internal interrupt controller with a maximum of
- * 64 IRQs. We will use NR_IRQs from above since it is large enough.
- * Don't be confused by the 8260 documentation where they list an
- * "interrupt number" and "interrupt vector". We are only interested
- * in the interrupt vector. There are "reserved" holes where the
- * vector number increases, but the interrupt number in the table does not.
- * (Document errata updates have fixed this...make sure you have up to
- * date processor documentation -- Dan).
- */
-
-#ifndef CPM_IRQ_OFFSET
-#define CPM_IRQ_OFFSET 0
-#endif
-
-#define NR_CPM_INTS 64
-
-#define SIU_INT_ERROR ((uint)0x00 + CPM_IRQ_OFFSET)
-#define SIU_INT_I2C ((uint)0x01 + CPM_IRQ_OFFSET)
-#define SIU_INT_SPI ((uint)0x02 + CPM_IRQ_OFFSET)
-#define SIU_INT_RISC ((uint)0x03 + CPM_IRQ_OFFSET)
-#define SIU_INT_SMC1 ((uint)0x04 + CPM_IRQ_OFFSET)
-#define SIU_INT_SMC2 ((uint)0x05 + CPM_IRQ_OFFSET)
-#define SIU_INT_IDMA1 ((uint)0x06 + CPM_IRQ_OFFSET)
-#define SIU_INT_IDMA2 ((uint)0x07 + CPM_IRQ_OFFSET)
-#define SIU_INT_IDMA3 ((uint)0x08 + CPM_IRQ_OFFSET)
-#define SIU_INT_IDMA4 ((uint)0x09 + CPM_IRQ_OFFSET)
-#define SIU_INT_SDMA ((uint)0x0a + CPM_IRQ_OFFSET)
-#define SIU_INT_USB ((uint)0x0b + CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER1 ((uint)0x0c + CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER2 ((uint)0x0d + CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER3 ((uint)0x0e + CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER4 ((uint)0x0f + CPM_IRQ_OFFSET)
-#define SIU_INT_TMCNT ((uint)0x10 + CPM_IRQ_OFFSET)
-#define SIU_INT_PIT ((uint)0x11 + CPM_IRQ_OFFSET)
-#define SIU_INT_PCI ((uint)0x12 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ1 ((uint)0x13 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ2 ((uint)0x14 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ3 ((uint)0x15 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ4 ((uint)0x16 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ5 ((uint)0x17 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ6 ((uint)0x18 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ7 ((uint)0x19 + CPM_IRQ_OFFSET)
-#define SIU_INT_FCC1 ((uint)0x20 + CPM_IRQ_OFFSET)
-#define SIU_INT_FCC2 ((uint)0x21 + CPM_IRQ_OFFSET)
-#define SIU_INT_FCC3 ((uint)0x22 + CPM_IRQ_OFFSET)
-#define SIU_INT_MCC1 ((uint)0x24 + CPM_IRQ_OFFSET)
-#define SIU_INT_MCC2 ((uint)0x25 + CPM_IRQ_OFFSET)
-#define SIU_INT_SCC1 ((uint)0x28 + CPM_IRQ_OFFSET)
-#define SIU_INT_SCC2 ((uint)0x29 + CPM_IRQ_OFFSET)
-#define SIU_INT_SCC3 ((uint)0x2a + CPM_IRQ_OFFSET)
-#define SIU_INT_SCC4 ((uint)0x2b + CPM_IRQ_OFFSET)
-#define SIU_INT_PC15 ((uint)0x30 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC14 ((uint)0x31 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC13 ((uint)0x32 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC12 ((uint)0x33 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC11 ((uint)0x34 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC10 ((uint)0x35 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC9 ((uint)0x36 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC8 ((uint)0x37 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC7 ((uint)0x38 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC6 ((uint)0x39 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC5 ((uint)0x3a + CPM_IRQ_OFFSET)
-#define SIU_INT_PC4 ((uint)0x3b + CPM_IRQ_OFFSET)
-#define SIU_INT_PC3 ((uint)0x3c + CPM_IRQ_OFFSET)
-#define SIU_INT_PC2 ((uint)0x3d + CPM_IRQ_OFFSET)
-#define SIU_INT_PC1 ((uint)0x3e + CPM_IRQ_OFFSET)
-#define SIU_INT_PC0 ((uint)0x3f + CPM_IRQ_OFFSET)
-
-#endif /* CONFIG_8260 */
-
-#endif /* Whatever way too big #ifdef */
-
-#define NR_MASK_WORDS ((NR_IRQS + 31) / 32)
-/* pedantic: these are long because they are used with set_bit --RR */
-extern unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
-
-/*
- * Because many systems have two overlapping names spaces for
- * interrupts (ISA and XICS for example), and the ISA interrupts
- * have historically not been easy to renumber, we allow ISA
- * interrupts to take values 0 - 15, and shift up the remaining
- * interrupts by 0x10.
- */
-#define NUM_ISA_INTERRUPTS 0x10
-extern int __irq_offset_value;
-
-static inline int irq_offset_up(int irq)
-{
- return(irq + __irq_offset_value);
-}
-
-static inline int irq_offset_down(int irq)
-{
- return(irq - __irq_offset_value);
-}
-
-static inline int irq_offset_value(void)
-{
- return __irq_offset_value;
-}
-
-#ifdef __DO_IRQ_CANON
-extern int ppc_do_canonicalize_irqs;
-#else
-#define ppc_do_canonicalize_irqs 0
-#endif
-
-static __inline__ int irq_canonicalize(int irq)
-{
- if (ppc_do_canonicalize_irqs && irq == 2)
- irq = 9;
- return irq;
-}
-#endif /* CONFIG_PPC_MERGE */
-
extern int distribute_irqs;
struct irqaction;
--
1.5.2.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox