* RE: [PATCH] [POWERPC] Xilinx: add compatibility for IBMcoreconnect busses.
From: Stephen Neuendorffer @ 2008-05-08 16:15 UTC (permalink / raw)
To: David Gibson, Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080508033006.GH5156@yookeroo.seuss>
Hmm... sounds reasonable to me.
> -----Original Message-----
> From: =
linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of =
David
Gibson
> Sent: Wednesday, May 07, 2008 8:30 PM
> To: Josh Boyer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibility for
IBMcoreconnect busses.
>=20
> On Wed, May 07, 2008 at 09:46:30PM -0500, Josh Boyer wrote:
> > On Thu, 8 May 2008 10:18:50 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > On Wed, May 07, 2008 at 01:47:31PM -0700, Stephen Neuendorffer
wrote:
> > > > The IBM coreconnect names are pretty well defined, it appears.
In
> > > > addition, the Xilinx versions of these IPs seem to be
proliferating.
> > > > Hence, in the future let's prefer to use the standard names.
I've
> > > > left the old names in for some backward compatibility for
existing
> > > > device trees.
> > > >
> > > > Signed-off-by: Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com>
> > >
> > > If you're talking about future trees, can't you just slap
"simple-bus"
> > > on them avoid this monster id table?
> >
> > What is that and how does it work?
>=20
> ePAPR states that busses which cannot be probed as such (i.e. the
> device tree is the only way to figure out what's on the bus) should
> have "simple-bus" in their compatible property. You can then just add
> simple-bus to the of_bus_ids list and avoid adding umpteen other
things.
>=20
> --
> 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
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Predefined Compiler Flag for CROSS_COMPILE in ELDK
From: Detlev Zundel @ 2008-05-08 16:38 UTC (permalink / raw)
To: rodolfo; +Cc: linuxppc-embedded
In-Reply-To: <8b6b0af3278e2fe8a9355b1e053e1419@lesc.ufc.br>
Hi Rodolfo,
> -mcpu is deprecated:
>
> HOSTCC scripts/basic/fixdep
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> scripts/basic/fixdep.c:1: error: bad value (405) for -mtune= switch
> make[1]: ** [scripts/basic/fixdep] Erro 1
> make: ** [scripts_basic] Erro 2
Uhu - HOSTCC is the native compiler, which very likely does not know
anything about 405 cpus...
> then I put -march=405 and give this errors:
>
> scripts/basic/fixdep.c:1: error: bad value (405) for -march= switch
> scripts/basic/fixdep.c:1: error: bad value (405) for -mtune= switch
> make[1]: ** [scripts/basic/fixdep] Erro 1
> make: ** [scripts_basic] Erro 2
Still, same problem - you want to use the flag for the cross compiler.
> See a piece of my Makefile:
>
> HOSTCC = gcc
> HOSTCXX = g++
> HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
> -march=405
> HOSTCXXFLAGS = -O2
Again, this is the host compiler.
> How can I do this?
If we are only talking about compiling a recent linux kernel, then the
easiest way is to simply override CFLAGS_KERNEL from the commandline,
i.e.:
make CFLAGS_KERNEL=-mcpu=405 uImage
If you want to check that this works, do a
make CFLAGS_KERNEL=-mcpu=405 V=1 uImage
and check the generated command lines.
Cheers
Detlev
--
Alisa Sherer (AMD) suggested that consumer demand will not follow
faster clock speeds. Marketing might help with this problem, she
added. -- 2004/02/20
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* [PATCH] POWERPC: Get rid of leftover printk in isa-bridge.c
From: Nate Case @ 2008-05-08 16:41 UTC (permalink / raw)
To: kernel-janitors; +Cc: linuxppc-dev
This printk() appears twice in the same function. Only the latter one
in the inval_range: section appears to be legitimate.
Signed-off-by: Nate Case <ncase@xes-inc.com>
---
diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c
index ee172aa..e35092e 100644
--- a/arch/powerpc/kernel/isa-bridge.c
+++ b/arch/powerpc/kernel/isa-bridge.c
@@ -108,9 +108,6 @@ static void __devinit pci_process_ISA_OF_ranges(struct device_node *isa_node,
if (size > 0x10000)
size = 0x10000;
- printk(KERN_ERR "no ISA IO ranges or unexpected isa range, "
- "mapping 64k\n");
-
__ioremap_at(phb_io_base_phys, (void *)ISA_IO_BASE,
size, _PAGE_NO_CACHE|_PAGE_GUARDED);
return;
^ permalink raw reply related
* RE: xilinx linux on a XUPV2P
From: Stephen Neuendorffer @ 2008-05-08 17:24 UTC (permalink / raw)
To: Dr. Peter Hartmann, linuxppc-embedded
In-Reply-To: <48230682.8090000@delta.uni-dortmund.de>
Sounds like it's not finding the console.
If you're using the uartlite, you need to specify console=3DttyUL0 on =
the
kernel command line.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Dr. Peter
Hartmann
> Sent: Thursday, May 08, 2008 6:56 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: xilinx linux on a XUPV2P
>=20
> Hello everybody,
>=20
> I am trying to get the latest Kernel (2.6.25-rc9) from git.xilinx.com
running on
> a XUPV2P board. I generated the hardware using JH Kelms step by step
list,
> skipping points 6-8 and replacing point 9 by a more modern version of
doing
> this. When I boot the system.ace from the CF card, the bootloader
talks to me
> over the RS232, but as soon as it tries to boot the kernel it hangs
up.
> I had 2.6.18-rc3 which I got from somebody else running this way. The
reason I
> intend to change is the UARTLITE driver, which seems to be included in
the
> latest kernel tree.
> I use Platform Studio 9.1.02i which I also used for the 2.6.18 Kernel.
> Has anybody yet got this to work out with 9.1.02i ??
> Would it be possible for somebody to give a dummy like me the steps
you took to
> get it working on your board? I'm really lost here. Thanks!
>=20
>=20
> Thanks in advance!
^ permalink raw reply
* Re: [PATCH] Delete unused fec_8xx net driver
From: Vitaly Bordug @ 2008-05-08 17:25 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, jengelh, linuxppc-dev, scottwood
In-Reply-To: <48208790.5090508@pobox.com>
On Tue, May 06, 2008 at 12:30:08PM -0400, Jeff Garzik wrote:
> Becky Bruce wrote:
> >This driver has been superseded by fs_enet and is no longer in use.
> >
> >Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
>
> I cannot make an informed judgement on this.
>
> ACK, and pass through platform tree, if all platform peeps are happy.
I'll move thins along.
-Vitaly
^ permalink raw reply
* Re: mmap problem in device driver and application program.
From: Dave Cogley @ 2008-05-08 17:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY138-W55519F961B3A01D0B8A167B2D00@phx.gbl>
The address you are passing to mmap is where the pointer will be mapped
in virtual address space. You need to determine the DMA memory address
page number down in the actual mmap call.
int foo_mmap(struct file* filep, struct vm_area_struct* vma)
{
unsigned long dma_addr = 0x03000000;
unsigned long dma_size = 0x00200000;
unsigned long pfn;
// convert the DMA address to page number
pfn = virt_to_phys(dma_addr) >> PAGE_SHIFT;
// remap our page frame to the vma offset
remap_pfn_range(vma, vma->vm_start, pfn,
dma_size, vma->vm_page_prot);
}
Change the address parameter from 0x03000000 to 0:
lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE,
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
Dave
On Thu, 2008-05-08 at 15:33 +0000, MingLiu wrote:
> Dear all,
> I had some problem when I use mmap() file operation in the device
> driver file operation. My situation can be described as:
>
> 1. I reserve 2MB DDR memory as a look-up-table (LUT) for my customized
> device. The physical start address in the memory is 0x03000000 and the
> size is 2MB.
>
> 2. In the device driver, I use mmap file operation to make this memory
> area directly accessible by application programs. In the mmap file
> operation, it looks like:
>
> if(remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, vma->vm_end -
> vma->vm_start, vma->vm_page_prot)){
> return -EAGAIN;
> }
>
> 3. In the application program, I read from a file and initialize the
> LUT area. I use the following sentence to mmap the physical address
> into a virtual one which could be accessed by the application:
>
> // the physical address is from 0x03000000 with a size of
> LUT_SIZE_IN_BYTE equal to 2MB
> lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, PROT_READ
> | PROT_WRITE, MAP_SHARED, fd, 0x03000000);
>
> Then, I initialize the LUT area with the virtual address specified by
> lut_mem_base.
>
> for(i=0;;i++){
> fread(&buf, sizeof(unsigned int), 1, fp);
> *(lut_mem_base + i) = buf;
> if(feop(fp)){
> break;
> }
> }
>
> 4. After the initialization of the LUT memory area, in the device
> driver, DMA transfer will be enabled using the physical address of
> 0x03000000 as the source address. The destination is a register in my
> customized device. The data is fed from the memory to my device
> register.
>
> HOWEVER, I found that the data fed to the device register is not the
> same as the one used to initialize the LUT memory. Maybe the DMA
> fetches wrong data from different addresses and feeds to my device.
> Since this is my first time to use mmap, I am not self-confident to my
> program, both in the device driver and in the application. Is there
> anything wrong with my mmap part? I will appreciate so much if some
> experts could give me some hints. Thanks in advance.
>
> BR
> Ming
>
>
>
>
>
>
>
>
> ______________________________________________________________________
> Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使
> 用！
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
From: Stephen Neuendorffer @ 2008-05-08 18:25 UTC (permalink / raw)
To: dwg, jwboyer, grant.likely, linuxppc-dev
In-Reply-To: <20080508161529.65566FB805F@mail185-va3.bigfish.com>
ePAPR drafts propose 'simple-bus' as a generic compatibility type for
busses which cannot be probed for devices. In addition, the Xilinx
versions of these IPs seem to be proliferating. Hence, in the future
let's prefer to use the standard names. I've left the old names in
for short term backward compatibility for existing device trees.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
arch/powerpc/platforms/40x/virtex.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
index 6c72994..b1ab7b8 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -16,6 +16,7 @@
#include <asm/xilinx_intc.h>
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
+ { .compatible = "simple-bus", },
{ .compatible = "xlnx,plb-v46-1.00.a", },
{ .compatible = "xlnx,plb-v46-1.02.a", },
{ .compatible = "xlnx,plb-v34-1.01.a", },
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
From: Grant Likely @ 2008-05-08 18:27 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, dwg
In-Reply-To: <20080508182534.82DF2129805E@mail16-dub.bigfish.com>
On Thu, May 8, 2008 at 12:25 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> ePAPR drafts propose 'simple-bus' as a generic compatibility type for
> busses which cannot be probed for devices. In addition, the Xilinx
> versions of these IPs seem to be proliferating. Hence, in the future
> let's prefer to use the standard names. I've left the old names in
> for short term backward compatibility for existing device trees.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
I'll queue this up for .27
Cheers,
g.
> ---
> arch/powerpc/platforms/40x/virtex.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
> index 6c72994..b1ab7b8 100644
> --- a/arch/powerpc/platforms/40x/virtex.c
> +++ b/arch/powerpc/platforms/40x/virtex.c
> @@ -16,6 +16,7 @@
> #include <asm/xilinx_intc.h>
>
> static struct of_device_id xilinx_of_bus_ids[] __initdata = {
> + { .compatible = "simple-bus", },
> { .compatible = "xlnx,plb-v46-1.00.a", },
> { .compatible = "xlnx,plb-v46-1.02.a", },
> { .compatible = "xlnx,plb-v34-1.01.a", },
> --
> 1.5.3.4
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: mmap problem in device driver and application program.
From: MingLiu @ 2008-05-08 18:42 UTC (permalink / raw)
To: Dave Cogley, linuxppc-embedded
In-Reply-To: <1210266109.3755.8.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]
Dear Dave,
Thanks for your answer first. However I am very confused. It seems that I understand the memory-mapping-related functions completely wrong. Here comes more questions. > The address you are passing to mmap is where the pointer will be mapped> in virtual address space. You need to determine the DMA memory address> page number down in the actual mmap call.> > int foo_mmap(struct file* filep, struct vm_area_struct* vma)> {> unsigned long dma_addr = 0x03000000;> unsigned long dma_size = 0x00200000;> unsigned long pfn;> > // convert the DMA address to page number> pfn = virt_to_phys(dma_addr) >> PAGE_SHIFT;
Shall I use virt_to_phys? dma_addr is already exactly physical address which is used to initiate DMA transfers.
> // remap our page frame to the vma offset> remap_pfn_range(vma, vma->vm_start, pfn, > dma_size, vma->vm_page_prot);> }> > Change the address parameter from 0x03000000 to 0:> > lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, > PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
Previously I used "remap_page_range(vma, vma->vm_start, physical_addr, vm_size, vma->vm_page_prot)" in the device driver, where physical_addr is 0x03000000. In the application program, I used "lut_mem_base = (unsigned int *) mmap(0, LUT_SIZE_IN_BYTE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);". I think it is correct but it doesn't work. I heard that in the new kernels, remap_page_range is not supported any more. However when I compile the driver, nothing was shown to complain that. I am using 2.6.10 kernel. Any hint for this?
Thank you for your help to make me understand.
BR
Ming
_________________________________________________________________
Windows Live Photo gallery 数码相机的超级伴侣，轻松管理和编辑照片，还能制作全景美图！
http://get.live.cn/product/photo.html
[-- Attachment #2: Type: text/html, Size: 2162 bytes --]
^ permalink raw reply
* Re: How to link a .o with all modules
From: Sam Ravnborg @ 2008-05-08 20:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, lkml List
In-Reply-To: <5DD68A6B-45FD-4163-BDF5-356C70A00676@kernel.crashing.org>
On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote:
>
> On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote:
>
> >>>
> >>>
> >>>Let me know if this does address your question.
> >>
> >>The problem is MODPOST complains about undefined symbols:
> >>
> >> MODPOST 24 modules
> >>ERROR: "_restgpr_20_x" [net/key/af_key.ko] undefined!
> >>ERROR: "_restgpr_25_x" [net/key/af_key.ko] undefined!
> >>ERROR: "_restgpr_30_x" [net/key/af_key.ko] undefined!
> >
> >I need a bit more context to try to analyse this.
> >Where did you expect _restgpr_20_x to be defined.
> >If in vmlinux then were they present in the
> >Module.symvers file?
>
> No they aren't there since we I'm not EXPORT_SYMBOL() them. Should I
> also be doing EXPORT_SYMBOL?
So modpost claim it cannot find the symbols.
>
> >If in the linked in .o file - could you
> >see the symbols using objdump.
>
> Yes.
>
> readelf -a:
>
> ...
> Symbol table '.symtab' contains 113 entries:
> Num: Value Size Type Bind Vis Ndx Name
> ...
> 5: 00000000 0 FUNC GLOBAL DEFAULT 1 _savegpr_14
> 6: 00000000 0 FUNC GLOBAL DEFAULT 1 _save32gpr_14
> ...
Strange.
I did not look closer.
But it looks like the linker failed to resolve these symbols
in the final link somehow - despite the symbols are present in
the linked in .o file.
Can you try to drop me the output of the relocation records for the
finally linked .o file (the one with your .o file linked in).
objdump -r IIRC
Sam
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
From: Carl Love @ 2008-05-08 20:47 UTC (permalink / raw)
To: jroth, linux-kernel, linuxppc-dev, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <4822B03B.5060509@linux.vnet.ibm.com>
On Thu, 2008-05-08 at 09:48 +0200, Jochen Roth wrote:
> >> Unable to handle kernel paging request for data at address
> >> 0xd0000000004fe9a8
> >> Faulting instruction address: 0xd000000000330ad8
> >> cpu 0x0: Vector: 300 (Data Access) at [c00000003c337680]
> >> pc: d000000000330ad8: .alloc_cpu_buffers+0x7c/0x12c [oprofile]
> >> lr: d000000000330abc: .alloc_cpu_buffers+0x60/0x12c [oprofile]
> >> sp: c00000003c337900
> >> msr: 9000000000009032
> >> dar: d0000000004fe9a8
> >> dsisr: 42000000
> >> current = 0xc00000003e128600
> >> paca = 0xc0000000005b3480
> >> pid = 2356, comm = oprofiled
> >> enter ? for help
> >> [c00000003c3379a0] d0000000003302ac .oprofile_setup+0x2c/0x134 [oprofile]
> >> [c00000003c337a30] d00000000033176c .event_buffer_open+0x7c/0xc8 [oprofile]
> >> [c00000003c337ac0] c0000000000d6ca8 .__dentry_open+0x190/0x308
> >> [c00000003c337b70] c0000000000e7a5c .do_filp_open+0x3c4/0x8e8
> >> [c00000003c337d00] c0000000000d6a1c .do_sys_open+0x80/0x14c
> >> [c00000003c337db0] c0000000001192f4 .compat_sys_open+0x24/0x38
> >> [c00000003c337e30] c0000000000076b4 syscall_exit+0x0/0x40
> >> --- Exception: c01 (System Call) at 000000000ff006f8
> >> SP (ffc6f6a0) is in userspace
> >>
>
> Btw, I get this crash even without the patch applied. So it might be
> something unrelated. Shall I open a separate bugzilla for that?
>
> > A couple of things, first I am not finding a 2.6.25 Jeremy tree that you
> > refer to. The best that I see is a 2.6.23 tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/jermey/xen.git. Can you
> > either send me a location to get the jeremy tree you used or
> > tar/compress it an email it to me. A link would be preferred.
I pulled down the jeremy tree. I tried compiling and booting it. It
also crashes for me without my patch. The tree is clearly bad.
I looked at the jeremy tree. The oprofile code is different then the
Arnd tree. My patch is consistent with the code in Arnd's tree. The
oprofile cpu_buffer has been changed in the Jeremy tree from what is in
Arnd's tree.
It is my understanding that Arnd is the official CELL kernel maintainer.
I have no idea where the jeremy tree comes from. My patch was done
against the latest Arnd tree. I would recommend you use Arnd's tree.
Let me know if you find any issues with my patch with Arnd's tree.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jk/spufs.git
>
> >
> > I use Arnd's git tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/arnd/cell-2.6.git
>
> I'll clone Arnd's git and apply your patch.
>
> > The second thing is the function that you changed is used when adding a
> > sample to the CPU buffer. It is only called when OProfile is running.
> > The crash that you sent above looks like it occurred when the module was
> > loading since it failed in the alloc_cpu_buffer call. This would appear
> > to me to be completely separate from the oprofile_add_value() function.
> > The patch does make some changes in the oprofile arch specific sync init
> > code. Perhaps something is failing as part of the sync start
> > (drivers/oprofile/oprof.c) and resulting in the crash. There are no
> > buffer creation specific changes in the patch so I am puzzled by the
> > crash. I would like to see if I can reproduce the crash on my system.
> > I have a qs20. What are you running on?
> >
>
> Thanks for the explanation. It also crashed before applying your patch.
> I'm using a QS21.
>
> --
> Kind regards,
> Jochen
^ permalink raw reply
* Patch [Port fixmap from x86 and use for kmap_atomic] breaks dma_noncoherent.c
From: Gerhard Pircher @ 2008-05-08 20:45 UTC (permalink / raw)
To: linuxppc-dev
Hi,
The commit "[POWERPC] Port fixmap from x86 and use for kmap_atomic" breaks
dma-noncoherent.c, if highmem is enabled.
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -387,3 +388,25 @@ void kernel_map_pages(struct page *page, int numpages, int enable)
> change_page_attr(page, numpages, enable ? PAGE_KERNEL : __pgprot(0));
> }
> #endif /* CONFIG_DEBUG_PAGEALLOC */
> +
> +static int fixmaps;
> +unsigned long FIXADDR_TOP = 0xfffff000;
> +EXPORT_SYMBOL(FIXADDR_TOP);
> +
The address defined for FIXADDR_TOP seems to conflict with the address
defined by CONSISTENT_START (default 0xff100000). It triggers the
BUG_ON(!pte_none(*pte)) statement in __dma_alloc_coherent().
regards,
Gerhard
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
^ permalink raw reply
* Re: [PATCH v5] create modalias file in sysfs for bus of_platform
From: Olaf Hering @ 2008-05-08 21:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: sparclinux, linuxppc-dev
In-Reply-To: <20080424131600.GA15226@aepfle.de>
On Thu, Apr 24, Olaf Hering wrote:
> Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
> of modules. modalias files are already present for many other bus types.
> This adds also a newline to the devspec files.
>
> Also create a devspec file for mac-io devices. They were created as a side
> effect. Use correct buffer size for mac-io modalias buffer.
>
> Tested on iBook1 and Efika.
Did anyone test this on other systems, like sparc?
^ permalink raw reply
* [PATCH] POWERPC: Support ISA legacy addresses in of_address_to_resource()
From: Nate Case @ 2008-05-08 23:26 UTC (permalink / raw)
To: linuxppc-dev
When mapping an open firmware device tree node to a resource,
check if the device is on the "isa" legacy bus. In this case,
pci_address_to_pio() should not be used since that function is only
for addresses above the 64KB reserved region.
This was necessary to get IPMI working on a board that accesses
the IPMI controller via the legacy I/O region.
Signed-off-by: Nate Case <ncase@xes-inc.com>
---
arch/powerpc/kernel/prom_parse.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 90eb3a3..28d354d 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -622,7 +622,15 @@ static int __of_address_to_resource(struct device_node *dev, const u32 *addrp,
memset(r, 0, sizeof(struct resource));
if (flags & IORESOURCE_IO) {
unsigned long port;
- port = pci_address_to_pio(taddr);
+ struct device_node *parent;
+
+ parent = of_get_parent(dev);
+ if (of_bus_isa_match(parent))
+ port = (unsigned long) taddr;
+ else
+ port = pci_address_to_pio(taddr);
+ of_node_put(parent);
+
if (port == (unsigned long)-1)
return -EINVAL;
r->start = port;
--
1.5.4.4
^ permalink raw reply related
* Re: [PATCH] Delete unused fec_8xx net driver
From: Becky Bruce @ 2008-05-09 0:12 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: netdev, jengelh, linuxppc-dev, scottwood, Jeff Garzik
In-Reply-To: <20080508172519.GA12162@gate.crashing.org>
On May 8, 2008, at 12:25 PM, Vitaly Bordug wrote:
> On Tue, May 06, 2008 at 12:30:08PM -0400, Jeff Garzik wrote:
>> Becky Bruce wrote:
>>> This driver has been superseded by fs_enet and is no longer in use.
>>>
>>> Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
>>
>> I cannot make an informed judgement on this.
>>
>> ACK, and pass through platform tree, if all platform peeps are happy.
>
> I'll move thins along.
>
>
Great, thanks!
Cheers,
B
^ permalink raw reply
* lsprop patch for little endian
From: Benjamin Herrenschmidt @ 2008-05-09 0:14 UTC (permalink / raw)
To: linuxppc-dev list
I'm not sure who packages that, I think it's in powerpc-utils, anyway,
here's a patch that makes it work on device-tree tarballs lsprop'ed from
a LE machine.
--- /home/benh/grabbag/powerpc-utils-1.1.3/lsprop.c 2007-05-11 14:21:23.000000000 +1000
+++ lsprop.c 2008-05-09 10:13:49.000000000 +1000
@@ -7,10 +7,22 @@
*/
#include <stdio.h>
#include <stdlib.h>
+#include <string.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <dirent.h>
+#include <endian.h>
+#include <byteswap.h>
+
+static inline unsigned int dt_swap_int(unsigned int data)
+{
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+ return bswap_32(data);
+#else
+ return data;
+#endif
+}
int recurse;
int maxbytes = 128;
@@ -170,7 +182,7 @@
} else if ((n & 3) == 0) {
nw = n >> 2;
if (nw == 1) {
- i = *(int *)buf;
+ i = dt_swap_int(*(int *)buf);
printf(" %.8x", i);
if (i > -0x10000 && !(i >= 0 && i <= 9))
printf(" (%d)", i);
@@ -185,7 +197,7 @@
if (i != 0)
printf("\n\t\t");
for (j = 0; j < npl && i + j < nw; ++j)
- printf(" %.8x", ((unsigned int *)buf)[i+j]);
+ printf(" %.8x", dt_swap_int(((unsigned int *)buf)[i+j]));
}
}
} else {
^ permalink raw reply
* Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
From: Paul Mackerras @ 2008-05-09 3:15 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Andrew Morton, linux-next, kernel list
In-Reply-To: <4810231B.6020105@linux.vnet.ibm.com>
Kamalesh Babulal writes:
> Thanks, after applying the patch the oops is not reproducible on the machine. The console
> log had no message starting with SLB: or FWNMI:. I have updated the bugzilla also.
>
> Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Could you test Linus' current git tree and see if you can reproduce
the same problem now? The patch I sent upstream was a little
different from the one you tested, though it should have the same
effect, and I would like to be sure that it is just as effective at
fixing the bug.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] POWERPC: Support ISA legacy addresses in of_address_to_resource()
From: Benjamin Herrenschmidt @ 2008-05-09 4:31 UTC (permalink / raw)
To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1210289192.13845.281.camel@localhost.localdomain>
On Thu, 2008-05-08 at 18:26 -0500, Nate Case wrote:
> When mapping an open firmware device tree node to a resource,
> check if the device is on the "isa" legacy bus. In this case,
> pci_address_to_pio() should not be used since that function is only
> for addresses above the 64KB reserved region.
>
> This was necessary to get IPMI working on a board that accesses
> the IPMI controller via the legacy I/O region.
I don't understand that fix. Can you tell us more about the exact
failure mode ? Especially, show us the device-tree bits and the
addresses returned.
I suspect the bug is in your device-tree that is forwarding IO addresses
all the way without converting them to memory or something like that.
> Signed-off-by: Nate Case <ncase@xes-inc.com>
> ---
> arch/powerpc/kernel/prom_parse.c | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
> index 90eb3a3..28d354d 100644
> --- a/arch/powerpc/kernel/prom_parse.c
> +++ b/arch/powerpc/kernel/prom_parse.c
> @@ -622,7 +622,15 @@ static int __of_address_to_resource(struct device_node *dev, const u32 *addrp,
> memset(r, 0, sizeof(struct resource));
> if (flags & IORESOURCE_IO) {
> unsigned long port;
> - port = pci_address_to_pio(taddr);
> + struct device_node *parent;
> +
> + parent = of_get_parent(dev);
> + if (of_bus_isa_match(parent))
> + port = (unsigned long) taddr;
> + else
> + port = pci_address_to_pio(taddr);
> + of_node_put(parent);
> +
> if (port == (unsigned long)-1)
> return -EINVAL;
> r->start = port;
^ permalink raw reply
* Re: [PATCH] POWERPC: Get rid of leftover printk in isa-bridge.c
From: Benjamin Herrenschmidt @ 2008-05-09 4:31 UTC (permalink / raw)
To: Nate Case; +Cc: linuxppc-dev, kernel-janitors
In-Reply-To: <1210264877.13845.274.camel@localhost.localdomain>
On Thu, 2008-05-08 at 11:41 -0500, Nate Case wrote:
> This printk() appears twice in the same function. Only the latter one
> in the inval_range: section appears to be legitimate.
>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
Ack.
^ permalink raw reply
* Re: [PATCH] Add null pointer check to of_find_property
From: Paul Mackerras @ 2008-05-09 4:50 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <1210202466.16180.1.camel@localhost>
Michael Ellerman writes:
> On Wed, 2008-05-07 at 14:19 -0500, Timur Tabi wrote:
> > Update function of_find_property() to return NULL if the device_node passed
> > to it is also NULL. Otherwise, passing NULL will cause a null pointer
> > dereference.
> >
> > Signed-off-by: Timur Tabi <timur@freescale.com>
> > ---
> >
> > This patch allows callers to do this:
>
> np = of_find_compatible_node(...);
> prop = of_get_property(np);
> if (!prop)
> goto error;
>
> ...
>
> error:
> of_node_put(np)
>
> :)
And of_node_put looks like this:
void of_node_put(struct device_node *node)
{
if (node)
kref_put(&node->kref, of_node_release);
}
so it's OK.
:)
Paul.
^ permalink raw reply
* Re: [PATCH]: PPC_OF protect USB driver...
From: Paul Mackerras @ 2008-05-09 5:27 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080505.005715.215572318.davem@davemloft.net>
David Miller writes:
> This uses APIs that are not generic, or at least not part of
> what Sparc provides yet.
>
> So just PPC_OF this for now just like the EHCI_OF driver.
>
> This fixes allmodconfig build errors on sparc.
Are you going to send this to the USB maintainers, or are you going to
merge it to Linus, or do you want me to?
Paul.
^ permalink raw reply
* Re: [PATCH]: PPC_OF protect USB driver...
From: David Miller @ 2008-05-09 5:51 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <18467.57545.798170.20885@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Fri, 9 May 2008 15:27:37 +1000
> David Miller writes:
>
> > This uses APIs that are not generic, or at least not part of
> > what Sparc provides yet.
> >
> > So just PPC_OF this for now just like the EHCI_OF driver.
> >
> > This fixes allmodconfig build errors on sparc.
>
> Are you going to send this to the USB maintainers, or are you going to
> merge it to Linus, or do you want me to?
It is in Linus's tree after a sparc push I sent to him yesterday.
Thanks Paul.
^ permalink raw reply
* [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Jason Jin @ 2008-05-09 9:03 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Jason Jin
Binding document adding for Freescale MSI support.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
Updated to V2 version per Segher's suggestion.
Documentation/powerpc/booting-without-of.txt | 40 +++++++++++++++++++++++++-
1 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 1d2a772..887783c 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -57,7 +57,10 @@ Table of Contents
n) 4xx/Axon EMAC ethernet nodes
o) Xilinx IP cores
p) Freescale Synchronous Serial Interface
- q) USB EHCI controllers
+ q) USB EHCI controllers
+ r) Freescale Display Interface Unit
+ s) Freescale on board FPGA
+ t) Freescael MSI interrupt controller
VII - Marvell Discovery mv64[345]6x System Controller chips
1) The /system-controller node
@@ -2870,6 +2873,41 @@ platforms are moved over to use the flattened-device-tree model.
reg = <0xe8000000 32>;
};
+ t) Freescale MSI interrupt controller
+
+ Reguired properities:
+ - compatible : set as "fsl,86xx-MSI" for 86xx cpu, "fsl,85xx-MSI" for 85xx
+ cpu and "fsl,83xx-MSI" for 83xx cpu.
+ - reg : should contain the address and the length of the shared message
+ interrupt register set.
+ - msi-available-ranges: use <start count> style section to define which
+ msi interrupt can be used in the 256 msi interrupts.
+ - interrupts : each one of the interrupts here is one entry per 32 MSIs,
+ and routed to the host interrupt controller. the interrupts should
+ be set as edge sensitive.
+ - interrupt-parent: the phandle for the interrupt controller
+ that services interrupts for this device. for 83xx cpu, the interrupts
+ are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed
+ to MPIC.
+
+ Example (86xx CPU)
+ msi@41600 {
+ compatible = "fsl,86xx-MSI";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
+
VII - Marvell Discovery mv64[345]6x System Controller chips
===========================================================
--
1.5.4
^ permalink raw reply related
* [PATCH 2/4 V4] MSI support on 83xx/85xx/86xx board
From: Jason Jin @ 2008-05-09 9:03 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Jason Jin
In-Reply-To: <1210323810-24833-1-git-send-email-Jason.jin@freescale.com>
This MSI driver can be used on 83xx/85xx/86xx board.
In this driver, virtual interrupt host and chip were
setup. There are 256 MSI interrupts in this host, Every 32
MSI interrupts cascaded to one IPIC/MPIC interrupt.
The chip was treated as edge sensitive and some necessary
functions were setup for this chip.
Before using the MSI interrupt, PCI/PCIE device need to
ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
bitmap show which MSI interrupt was used, reserve bit in
the bitmap can be used to force the device use some designate
MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
for testing the all the MSI interrupts. The msi-available-ranges
property in the dts file was used for this purpose.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
Update to V4 version per the suggestion's from Michael Ellerman
arch/powerpc/sysdev/Makefile | 3 +-
arch/powerpc/sysdev/fsl_msi.c | 446 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_msi.h | 42 ++++
arch/powerpc/sysdev/fsl_pci.c | 14 ++
4 files changed, 504 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_msi.c
create mode 100644 arch/powerpc/sysdev/fsl_msi.h
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 6d386d0..98b6b8e 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,7 @@ endif
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+fsl-msi-obj-$(CONFIG_PCI_MSI) += fsl_msi.o
obj-$(CONFIG_PPC_MPC106) += grackle.o
obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
@@ -11,7 +12,7 @@ obj-$(CONFIG_PPC_PMI) += pmi.o
obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
-obj-$(CONFIG_FSL_PCI) += fsl_pci.o
+obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
new file mode 100644
index 0000000..be3304d
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -0,0 +1,446 @@
+/*
+ * Copyright (C) 2007-2008 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Tony Li <tony.li@freescale.com>
+ * Jason Jin <Jason.jin@freescale.com>
+ *
+ * The hwirq alloc and free code reuse from sysdev/mpic_msi.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+#include <linux/irq.h>
+#include <linux/bootmem.h>
+#include <linux/bitmap.h>
+#include <linux/msi.h>
+#include <linux/pci.h>
+#include <linux/of_platform.h>
+#include <sysdev/fsl_soc.h>
+#include <asm/prom.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+#include "fsl_msi.h"
+
+struct fsl_msi_feature {
+ u32 fsl_pic_ip;
+ u32 msiir_offset;
+};
+
+static struct fsl_msi *fsl_msi;
+
+static inline u32 fsl_msi_read(u32 __iomem *base, unsigned int reg)
+{
+ return in_be32(base + (reg >> 2));
+}
+
+static inline void fsl_msi_write(u32 __iomem *base,
+ unsigned int reg, u32 value)
+{
+ out_be32(base + (reg >> 2), value);
+}
+
+/*
+ * We do not need this actually. The MSIR register has been read once
+ * in the cascade interrupt. So, this MSI interrupt has been acked
+*/
+static void fsl_msi_end_irq(unsigned int virq)
+{
+}
+
+static struct irq_chip fsl_msi_chip = {
+ .mask = mask_msi_irq,
+ .unmask = unmask_msi_irq,
+ .ack = fsl_msi_end_irq,
+ .typename = " FSL-MSI ",
+};
+
+static int fsl_msi_host_match(struct irq_host *h, struct device_node *node)
+{
+ /* Exact match*/
+ return h->of_node == node;
+}
+
+
+static int fsl_msi_host_map(struct irq_host *h, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ struct irq_chip *chip = &fsl_msi_chip;
+
+ get_irq_desc(virq)->status |= IRQ_TYPE_EDGE_FALLING;
+
+ set_irq_chip_and_handler(virq, chip, handle_edge_irq);
+
+ return 0;
+}
+
+static struct irq_host_ops fsl_msi_host_ops = {
+ .match = fsl_msi_host_match,
+ .map = fsl_msi_host_map,
+};
+
+irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
+{
+ unsigned long flags;
+ int offset, order = get_count_order(num);
+
+ spin_lock_irqsave(&msi->bitmap_lock, flags);
+
+ offset = bitmap_find_free_region(msi->fsl_msi_bitmap,
+ NR_MSI_IRQS, order);
+
+ spin_unlock_irqrestore(&msi->bitmap_lock, flags);
+
+ pr_debug("%s: allocated 0x%x (2^%d) at offset 0x%x\n",
+ __func__, num, order, offset);
+
+ return offset;
+}
+
+void fsl_msi_free_hwirqs(struct fsl_msi *msi, int offset, int num)
+{
+ unsigned long flags;
+ int order = get_count_order(num);
+
+ pr_debug("%s: freeing 0x%x (2^%d) at offset 0x%x\n",
+ __func__, num, order, offset);
+
+ spin_lock_irqsave(&msi->bitmap_lock, flags);
+ bitmap_release_region(msi->fsl_msi_bitmap, offset, order);
+ spin_unlock_irqrestore(&msi->bitmap_lock, flags);
+}
+
+static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
+{
+ int i, len;
+ const u32 *p;
+
+ p = of_get_property(msi->of_node, "msi-available-ranges", &len);
+ if (!p) {
+ pr_debug("fsl_msi: no msi-available-ranges property found \
+ on %s\n", msi->of_node->full_name);
+ return -ENODEV;
+ }
+
+ if ((len % 0x8) != 0) {
+ printk(KERN_WARNING "fsl_msi: Malformed msi-available-ranges "
+ "property on %s\n", msi->of_node->full_name);
+ return -EINVAL;
+ }
+
+ bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
+ get_count_order(NR_MSI_IRQS));
+
+ /* Format is: (<u32 start> <u32 count>)+ */
+ len /= sizeof(u32);
+ len /= 2;
+ for (i = 0; i < len; i++, p += 2)
+ fsl_msi_free_hwirqs(msi, *p, *(p + 1));
+
+ return 0;
+}
+
+static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
+{
+ int rc, size;
+
+ size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(u32);
+
+ msi_data->fsl_msi_bitmap = kzalloc(size, GFP_KERNEL);
+
+ if (msi_data->fsl_msi_bitmap == NULL) {
+ pr_debug("%s: ENOMEM allocating allocator bitmap!\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ rc = fsl_msi_free_dt_hwirqs(msi_data);
+ if (rc)
+ goto out_free;
+
+ return 0;
+out_free:
+ kfree(msi_data->fsl_msi_bitmap);
+
+ msi_data->fsl_msi_bitmap = NULL;
+ return rc;
+
+}
+
+static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
+{
+ if (type == PCI_CAP_ID_MSIX)
+ pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
+
+ return 0;
+}
+
+static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
+{
+ struct msi_desc *entry;
+ struct fsl_msi *msi_data = fsl_msi;
+
+ list_for_each_entry(entry, &pdev->msi_list, list) {
+ if (entry->irq == NO_IRQ)
+ continue;
+ set_irq_msi(entry->irq, NULL);
+ fsl_msi_free_hwirqs(msi_data, virq_to_hw(entry->irq), 1);
+ irq_dispose_mapping(entry->irq);
+ }
+
+ return;
+}
+
+static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
+ struct msi_msg *msg)
+{
+ struct fsl_msi *msi_data = fsl_msi;
+
+ msg->address_lo = msi_data->msi_addr_lo;
+ msg->address_hi = msi_data->msi_addr_hi;
+ msg->data = hwirq;
+
+ pr_debug("%s: allocated srs: %d, ibs: %d\n",
+ __func__, hwirq / IRQS_PER_MSI_REG, hwirq % IRQS_PER_MSI_REG);
+}
+
+static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
+{
+ irq_hw_number_t hwirq;
+ int rc;
+ unsigned int virq;
+ struct msi_desc *entry;
+ struct msi_msg msg;
+ struct fsl_msi *msi_data = fsl_msi;
+
+ list_for_each_entry(entry, &pdev->msi_list, list) {
+ hwirq = fsl_msi_alloc_hwirqs(msi_data, 1);
+ if (hwirq < 0) {
+ rc = hwirq;
+ pr_debug("%s: fail allocating msi interrupt\n",
+ __func__);
+ goto out_free;
+ }
+
+ virq = irq_create_mapping(msi_data->irqhost, hwirq);
+
+ if (virq == NO_IRQ) {
+ pr_debug("%s: fail mapping hwirq 0x%lx\n",
+ __func__, hwirq);
+ fsl_msi_free_hwirqs(msi_data, hwirq, 1);
+ rc = -ENOSPC;
+ goto out_free;
+ }
+ set_irq_msi(virq, entry);
+
+ fsl_compose_msi_msg(pdev, hwirq, &msg);
+ write_msi_msg(virq, &msg);
+ }
+ return 0;
+
+out_free:
+ return rc;
+}
+
+void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq;
+ struct fsl_msi *msi_data = fsl_msi;
+ int msir_index = -1;
+ u32 msir_value = 0;
+ u32 intr_index;
+ u32 have_shift = 0;
+
+ spin_lock(&desc->lock);
+ if ((msi_data->feature & FSL_PIC_IP_MASK) == FSL_PIC_IP_IPIC) {
+ if (desc->chip->mask_ack)
+ desc->chip->mask_ack(irq);
+ else {
+ desc->chip->mask(irq);
+ desc->chip->ack(irq);
+ }
+ }
+
+ if (unlikely(desc->status & IRQ_INPROGRESS))
+ goto unlock;
+
+ msir_index = (int)(desc->handler_data);
+
+ if (msir_index >= NR_MSI_REG)
+ cascade_irq = NO_IRQ;
+
+ desc->status |= IRQ_INPROGRESS;
+ switch (fsl_msi->feature & FSL_PIC_IP_MASK) {
+ case FSL_PIC_IP_MPIC:
+ msir_value = fsl_msi_read(msi_data->msi_regs,
+ msir_index * 0x10);
+ break;
+ case FSL_PIC_IP_IPIC:
+ msir_value = fsl_msi_read(msi_data->msi_regs, msir_index * 0x4);
+ break;
+ }
+
+ while (msir_value) {
+ intr_index = ffs(msir_value) - 1;
+
+ cascade_irq = irq_linear_revmap(msi_data->irqhost,
+ (msir_index * IRQS_PER_MSI_REG +
+ intr_index + have_shift));
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+ have_shift += (intr_index + 1);
+ msir_value = (msir_value >> (intr_index + 1));
+ }
+ desc->status &= ~IRQ_INPROGRESS;
+
+ switch (msi_data->feature & FSL_PIC_IP_MASK) {
+ case FSL_PIC_IP_MPIC:
+ desc->chip->eoi(irq);
+ break;
+ case FSL_PIC_IP_IPIC:
+ if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+ desc->chip->unmask(irq);
+ break;
+ }
+unlock:
+ spin_unlock(&desc->lock);
+}
+
+static int __devinit fsl_of_msi_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ struct fsl_msi *msi;
+ struct resource res;
+ int err, i, count;
+ int rc;
+ int virt_msir;
+ const u32 *p;
+ struct fsl_msi_feature *tmp_data;
+
+ printk(KERN_DEBUG "Setting up fsl msi support\n");
+
+ msi = kzalloc(sizeof(struct fsl_msi), GFP_KERNEL);
+ if (!msi) {
+ dev_err(&dev->dev, "No memory for MSI structure\n");
+ err = -ENOMEM;
+ goto error_out;
+ }
+
+ msi->of_node = dev->node;
+
+ msi->irqhost = irq_alloc_host(of_node_get(dev->node),
+ IRQ_HOST_MAP_LINEAR,
+ NR_MSI_IRQS, &fsl_msi_host_ops, 0);
+ if (msi->irqhost == NULL) {
+ dev_err(&dev->dev, "No memory for MSI irqhost\n");
+ of_node_put(dev->node);
+ err = -ENOMEM;
+ goto error_out;
+ }
+
+ /* Get the MSI reg base */
+ err = of_address_to_resource(dev->node, 0, &res);
+ if (err) {
+ dev_err(&dev->dev, "%s resource error!\n",
+ dev->node->full_name);
+ goto error_out;
+ }
+
+ msi->msi_regs = ioremap(res.start, res.end - res.start + 1);
+ if (!msi->msi_regs) {
+ dev_err(&dev->dev, "ioremap problem failed\n");
+ goto error_out;
+ }
+
+ tmp_data = (struct fsl_msi_feature *)match->data;
+
+ msi->feature = tmp_data->fsl_pic_ip;
+
+ msi->irqhost->host_data = msi;
+
+ msi->msi_addr_hi = 0x0;
+ msi->msi_addr_lo = res.start + tmp_data->msiir_offset;
+
+ rc = fsl_msi_init_allocator(msi);
+ if (rc) {
+ dev_err(&dev->dev, "Error allocating MSI bitmap\n");
+ goto error_out;
+ }
+
+ p = of_get_property(dev->node, "interrupts", &count);
+ if (!p) {
+ dev_err(&dev->dev, "no interrupts property found on %s\n",
+ dev->node->full_name);
+ err = -ENODEV;
+ goto error_out;
+ }
+ if (count % 8 != 0) {
+ dev_err(&dev->dev, "Malformed interrupts property on %s\n",
+ dev->node->full_name);
+ err = -EINVAL;
+ goto error_out;
+ }
+
+ count /= sizeof(u32);
+ for (i = 0; i < count / 2; i++) {
+ if (i > NR_MSI_REG)
+ break;
+ virt_msir = irq_of_parse_and_map(dev->node, i);
+ if (virt_msir != NO_IRQ) {
+ set_irq_data(virt_msir, (void *)i);
+ set_irq_chained_handler(virt_msir, fsl_msi_cascade);
+ }
+ }
+
+ fsl_msi = msi;
+
+ WARN_ON(ppc_md.setup_msi_irqs);
+ ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
+ ppc_md.msi_check_device = fsl_msi_check_device;
+ return 0;
+error_out:
+ kfree(msi);
+ return err;
+}
+
+static const struct fsl_msi_feature mpic_msi_feature = {
+ .fsl_pic_ip = FSL_PIC_IP_MPIC,
+ .msiir_offset = 0x140,
+};
+
+static const struct fsl_msi_feature ipic_msi_feature = {
+ .fsl_pic_ip = FSL_PIC_IP_IPIC,
+ .msiir_offset = 0x38,
+};
+
+static const struct of_device_id fsl_of_msi_ids[] = {
+ {
+ .compatible = "fsl,86xx-MSI",
+ .data = (void *)&mpic_msi_feature,
+ },
+ {
+ .compatible = "fsl,85xx-MSI",
+ .data = (void *)&mpic_msi_feature,
+ },
+ {
+ .compatible = "fsl,83xx-MSI",
+ .data = (void *)&ipic_msi_feature,
+ },
+ {}
+};
+
+static struct of_platform_driver fsl_of_msi_driver = {
+ .name = "fsl-of-msi",
+ .match_table = fsl_of_msi_ids,
+ .probe = fsl_of_msi_probe,
+};
+
+static __init int fsl_of_msi_init(void)
+{
+ return of_register_platform_driver(&fsl_of_msi_driver);
+}
+
+subsys_initcall(fsl_of_msi_init);
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
new file mode 100644
index 0000000..a653468
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2007-2008 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Tony Li <tony.li@freescale.com>
+ * Jason Jin <Jason.jin@freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+#ifndef _POWERPC_SYSDEV_FSL_MSI_H
+#define _POWERPC_SYSDEV_FSL_MSI_H
+
+#define NR_MSI_REG 8
+#define IRQS_PER_MSI_REG 32
+#define NR_MSI_IRQS (NR_MSI_REG * IRQS_PER_MSI_REG)
+
+#define FSL_PIC_IP_MASK 0x0000000F
+#define FSL_PIC_IP_MPIC 0x00000001
+#define FSL_PIC_IP_IPIC 0x00000002
+
+struct fsl_msi {
+ /* Device node of the MSI interrupt*/
+ struct device_node *of_node;
+
+ struct irq_host *irqhost;
+
+ unsigned long cascade_irq;
+
+ u32 msi_addr_lo;
+ u32 msi_addr_hi;
+ void __iomem *msi_regs;
+ u32 feature;
+
+ unsigned long *fsl_msi_bitmap;
+ spinlock_t bitmap_lock;
+};
+
+#endif /* _POWERPC_SYSDEV_FSL_MSI_H */
+
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index bf13c21..fede767 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -106,6 +106,16 @@ void __init setup_pci_cmd(struct pci_controller *hose)
}
}
+#ifdef CONFIG_PCI_MSI
+void __init setup_pci_pcsrbar(struct pci_controller *hose)
+{
+ phys_addr_t immr_base;
+
+ immr_base = get_immrbase();
+ early_write_config_dword(hose, 0, 0, PCI_BASE_ADDRESS_0, immr_base);
+}
+#endif
+
static int fsl_pcie_bus_fixup;
static void __init quirk_fsl_pcie_header(struct pci_dev *dev)
@@ -211,6 +221,10 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
/* Setup PEX window registers */
setup_pci_atmu(hose, &rsrc);
+ /*Setup PEXCSRBAR */
+#ifdef CONFIG_PCI_MSI
+ setup_pci_pcsrbar(hose);
+#endif
return 0;
}
--
1.5.4
^ permalink raw reply related
* [PATCH 3/4 V2] Enable MSI support for MPC8610HPCD board
From: Jason Jin @ 2008-05-09 9:13 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Jason Jin
This patch enable the MSI on 8610hpcd board.
Through the msi-available-ranges property, All the 256
msi interrupts can be tested on this board.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
compatible name in dts was changed in V2 version.
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 16 ++++++++++++++++
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 6 +++++-
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index bba234e..93e681b 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -128,6 +128,22 @@
big-endian;
};
+ msi@41600 {
+ compatible = "fsl,86xx-MSI";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
global-utilities@e0000 {
compatible = "fsl,mpc8610-guts";
reg = <0xe0000 0x1000>;
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 5e1e8cf..59f75f7 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -70,9 +70,13 @@ static void __init mpc86xx_hpcd_init_irq(void)
/* Alloc mpic structure and per isu has 16 INT entries. */
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
- 0, 256, " MPIC ");
+ 64, 256, " MPIC ");
BUG_ON(mpic1 == NULL);
+ mpic_assign_isu(mpic1, 0, res.start + 0x10000);
+ mpic_assign_isu(mpic1, 1, res.start + 0x10800);
+ mpic_assign_isu(mpic1, 2, res.start + 0x11600);
+
mpic_init(mpic1);
}
--
1.5.4
^ permalink raw reply related
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