* Re: ioremap() fails for >64 MB
From: Matt Porter @ 2006-08-23 14:05 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <44EB717D.3080800@dlasys.net>
On Tue, Aug 22, 2006 at 05:05:01PM -0400, David H. Lynch Jr. wrote:
> is ioremap() failing or is vmalloc failing ?
>
> ioremap should just assign a virtual address to a physical address -
> does it actually allocate anything ?
> I beleive I am ioremap()ing a greater than 64MB Flash ROM and I do
> not think it is failing.
ioremap() allocates virtual address space in order to be able to
do the assignment. The ability to allocate this vmalloc space
(which is used by ioremap() and vmalloc() calls) varies based
on amount of memory, etc. in a system. It also depends on how
good of a quality of a board port is done. It's possible to do
some very stupid things that constrict availability of vmalloc
space. So YMMV versus others.
-Matt
^ permalink raw reply
* Re: update: consolidated flat device tree code
From: Hollis Blanchard @ 2006-08-23 14:42 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Pantelis Antoniou, Sachin P. Sant,
linuxppc-embedded
In-Reply-To: <17643.64011.666743.300278@cargo.ozlabs.ibm.com>
On Wed, 2006-08-23 at 16:47 +1000, Paul Mackerras wrote:
> Hollis Blanchard writes:
>
> > Still haven't looked to merge Matt's changes (because I'm busy, the
> > current code works for me, and they haven't been accepted in u-boot
> > yet).
>
> The other version that was posted had support for modifying an
> existing flat tree, which I need for the wrapper code for prep. Are
> those "Matt's changes"? Are you thinking of adding that capability to
> your version?
You can do this now with the ft_set_prop() function, which is what I'm
using for Xen.
At the moment that function isn't able to modify the size of a property,
but Mark is going to adapt his code (which supports that).
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Olof Johansson @ 2006-08-23 14:51 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC20C@zch01exm20.fsl.freescale.net>
On Wed, Aug 23, 2006 at 06:55:26PM +0800, Li Yang-r58472 wrote:
> Ok, I rephrase my question as is it no longer needed? Sometimes people
> may use this value as a rough estimation of CPU performance. There are
> people even maintained a list of bogoMIPS of most CPUs. Maybe it is
> still needed for some legacy reasons. I'm not very sure. :) At leave
> we need to inform people who do look at this magic number and find it
> amazingly low.
Bogomips has never had anything to do with performance on PPC, it's just
a number that's based on the decrementer frequency. For processors with
external/fixed decrementer clock, it will not vary between different
processors in a meaningful way.
Every now and then someone will ask "why does my PPC box have such low
bogomips, is it really that much slower than my PC?". Removing all output
would certainly help avoid that confusion.
For reference, my G5 here has 66.56 bogomips, which corresponds well to
the 33MHz decrementer clock it uses.
-Olof
^ permalink raw reply
* Re: booting with BootX corrupts memory
From: Olaf Hering @ 2006-08-23 14:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Niels Kristian Bech Jensen
In-Reply-To: <1156195877.21752.39.camel@localhost.localdomain>
On Tue, Aug 22, Benjamin Herrenschmidt wrote:
>
> > > No, now I dont even get console= output on serial console.
> >
> > It doesnt work on a 7200, butit works on a beige G3.
> > But later it locks up in 'PM: Adding info for No Bus:target0:0',
> > after mesh init. This one is likely unrelated.
>
> Depends.... does it work if you netboot a zImage.coff ?
Have to try that, but 2.6.16 freezes as well.
^ permalink raw reply
* Re: TEMAC problem on ML403 with U-boot.
From: Frank D Lombardo @ 2006-08-23 15:08 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F391AE6DCE84284F62F4FEAB2460@phx.gbl>
Ming Liu wrote:
> Dear Frank,
> In your ML403 design which is booted by U-boot, do you use the normal
> 10/100M Enet MAC or TEMAC? Is TEMAC supported by U-Boot 1.1.4? In my
> design I use TEMAC and it works well when I boot my Linux directly
> using Xilinx EDK bootloader. However it fails when using U-boot......
>
> Thanks for your telling.
>
> Regards
> Ming
>
> _________________________________________________________________
> 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
Ming,
The ML403 reference design from Xilinx uses the 10/100 Ethernet MAC and
works with U-Boot 1.1.4. The Xilinx GSRD design uses the ll_temac and it
does not work with U-Boot. We have decided that it would not be worth
the effort to port the ll_temac driver to work with U-Boot. However, if
anybody has done so, I would be interested.
Frank
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Tim Bird @ 2006-08-23 16:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1156329453.3914.13.camel@ux156>
Johannes Berg wrote:
> On Wed, 2006-08-23 at 18:25 +0800, Li Yang-r58472 wrote:
> > I noticed a recent modification to __delay has changed from using empty
> > loops to reading timebase. Thus, breaks the calculation of bogomips,
> > and makes it terribly low. Is the bogomips no longer being supported on
> > powerpc arch?
>
> What's there to be 'supported'? The only purpose of bogomips is
> calibrating the delay loop, and that has changed now by using timebase,
> hence bogomips no longer have a purpose. There was even a patch to
> remove it from /proc/cpuinfo but I'm not sure whether that got applied
> or not.
I missed the patch for this, but I have a related question.
What is the status of the calibration code now for PPC?
Is it just skipped?
I assume that the ability to set a preset loops_per_jiffy
is no longer relevant?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Li Yang @ 2006-08-23 16:46 UTC (permalink / raw)
Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <44EC8338.3050203@am.sony.com>
On 8/24/06, Tim Bird <tim.bird@am.sony.com> wrote:
> Johannes Berg wrote:
> > On Wed, 2006-08-23 at 18:25 +0800, Li Yang-r58472 wrote:
> > > I noticed a recent modification to __delay has changed from using empty
> > > loops to reading timebase. Thus, breaks the calculation of bogomips,
> > > and makes it terribly low. Is the bogomips no longer being supported on
> > > powerpc arch?
> >
> > What's there to be 'supported'? The only purpose of bogomips is
> > calibrating the delay loop, and that has changed now by using timebase,
> > hence bogomips no longer have a purpose. There was even a patch to
> > remove it from /proc/cpuinfo but I'm not sure whether that got applied
> > or not.
>
> I missed the patch for this, but I have a related question.
> What is the status of the calibration code now for PPC?
> Is it just skipped?
The calibration is still used.
>
> I assume that the ability to set a preset loops_per_jiffy
> is no longer relevant?
However, loop is no longer true loop now. It should be called
timebase_change_per_jiffy. :)
- Leo
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Li Yang @ 2006-08-23 16:47 UTC (permalink / raw)
Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <20060823145138.GH614@pb15.lixom.net>
On 8/23/06, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Aug 23, 2006 at 06:55:26PM +0800, Li Yang-r58472 wrote:
> > Ok, I rephrase my question as is it no longer needed? Sometimes people
> > may use this value as a rough estimation of CPU performance. There are
> > people even maintained a list of bogoMIPS of most CPUs. Maybe it is
> > still needed for some legacy reasons. I'm not very sure. :) At leave
> > we need to inform people who do look at this magic number and find it
> > amazingly low.
>
> Bogomips has never had anything to do with performance on PPC, it's just
> a number that's based on the decrementer frequency. For processors with
> external/fixed decrementer clock, it will not vary between different
> processors in a meaningful way.
>
> Every now and then someone will ask "why does my PPC box have such low
> bogomips, is it really that much slower than my PC?". Removing all output
> would certainly help avoid that confusion.
>
> For reference, my G5 here has 66.56 bogomips, which corresponds well to
> the 33MHz decrementer clock it uses.
I think it's the new way to use timebase or RTC. Legacy bogomips is
calculated by counting empty loops, which at some degree reflects cpu
performance. Do you mean it has always been like this for PPC?
- Leo
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Olaf Hering @ 2006-08-23 16:50 UTC (permalink / raw)
To: Tim Bird; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <44EC8338.3050203@am.sony.com>
On Wed, Aug 23, Tim Bird wrote:
> I missed the patch for this, but I have a related question.
http://ozlabs.org/pipermail/linuxppc-dev/2006-July/024708.html
^ permalink raw reply
* Re: BogoMIPS no longer supported on PowerPC?
From: Linas Vepstas @ 2006-08-23 18:06 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <20060823145138.GH614@pb15.lixom.net>
On Wed, Aug 23, 2006 at 09:51:38AM -0500, Olof Johansson wrote:
>
> For reference, my G5 here has 66.56 bogomips,
H3y d00d3, 1ik3, my 12-year-old 486DX100 h4s m0r3 bogomips
th4n th4t! 486 r0x and p0w3rpc sux!
^ permalink raw reply
* atomic operations in user space
From: Terry Liang @ 2006-08-23 19:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
Thanks. Arnd. My main concern is whether the operations are really atomic as they are in the kernel space. I have read some discussion in another forum that on other platforms, even if you are able to compile the atomic_add(), atomic_set(), etc. from an user space application, they don't guarantee to be atomic. Thanks.
Regards,
Terry Liang
[-- Attachment #2: Type: text/html, Size: 820 bytes --]
^ permalink raw reply
* Philips isp1362 linux driver
From: Kartik Babu @ 2006-08-23 19:16 UTC (permalink / raw)
To: linuxppc-embedded, kylej
Hi,
I was looking through the ozlabs forums, and saw your post about the
driver for the Philips isp1362 USB host controller. You had offered to
put up the for this driver to another poster.
I was wondering if you would be able to share that code with me, I'm
working on getting USB working reliably on a Phytec PXA255 board, and
I'm having some issues. I was looking to see if the other drivers out
there would do a better job. (Currently using the driver from ELINOS).
Thanks in advance.
Kartik
^ permalink raw reply
* crashes on NFS
From: Wade Maxfield @ 2006-08-23 20:37 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
Hi,
I accidentally posted some kernel crashes when running updatedb on an
ML403 using MontaVista tools. I was meaning to send them to MV.
I had swap enabled over NFS (128meg), and the NFS directory being exported
was about 2 gigabytes in sizes.
According to MontaVista, the problem was the kernel was running out of
memory. (There are 64 megs of ram on that board.)
I guess updatedb is very greedy.
thanks,
wade
[-- Attachment #2: Type: text/html, Size: 507 bytes --]
^ permalink raw reply
* PCI resource allocation MPC8540ADS
From: Clint Thomas @ 2006-08-23 21:11 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]
Hey guys,
I have a development board based loosely off the MPC8540ADS design that
I am trying to move to the Linux kernel 2.6. I already have this system
working successfully in Linux Kernel 2.4, but after dealing with
compilation and load errors, i've come to the point where I can get to a
console. However, this problem at boot time keeps me from using a lot of
onboard hardware. When I enable PCI support in the Kernel configuration,
this is the text I get at boot time...
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 1 of PCI bridge 1
PCI: Cannot allocate resource region 2 of PCI bridge 1
PCI: bridge 1 resource 2 moved to 9ff00000..9fffffff
PCI: Cannot allocate resource region 1 of PCI bridge 2
PCI: Cannot allocate resource region 2 of PCI bridge 2
PCI: bridge 2 resource 2 moved to 9fe00000..9fefffff
PCI: Cannot allocate resource region 1 of device 0000:00:14.0
PCI: Cannot allocate resource region 2 of device 0000:00:14.0
PCI: Cannot allocate resource region 0 of device 0000:01:01.0
PCI: Cannot allocate resource region 1 of device 0000:01:01.0
PCI: Cannot allocate resource region 2 of device 0000:01:01.0
PCI: Cannot allocate resource region 0 of device 0000:01:05.0
PCI: Cannot allocate resource region 1 of device 0000:01:05.0
PCI: Cannot allocate resource region 2 of device 0000:01:05.0
PCI: Cannot allocate resource region 0 of device 0000:01:06.0
PCI: Cannot allocate resource region 0 of device 0000:01:06.1
PCI: Cannot allocate resource region 0 of device 0000:01:06.2
PCI: Failed to allocate mem resource #0:1000000@0 for 0000:01:01.0
PCI: Failed to allocate I/O resource #1:100@1000 for 0000:01:01.0
PCI: Failed to allocate mem resource #2:1000@0 for 0000:01:01.0
PCI: Failed to allocate mem resource #0:10000@0 for 0000:01:05.0
PCI: Failed to allocate mem resource #2:10000@0 for 0000:01:05.0
PCI: Failed to allocate mem resource #0:1000@0 for 0000:01:06.0
PCI: Failed to allocate mem resource #0:1000@0 for 0000:01:06.1
PCI: Failed to allocate mem resource #0:100@0 for 0000:01:06.2
the system is using a PLX PCI bridge chip. Like I said, this works fine
in my 2.4 distribution. Thanks for any and all help!
Clinton Thomas
cthomas@soneticom.com
[-- Attachment #2: Type: text/html, Size: 2937 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-08-23 21:36 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, James K Lewis, linux-kernel, netdev
In-Reply-To: <200608201203.15645.arnd@arndb.de>
On Sun, Aug 20, 2006 at 12:03:14PM +0200, Arnd Bergmann wrote:
> On Sunday 20 August 2006 08:31, Benjamin Herrenschmidt wrote:
> > > card->low_watermark->next->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
> > > mb();
> > > card->low_watermark->dmac_cmd_status &= ~SPIDER_NET_DESCR_TXDESFLG;
> > > card->low_watermark = card->low_watermark->next;
> > >
> > > when we queue another frame for TX.
> >
> > I would have expected those to be racy vs. the hardware... what if the
> > hardware is updating dmac_cmd_status just as your are trying to and the
> > bit out of it ?
>
> Right, that doesn't work. It is the only bit we use in that byte though,
> so maybe it can be done with a single byte write.
Thanks, you're right, I missed that. I'll change this to byte access
shortly. Any recommendations for style/api for byte access?
I could create a searate patch to change struct descr {} to split
the u32 into several u8's; there's a dozen spots that get touched.
Alternatel, I could do a cheesy cast to char[4] and access that way.
Opinions?
--linas
^ permalink raw reply
* Re: [PATCH 5/6]: powerpc/cell spidernet bottom half
From: Linas Vepstas @ 2006-08-23 21:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
ens Osterkamp, Jeff Garzik
In-Reply-To: <200608190103.05649.arnd@arndb.de>
On Sat, Aug 19, 2006 at 01:03:04AM +0200, Arnd Bergmann wrote:
> using the NAPI poll function
Still fiddling with this. Getting side-tracked after noticing
that the RX side generates a *huge* numbe of interrupts, despite
code in the driver which superficially appears to be RX NAPI.
One step forward, two steps back, isn't there a dance like that?
--linas
^ permalink raw reply
* Re: [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: David Miller @ 2006-08-23 22:03 UTC (permalink / raw)
To: linas; +Cc: arnd, jklewis, linux-kernel, linuxppc-dev, netdev
In-Reply-To: <20060823213642.GG4401@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Wed, 23 Aug 2006 16:36:42 -0500
> I could create a searate patch to change struct descr {} to split
> the u32 into several u8's; there's a dozen spots that get touched.
>
> Alternatel, I could do a cheesy cast to char[4] and access that way.
> Opinions?
The most portable scheme would be a "u32/u8[4]" union with
appropriate endianness checks when determining which byte
to access in the u8[] view.
^ permalink raw reply
* CompactFlash on PQII Pro
From: Ben Warren @ 2006-08-23 22:16 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have a custom board where we've hung a CompactFlash on the local bus
of an MPC8349 processor, intending to use it in 'True IDE' mode. The
closest thing I've found in the kernel tree is
drivers/ide/ppc/ide-m8xx.c, although it's *very* possible I'm not
looking in the right place.
I believe my chip's local bus is similar to the 8xx, so making this
driver work with my hardware doesn't seem like that big a deal. I fully
expect to have to monkey with UPM timings among other things. On the
other hand, this seems like something other people would have done,
maybe with one of the other PQ families like 82xx or 85xx.
Does anyone have a patch, suggestions or flames they can throw my way?
cheers,
Ben
^ permalink raw reply
* Re: [PATCH ] powerpc: pass UPIO_TSI flag to 8259 serial driver
From: Benjamin Herrenschmidt @ 2006-08-23 21:52 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <44EC15A1.4090807@freescale.com>
On Wed, 2006-08-23 at 16:45 +0800, Zang Roy-r61911 wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2006-08-23 at 10:20 +0800, Zang Roy-r61911 wrote:
> >
> >> The patch passes the UPIO_TSI flag to general 8259 serial driver
> >>
> >
> > Patch looks damaged to me... appart from that, what it does looks ok to
> > me.
> Sorry. It seems imported by my mail client. Please pick up the following
> one.
Seems to be damaged as well ! What mail client do you use ?
Ben.
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>
> ---
>
> arch/powerpc/kernel/legacy_serial.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c
> b/arch/powerpc/kernel/legacy_serial.c
> index 359ab89..07c2c00 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -115,6 +115,7 @@ static int __init add_legacy_soc_port(st
> u64 addr;
> u32 *addrp;
> upf_t flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ;
> + struct device_node *tsi = of_get_parent(np);
>
> /* We only support ports that have a clock frequency properly
> * encoded in the device-tree.
> @@ -134,7 +135,10 @@ static int __init add_legacy_soc_port(st
> /* Add port, irq will be dealt with later. We passed a translated
> * IO port value. It will be fixed up later along with the irq
> */
> - return add_legacy_port(np, -1, UPIO_MEM, addr, addr, NO_IRQ, flags, 0);
> + if (tsi && !strcmp(tsi->type, "tsi-bridge"))
> + return add_legacy_port(np, -1, UPIO_TSI, addr, addr, NO_IRQ,
> flags, 0);
> + else
> + return add_legacy_port(np, -1, UPIO_MEM, addr, addr, NO_IRQ,
> flags, 0);
> }
>
> static int __init add_legacy_isa_port(struct device_node *np,
> @@ -464,7 +468,7 @@ static int __init serial_dev_init(void)
> fixup_port_irq(i, np, port);
> if (port->iotype == UPIO_PORT)
> fixup_port_pio(i, np, port);
> - if (port->iotype == UPIO_MEM)
> + if ((port->iotype == UPIO_MEM) || (port->iotype == UPIO_TSI))
> fixup_port_mmio(i, np, port);
> }
>
^ permalink raw reply
* Re: CompactFlash on PQII Pro
From: Kumar Gala @ 2006-08-23 23:04 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1156371402.17977.21.camel@saruman.qstreams.net>
On Aug 23, 2006, at 5:16 PM, Ben Warren wrote:
> Hello,
>
> I have a custom board where we've hung a CompactFlash on the local bus
> of an MPC8349 processor, intending to use it in 'True IDE' mode. The
> closest thing I've found in the kernel tree is
> drivers/ide/ppc/ide-m8xx.c, although it's *very* possible I'm not
> looking in the right place.
>
> I believe my chip's local bus is similar to the 8xx, so making this
> driver work with my hardware doesn't seem like that big a deal. I
> fully
> expect to have to monkey with UPM timings among other things. On the
> other hand, this seems like something other people would have done,
> maybe with one of the other PQ families like 82xx or 85xx.
>
> Does anyone have a patch, suggestions or flames they can throw my way?
I know I posted a patch for cf-ide.c to lkml some time ago, this was
to do a CF in true ide mode using the 83xx localbus.
http://marc.theaimsgroup.com/?l=linux-kernel&m=113877891224982&w=2
We did some UPM setup in u-boot to use two CS on Localbus for this.
- kumar
^ permalink raw reply
* Re: PCI resource allocation MPC8540ADS
From: Kumar Gala @ 2006-08-23 23:06 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952918DFB7@bluefin.Soneticom.local>
On Aug 23, 2006, at 4:11 PM, Clint Thomas wrote:
> Hey guys,
>
> I have a development board based loosely off the MPC8540ADS design
> that I am trying to move to the Linux kernel 2.6. I already have
> this system working successfully in Linux Kernel 2.4, but after
> dealing with compilation and load errors, i've come to the point
> where I can get to a console. However, this problem at boot time
> keeps me from using a lot of onboard hardware. When I enable PCI
> support in the Kernel configuration, this is the text I get at boot
> time...
which 2.6 kernel are you using?
> PCI: Probing PCI hardware
> PCI: Cannot allocate resource region 1 of PCI bridge 1
> PCI: Cannot allocate resource region 2 of PCI bridge 1
> PCI: bridge 1 resource 2 moved to 9ff00000..9fffffff
> PCI: Cannot allocate resource region 1 of PCI bridge 2
> PCI: Cannot allocate resource region 2 of PCI bridge 2
> PCI: bridge 2 resource 2 moved to 9fe00000..9fefffff
> PCI: Cannot allocate resource region 1 of device 0000:00:14.0
> PCI: Cannot allocate resource region 2 of device 0000:00:14.0
> PCI: Cannot allocate resource region 0 of device 0000:01:01.0
> PCI: Cannot allocate resource region 1 of device 0000:01:01.0
> PCI: Cannot allocate resource region 2 of device 0000:01:01.0
> PCI: Cannot allocate resource region 0 of device 0000:01:05.0
> PCI: Cannot allocate resource region 1 of device 0000:01:05.0
> PCI: Cannot allocate resource region 2 of device 0000:01:05.0
> PCI: Cannot allocate resource region 0 of device 0000:01:06.0
> PCI: Cannot allocate resource region 0 of device 0000:01:06.1
> PCI: Cannot allocate resource region 0 of device 0000:01:06.2
> PCI: Failed to allocate mem resource #0:1000000@0 for 0000:01:01.0
> PCI: Failed to allocate I/O resource #1:100@1000 for 0000:01:01.0
> PCI: Failed to allocate mem resource #2:1000@0 for 0000:01:01.0
> PCI: Failed to allocate mem resource #0:10000@0 for 0000:01:05.0
> PCI: Failed to allocate mem resource #2:10000@0 for 0000:01:05.0
> PCI: Failed to allocate mem resource #0:1000@0 for 0000:01:06.0
> PCI: Failed to allocate mem resource #0:1000@0 for 0000:01:06.1
> PCI: Failed to allocate mem resource #0:100@0 for 0000:01:06.2
>
> the system is using a PLX PCI bridge chip. Like I said, this works
> fine in my 2.4 distribution. Thanks for any and all help!
can you post an lspci -v output.
- kumar
^ permalink raw reply
* Re: boot problems on pseries
From: Linas Vepstas @ 2006-08-23 23:59 UTC (permalink / raw)
To: dtutty; +Cc: linuxppc-dev
In-Reply-To: <20060822165023.GA4807@hooton>
On Tue, Aug 22, 2006 at 12:50:26PM -0400, dtutty@porchlight.ca wrote:
> Boot failures:
>
> 1. CD not recognized as bootable, so use OF manually.
> 2. OF manually will boot yaboot.
> 3. yaboot doesn't find its config in the /etc directory
> of the cd, nor in the / directory of the CD with the
> yaboot executable.
> 4. when manually from yaboot attempt to boot a kernel
> image, get either:
> a) CLAIMED FAILED
Olaf's suggestion to use netboot is a good one.
Have you tried googling "yaboot claim fail"?
I see suggetions to run yabootconfig, which normally
writes stuff to a special boot partition at /dev/sda1
No clue how to do this for a CD.
The BSD faq has a long discussion
http://www.netbsd.org/Ports/macppc/faq.html#ofw-claim-failed
which seems to indicate that some load or offset is being
incorrectly specified.
There seem to be plenty of other discussions as well
--linas
^ permalink raw reply
* Please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-08-24 0:44 UTC (permalink / raw)
To: gregkh, linuxppc-dev
Greg,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get another set of PowerPC updates for 2.6.18.
Thanks,
Paul.
arch/powerpc/boot/dts/mpc8540ads.dts | 257 +++++++++++++++++
arch/powerpc/boot/dts/mpc8541cds.dts | 244 ++++++++++++++++
arch/powerpc/boot/dts/mpc8548cds.dts | 287 +++++++++++++++++++
arch/powerpc/boot/dts/mpc8555cds.dts | 244 ++++++++++++++++
arch/powerpc/kernel/legacy_serial.c | 8 -
arch/powerpc/kernel/prom_parse.c | 13 -
arch/powerpc/kernel/time.c | 25 +-
arch/powerpc/kernel/traps.c | 8 -
arch/powerpc/mm/hugetlbpage.c | 2
arch/powerpc/platforms/85xx/Kconfig | 1
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 162 ++++-------
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 210 ++++++--------
arch/powerpc/platforms/86xx/mpc8641_hpcn.h | 32 --
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 324 +++++++++++----------
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 73 ++---
arch/powerpc/platforms/powermac/bootx_init.c | 15 +
arch/powerpc/sysdev/fsl_soc.c | 30 +-
arch/powerpc/sysdev/tsi108_dev.c | 10 -
arch/powerpc/sysdev/tsi108_pci.c | 21 +
include/asm-powerpc/pgalloc.h | 2
include/asm-powerpc/system.h | 9 +
include/asm-powerpc/tsi108.h | 14 +
include/asm-powerpc/tsi108_irq.h | 124 ++++++++
23 files changed, 1593 insertions(+), 522 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8540ads.dts
create mode 100644 arch/powerpc/boot/dts/mpc8541cds.dts
create mode 100644 arch/powerpc/boot/dts/mpc8548cds.dts
create mode 100644 arch/powerpc/boot/dts/mpc8555cds.dts
create mode 100644 include/asm-powerpc/tsi108_irq.h
Adam Litke:
[POWERPC] hugepage BUG fix
Andy Fleming:
[POWERPC] Fix interrupts on 8540 ADS board
[POWERPC] Fix CDS IRQ handling and PCI code
[POWERPC] Add 85xx DTS files to powerpc
[POWERPC] Fix FEC node in 8540 ADS dts
Benjamin Herrenschmidt:
[POWERPC] Fix BootX booting with an initrd
Jon Loeliger:
[POWERPC] Rewrite the PPC 86xx IRQ handling to use Flat Device Tree
Li Yang:
[POWERPC] Fix compile problem without CONFIG_PCI
Nathan Lynch:
[POWERPC] Fix gettimeofday inaccuracies
Paul Mackerras:
[POWERPC] Correct masks used in emulating some instructions
Zang Roy-r61911:
[POWERPC] Update mpc7448hpc2 board irq support using device tree
[POWERPC] Pass UPIO_TSI flag to 8259 serial driver
^ permalink raw reply
* [PATCH 1/3] Adapt ipic driver to new host_ops interface, add set_irq_type to set IRQ sense
From: Kim Phillips @ 2006-08-24 1:39 UTC (permalink / raw)
To: linuxppc-dev
This converts ipic code to Benh's IRQ mods. For the IPIC, IRQ sense values in the device tree equal those in include/linux/irq.h; that's 8 for low assertion (most internal IRQs on mpc83xx), and 2 for high-to-low change.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
please apply to 2.6.18
arch/powerpc/sysdev/ipic.c | 281 +++++++++++++++++++++++++++++---------------
arch/powerpc/sysdev/ipic.h | 23 +++-
include/asm-powerpc/ipic.h | 6 -
3 files changed, 208 insertions(+), 102 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 46801f5..8db65d5 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -19,14 +19,16 @@ #include <linux/stddef.h>
#include <linux/sched.h>
#include <linux/signal.h>
#include <linux/sysdev.h>
+#include <linux/device.h>
+#include <linux/bootmem.h>
+
#include <asm/irq.h>
#include <asm/io.h>
+#include <asm/prom.h>
#include <asm/ipic.h>
-#include <asm/mpc83xx.h>
#include "ipic.h"
-static struct ipic p_ipic;
static struct ipic * primary_ipic;
static struct ipic_info ipic_info[] = {
@@ -373,15 +375,17 @@ static inline void ipic_write(volatile u
out_be32(base + (reg >> 2), value);
}
-static inline struct ipic * ipic_from_irq(unsigned int irq)
+static inline struct ipic * ipic_from_irq(unsigned int virq)
{
return primary_ipic;
}
-static void ipic_enable_irq(unsigned int irq)
+#define ipic_irq_to_hw(virq) ((unsigned int)irq_map[virq].hwirq)
+
+static void ipic_unmask_irq(unsigned int virq)
{
- struct ipic *ipic = ipic_from_irq(irq);
- unsigned int src = irq - ipic->irq_offset;
+ struct ipic *ipic = ipic_from_irq(virq);
+ unsigned int src = ipic_irq_to_hw(virq);
u32 temp;
temp = ipic_read(ipic->regs, ipic_info[src].mask);
@@ -389,10 +393,10 @@ static void ipic_enable_irq(unsigned int
ipic_write(ipic->regs, ipic_info[src].mask, temp);
}
-static void ipic_disable_irq(unsigned int irq)
+static void ipic_mask_irq(unsigned int virq)
{
- struct ipic *ipic = ipic_from_irq(irq);
- unsigned int src = irq - ipic->irq_offset;
+ struct ipic *ipic = ipic_from_irq(virq);
+ unsigned int src = ipic_irq_to_hw(virq);
u32 temp;
temp = ipic_read(ipic->regs, ipic_info[src].mask);
@@ -400,47 +404,170 @@ static void ipic_disable_irq(unsigned in
ipic_write(ipic->regs, ipic_info[src].mask, temp);
}
-static void ipic_disable_irq_and_ack(unsigned int irq)
+static void ipic_ack_irq(unsigned int virq)
{
- struct ipic *ipic = ipic_from_irq(irq);
- unsigned int src = irq - ipic->irq_offset;
+ struct ipic *ipic = ipic_from_irq(virq);
+ unsigned int src = ipic_irq_to_hw(virq);
u32 temp;
- ipic_disable_irq(irq);
+ temp = ipic_read(ipic->regs, ipic_info[src].pend);
+ temp |= (1 << (31 - ipic_info[src].bit));
+ ipic_write(ipic->regs, ipic_info[src].pend, temp);
+}
+
+static void ipic_mask_irq_and_ack(unsigned int virq)
+{
+ struct ipic *ipic = ipic_from_irq(virq);
+ unsigned int src = ipic_irq_to_hw(virq);
+ u32 temp;
+
+ temp = ipic_read(ipic->regs, ipic_info[src].mask);
+ temp &= ~(1 << (31 - ipic_info[src].bit));
+ ipic_write(ipic->regs, ipic_info[src].mask, temp);
temp = ipic_read(ipic->regs, ipic_info[src].pend);
temp |= (1 << (31 - ipic_info[src].bit));
ipic_write(ipic->regs, ipic_info[src].pend, temp);
}
-static void ipic_end_irq(unsigned int irq)
+static void ipic_end_irq(unsigned int virq)
+{
+ if (!(irq_desc[virq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
+ ipic_unmask_irq(virq);
+}
+
+static int ipic_set_irq_type(unsigned int virq, unsigned int flow_type)
+{
+ struct ipic *ipic = ipic_from_irq(virq);
+ unsigned int src = ipic_irq_to_hw(virq);
+ struct irq_desc *desc = get_irq_desc(virq);
+ unsigned int vold, vnew, edibit;
+
+ if (flow_type == IRQ_TYPE_NONE)
+ flow_type = IRQ_TYPE_LEVEL_LOW;
+ if (!(flow_type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_FALLING))) {
+ printk(KERN_ERR "ipic: sense type 0x%x not supported\n",
+ flow_type);
+ return -EINVAL;
+ }
+
+ desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
+ desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
+ if (flow_type & IRQ_TYPE_LEVEL_LOW) {
+ desc->status |= IRQ_LEVEL;
+ set_irq_handler(virq, handle_level_irq);
+ } else {
+ set_irq_handler(virq, handle_edge_irq);
+ }
+
+ if (src == IPIC_IRQ_EXT0)
+ edibit = 15;
+ else
+ if (src >= IPIC_IRQ_EXT1 && src <= IPIC_IRQ_EXT7)
+ edibit = (14 - (src - IPIC_IRQ_EXT1));
+ else
+ /* only EXT IRQ senses are programmable on ipic */
+ return 0;
+
+ vold = ipic_read(ipic->regs, IPIC_SECNR);
+ if ((flow_type & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_FALLING) {
+ vnew = vold | (1 << edibit);
+ } else {
+ vnew = vold & ~(1 << edibit);
+ }
+ if (vold != vnew)
+ ipic_write(ipic->regs, IPIC_SECNR, vnew);
+ return 0;
+}
+
+static struct irq_chip ipic_irq_chip = {
+ .typename = " IPIC ",
+ .unmask = ipic_unmask_irq,
+ .mask = ipic_mask_irq,
+ .mask_ack = ipic_mask_irq_and_ack,
+ .ack = ipic_ack_irq,
+ .end = ipic_end_irq,
+ .set_type = ipic_set_irq_type,
+};
+
+static int ipic_host_match(struct irq_host *h, struct device_node *node)
{
- if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
- ipic_enable_irq(irq);
+ struct ipic *ipic = h->host_data;
+
+ /* Exact match, unless ipic node is NULL */
+ return ipic->of_node == NULL || ipic->of_node == node;
+}
+
+static int ipic_host_map(struct irq_host *h, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ struct ipic *ipic = h->host_data;
+ struct irq_chip *chip;
+
+ /* Default chip */
+ chip = &ipic->hc_irq;
+
+ set_irq_chip_data(virq, ipic);
+ set_irq_chip(virq, chip);
+
+ return 0;
}
-struct hw_interrupt_type ipic = {
- .typename = " IPIC ",
- .enable = ipic_enable_irq,
- .disable = ipic_disable_irq,
- .ack = ipic_disable_irq_and_ack,
- .end = ipic_end_irq,
+static int ipic_host_xlate(struct irq_host *h, struct device_node *ct,
+ u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq, unsigned int *out_flags)
+
+{
+ *out_hwirq = intspec[0];
+ /* device tree interrupt sense values are assigned either
+ LEVEL_LOW (low assertion) or EDGE_FALLING (high-to-low change) */
+ if (intsize > 1 && (intspec[1] & (IRQ_TYPE_LEVEL_LOW |
+ IRQ_TYPE_EDGE_FALLING)))
+ *out_flags = intspec[1];
+ else
+ *out_flags = IRQ_TYPE_NONE;
+ return 0;
+}
+
+static struct irq_host_ops ipic_host_ops = {
+ .match = ipic_host_match,
+ .map = ipic_host_map,
+ .xlate = ipic_host_xlate,
};
-void __init ipic_init(phys_addr_t phys_addr,
- unsigned int flags,
- unsigned int irq_offset,
- unsigned char *senses,
- unsigned int senses_count)
+void __init ipic_init(struct device_node *node,
+ unsigned int flags)
{
- u32 i, temp = 0;
+ struct ipic *ipic;
+ struct resource res;
+ u32 temp = 0, ret;
+
+ ipic = alloc_bootmem(sizeof(struct ipic));
+ if (ipic == NULL)
+ return;
+
+ memset(ipic, 0, sizeof(struct ipic));
+ ipic->of_node = node ? of_node_get(node) : NULL;
+
+ ipic->irqhost = irq_alloc_host(IRQ_HOST_MAP_LINEAR,
+ NR_IPIC_INTS,
+ &ipic_host_ops, 0);
+ if (ipic->irqhost == NULL) {
+ of_node_put(node);
+ return;
+ }
- primary_ipic = &p_ipic;
- primary_ipic->regs = ioremap(phys_addr, MPC83xx_IPIC_SIZE);
+ ret = of_address_to_resource(node, 0, &res);
+ if (ret)
+ return;
+
+ ipic->regs = ioremap(res.start, res.end - res.start + 1);
- primary_ipic->irq_offset = irq_offset;
+ ipic->irqhost->host_data = ipic;
+ ipic->hc_irq = ipic_irq_chip;
- ipic_write(primary_ipic->regs, IPIC_SICNR, 0x0);
+ /* init hw */
+ ipic_write(ipic->regs, IPIC_SICNR, 0x0);
/* default priority scheme is grouped. If spread mode is required
* configure SICFR accordingly */
@@ -453,49 +580,35 @@ void __init ipic_init(phys_addr_t phys_a
if (flags & IPIC_SPREADMODE_MIX_B)
temp |= SICFR_MPSB;
- ipic_write(primary_ipic->regs, IPIC_SICNR, temp);
+ ipic_write(ipic->regs, IPIC_SICNR, temp);
/* handle MCP route */
temp = 0;
if (flags & IPIC_DISABLE_MCP_OUT)
temp = SERCR_MCPR;
- ipic_write(primary_ipic->regs, IPIC_SERCR, temp);
+ ipic_write(ipic->regs, IPIC_SERCR, temp);
/* handle routing of IRQ0 to MCP */
- temp = ipic_read(primary_ipic->regs, IPIC_SEMSR);
+ temp = ipic_read(ipic->regs, IPIC_SEMSR);
if (flags & IPIC_IRQ0_MCP)
temp |= SEMSR_SIRQ0;
else
temp &= ~SEMSR_SIRQ0;
- ipic_write(primary_ipic->regs, IPIC_SEMSR, temp);
-
- for (i = 0 ; i < NR_IPIC_INTS ; i++) {
- irq_desc[i+irq_offset].chip = &ipic;
- irq_desc[i+irq_offset].status = IRQ_LEVEL;
- }
+ ipic_write(ipic->regs, IPIC_SEMSR, temp);
- temp = 0;
- for (i = 0 ; i < senses_count ; i++) {
- if ((senses[i] & IRQ_SENSE_MASK) == IRQ_SENSE_EDGE) {
- temp |= 1 << (15 - i);
- if (i != 0)
- irq_desc[i + irq_offset + MPC83xx_IRQ_EXT1 - 1].status = 0;
- else
- irq_desc[irq_offset + MPC83xx_IRQ_EXT0].status = 0;
- }
- }
- ipic_write(primary_ipic->regs, IPIC_SECNR, temp);
+ primary_ipic = ipic;
+ irq_set_default_host(primary_ipic->irqhost);
- printk ("IPIC (%d IRQ sources, %d External IRQs) at %p\n", NR_IPIC_INTS,
- senses_count, primary_ipic->regs);
+ printk ("IPIC (%d IRQ sources) at %p\n", NR_IPIC_INTS,
+ primary_ipic->regs);
}
-int ipic_set_priority(unsigned int irq, unsigned int priority)
+int ipic_set_priority(unsigned int virq, unsigned int priority)
{
- struct ipic *ipic = ipic_from_irq(irq);
- unsigned int src = irq - ipic->irq_offset;
+ struct ipic *ipic = ipic_from_irq(virq);
+ unsigned int src = ipic_irq_to_hw(virq);
u32 temp;
if (priority > 7)
@@ -520,10 +633,10 @@ int ipic_set_priority(unsigned int irq,
return 0;
}
-void ipic_set_highest_priority(unsigned int irq)
+void ipic_set_highest_priority(unsigned int virq)
{
- struct ipic *ipic = ipic_from_irq(irq);
- unsigned int src = irq - ipic->irq_offset;
+ struct ipic *ipic = ipic_from_irq(virq);
+ unsigned int src = ipic_irq_to_hw(virq);
u32 temp;
temp = ipic_read(ipic->regs, IPIC_SICFR);
@@ -537,37 +650,10 @@ void ipic_set_highest_priority(unsigned
void ipic_set_default_priority(void)
{
- ipic_set_priority(MPC83xx_IRQ_TSEC1_TX, 0);
- ipic_set_priority(MPC83xx_IRQ_TSEC1_RX, 1);
- ipic_set_priority(MPC83xx_IRQ_TSEC1_ERROR, 2);
- ipic_set_priority(MPC83xx_IRQ_TSEC2_TX, 3);
- ipic_set_priority(MPC83xx_IRQ_TSEC2_RX, 4);
- ipic_set_priority(MPC83xx_IRQ_TSEC2_ERROR, 5);
- ipic_set_priority(MPC83xx_IRQ_USB2_DR, 6);
- ipic_set_priority(MPC83xx_IRQ_USB2_MPH, 7);
-
- ipic_set_priority(MPC83xx_IRQ_UART1, 0);
- ipic_set_priority(MPC83xx_IRQ_UART2, 1);
- ipic_set_priority(MPC83xx_IRQ_SEC2, 2);
- ipic_set_priority(MPC83xx_IRQ_IIC1, 5);
- ipic_set_priority(MPC83xx_IRQ_IIC2, 6);
- ipic_set_priority(MPC83xx_IRQ_SPI, 7);
- ipic_set_priority(MPC83xx_IRQ_RTC_SEC, 0);
- ipic_set_priority(MPC83xx_IRQ_PIT, 1);
- ipic_set_priority(MPC83xx_IRQ_PCI1, 2);
- ipic_set_priority(MPC83xx_IRQ_PCI2, 3);
- ipic_set_priority(MPC83xx_IRQ_EXT0, 4);
- ipic_set_priority(MPC83xx_IRQ_EXT1, 5);
- ipic_set_priority(MPC83xx_IRQ_EXT2, 6);
- ipic_set_priority(MPC83xx_IRQ_EXT3, 7);
- ipic_set_priority(MPC83xx_IRQ_RTC_ALR, 0);
- ipic_set_priority(MPC83xx_IRQ_MU, 1);
- ipic_set_priority(MPC83xx_IRQ_SBA, 2);
- ipic_set_priority(MPC83xx_IRQ_DMA, 3);
- ipic_set_priority(MPC83xx_IRQ_EXT4, 4);
- ipic_set_priority(MPC83xx_IRQ_EXT5, 5);
- ipic_set_priority(MPC83xx_IRQ_EXT6, 6);
- ipic_set_priority(MPC83xx_IRQ_EXT7, 7);
+ ipic_write(primary_ipic->regs, IPIC_SIPRR_A, IPIC_SIPRR_A_DEFAULT);
+ ipic_write(primary_ipic->regs, IPIC_SIPRR_D, IPIC_SIPRR_D_DEFAULT);
+ ipic_write(primary_ipic->regs, IPIC_SMPRR_A, IPIC_SMPRR_A_DEFAULT);
+ ipic_write(primary_ipic->regs, IPIC_SMPRR_B, IPIC_SMPRR_B_DEFAULT);
}
void ipic_enable_mcp(enum ipic_mcp_irq mcp_irq)
@@ -600,17 +686,20 @@ void ipic_clear_mcp_status(u32 mask)
ipic_write(primary_ipic->regs, IPIC_SERMR, mask);
}
-/* Return an interrupt vector or -1 if no interrupt is pending. */
-int ipic_get_irq(struct pt_regs *regs)
+/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */
+unsigned int ipic_get_irq(struct pt_regs *regs)
{
int irq;
- irq = ipic_read(primary_ipic->regs, IPIC_SIVCR) & 0x7f;
+ BUG_ON(primary_ipic == NULL);
+
+#define IPIC_SIVCR_VECTOR_MASK 0x7f
+ irq = ipic_read(primary_ipic->regs, IPIC_SIVCR) & IPIC_SIVCR_VECTOR_MASK;
if (irq == 0) /* 0 --> no irq is pending */
- irq = -1;
+ return NO_IRQ;
- return irq;
+ return irq_linear_revmap(primary_ipic->irqhost, irq);
}
static struct sysdev_class ipic_sysclass = {
diff --git a/arch/powerpc/sysdev/ipic.h b/arch/powerpc/sysdev/ipic.h
index a60c9d1..c28e589 100644
--- a/arch/powerpc/sysdev/ipic.h
+++ b/arch/powerpc/sysdev/ipic.h
@@ -15,7 +15,18 @@ #define __IPIC_H__
#include <asm/ipic.h>
-#define MPC83xx_IPIC_SIZE (0x00100)
+#define NR_IPIC_INTS 128
+
+/* External IRQS */
+#define IPIC_IRQ_EXT0 48
+#define IPIC_IRQ_EXT1 17
+#define IPIC_IRQ_EXT7 23
+
+/* Default Priority Registers */
+#define IPIC_SIPRR_A_DEFAULT 0x05309770
+#define IPIC_SIPRR_D_DEFAULT 0x05309770
+#define IPIC_SMPRR_A_DEFAULT 0x05309770
+#define IPIC_SMPRR_B_DEFAULT 0x05309770
/* System Global Interrupt Configuration Register */
#define SICFR_IPSA 0x00010000
@@ -31,7 +42,15 @@ #define SERCR_MCPR 0x00000001
struct ipic {
volatile u32 __iomem *regs;
- unsigned int irq_offset;
+
+ /* The remapper for this IPIC */
+ struct irq_host *irqhost;
+
+ /* The "linux" controller struct */
+ struct irq_chip hc_irq;
+
+ /* The device node of the interrupt controller */
+ struct device_node *of_node;
};
struct ipic_info {
diff --git a/include/asm-powerpc/ipic.h b/include/asm-powerpc/ipic.h
index 0fe396a..3f55df4 100644
--- a/include/asm-powerpc/ipic.h
+++ b/include/asm-powerpc/ipic.h
@@ -69,9 +69,7 @@ enum ipic_mcp_irq {
IPIC_MCP_MU = 7,
};
-extern void ipic_init(phys_addr_t phys_addr, unsigned int flags,
- unsigned int irq_offset,
- unsigned char *senses, unsigned int senses_count);
+extern void ipic_init(struct device_node *node, unsigned int flags);
extern int ipic_set_priority(unsigned int irq, unsigned int priority);
extern void ipic_set_highest_priority(unsigned int irq);
extern void ipic_set_default_priority(void);
@@ -79,7 +77,7 @@ extern void ipic_enable_mcp(enum ipic_mc
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);
-extern int ipic_get_irq(struct pt_regs *regs);
+extern unsigned int ipic_get_irq(struct pt_regs *regs);
#endif /* __ASM_IPIC_H__ */
#endif /* __KERNEL__ */
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* [PATCH 2/3] Fix MPC834x SYS platform to get IRQ data from device tree and use new IRQ layer
From: Kim Phillips @ 2006-08-24 1:39 UTC (permalink / raw)
To: linuxppc-dev
This fixes MPC834x SYS platform code to get IRQ data (including PCI) from the device tree, and to use the new IPIC code.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
please apply to 2.6.18
arch/powerpc/platforms/83xx/mpc834x_sys.c | 58 +++++------------------------
arch/powerpc/platforms/83xx/mpc83xx.h | 1 +
arch/powerpc/platforms/83xx/pci.c | 10 +++++
3 files changed, 21 insertions(+), 48 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc834x_sys.c b/arch/powerpc/platforms/83xx/mpc834x_sys.c
index 5eadf9d..d864571 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_sys.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_sys.c
@@ -43,33 +43,6 @@ unsigned long isa_io_base = 0;
unsigned long isa_mem_base = 0;
#endif
-#ifdef CONFIG_PCI
-static int
-mpc83xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
-{
- static char pci_irq_table[][4] =
- /*
- * PCI IDSEL/INTPIN->INTLINE
- * A B C D
- */
- {
- {PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x11 */
- {PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x12 */
- {PIRQD, PIRQA, PIRQB, PIRQC}, /* idsel 0x13 */
- {0, 0, 0, 0},
- {PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x15 */
- {PIRQD, PIRQA, PIRQB, PIRQC}, /* idsel 0x16 */
- {PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x17 */
- {PIRQB, PIRQC, PIRQD, PIRQA}, /* idsel 0x18 */
- {0, 0, 0, 0}, /* idsel 0x19 */
- {0, 0, 0, 0}, /* idsel 0x20 */
- };
-
- const long min_idsel = 0x11, max_idsel = 0x20, irqs_per_slot = 4;
- return PCI_IRQ_TABLE_LOOKUP;
-}
-#endif /* CONFIG_PCI */
-
/* ************************************************************************
*
* Setup the architecture
@@ -96,8 +69,6 @@ #ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
add_bridge(np);
- ppc_md.pci_swizzle = common_swizzle;
- ppc_md.pci_map_irq = mpc83xx_map_irq;
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
#endif
@@ -110,25 +81,13 @@ #endif
void __init mpc834x_sys_init_IRQ(void)
{
- u8 senses[8] = {
- 0, /* EXT 0 */
- IRQ_SENSE_LEVEL, /* EXT 1 */
- IRQ_SENSE_LEVEL, /* EXT 2 */
- 0, /* EXT 3 */
-#ifdef CONFIG_PCI
- IRQ_SENSE_LEVEL, /* EXT 4 */
- IRQ_SENSE_LEVEL, /* EXT 5 */
- IRQ_SENSE_LEVEL, /* EXT 6 */
- IRQ_SENSE_LEVEL, /* EXT 7 */
-#else
- 0, /* EXT 4 */
- 0, /* EXT 5 */
- 0, /* EXT 6 */
- 0, /* EXT 7 */
-#endif
- };
-
- ipic_init(get_immrbase() + 0x00700, 0, 0, senses, 8);
+ struct device_node *np;
+
+ np = of_find_node_by_type(NULL, "ipic");
+ if (!np)
+ return;
+
+ ipic_init(np, 0);
/* Initialize the default interrupt mapping priorities,
* in case the boot rom changed something on us.
@@ -178,4 +137,7 @@ define_machine(mpc834x_sys) {
.time_init = mpc83xx_time_init,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
+#ifdef CONFIG_PCI
+ .pcibios_fixup = mpc83xx_pcibios_fixup,
+#endif
};
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index 01cae10..2c82bca 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -11,6 +11,7 @@ #include <linux/device.h>
extern int add_bridge(struct device_node *dev);
extern int mpc83xx_exclude_device(u_char bus, u_char devfn);
+extern void mpc83xx_pcibios_fixup(void);
extern void mpc83xx_restart(char *cmd);
extern long mpc83xx_time_init(void);
diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/platforms/83xx/pci.c
index 9c36505..ae12547 100644
--- a/arch/powerpc/platforms/83xx/pci.c
+++ b/arch/powerpc/platforms/83xx/pci.c
@@ -45,6 +45,16 @@ int mpc83xx_exclude_device(u_char bus, u
return PCIBIOS_SUCCESSFUL;
}
+void __init mpc83xx_pcibios_fixup(void)
+{
+ struct pci_dev *dev = NULL;
+
+ /* map all the PCI irqs */
+ dev = NULL;
+ for_each_pci_dev(dev)
+ pci_read_irq_line(dev);
+}
+
int __init add_bridge(struct device_node *dev)
{
int len;
--
2006_06_07.01.gittree_pull-dirty
^ 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