Re: Maximum ioremap size for ppc arch?
On Mon, Dec 03, 2007 at 09:22:06AM -, [EMAIL PROTECTED] wrote: I'm trying to get am MPC834x system running that has 256MBytes of NOR flash connected. The physmap flash driver is failing to ioremap() that amount of space, while on a similar system with 128Mbytes of flash, there are no problems. Is this a known limitation of ioremap() on the ppc architecture, or specifically the MPC834x family, and is there any (hopefully easy) way to increase this limit? The answer is it depends. It depends on the amount of system memory you have. By default, your system memory is mapped at 0xc000, leaving not enough space for vmalloc allocations to grab 256MB for the ioremap (and avoid the fixed virtual mapping in the high virtual address area). See the Advanced setup menu. Normally, you can set Set custom kernel base address to 0xa000 safely. That will give you an additional 256MB of vmalloc space. On arch/powerpc, you'll also have to set Size of user task space to 0x8000 or 0xa000. -Matt ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/1] PPC32 : Huge-page support for ppc440
On Tue, Nov 07, 2006 at 02:45:22PM +1100, Benjamin Herrenschmidt wrote: On Mon, 2006-11-06 at 19:26 -0800, Roland Dreier wrote: Also, while it's great to have somebody do this work, I doubt there is much interest in merging it for arch/ppc... On that subject, what's the latest on moving ppc4xx to arch/powerpc? At the kernel summit you told me to chill out and wait, but I'll repeat my offer to help out Well, I told you that Matt Porter was about to do it :-) Now I haven't heard from him since. Feel free to jump in, just make sure you keep in sync with Josh and Matt. Er, wait a minute. :) I did some work then got busy again. I handed my starting point stuff to Josh who has been continuing on with some work. So there is progress happening there on the basic enablement, that is, outside of your contributions on mmio dcr handling etc. -Matt ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1302 driver for powerpc
On Wed, Aug 30, 2006 at 07:54:16PM +0800, Chun Chung Lo wrote: Hi all, I am now doing a STB project and the development board uses a DS1302 (trickle charge timekeeping chip) as a RTC. Our board is a IBM PPC405EP with a linux kernel 2.4.20 running on it. And the DS1302 is controlled by 2 GPIO pins instead of I2C. I would like to ask are there any porting of DS1302 support under ppc architecture? (I can only find DS1302 is supported under cris architecture.) There doesn't seem to be any DS1302 support for ppc available. However, even if there were a platform with DS1302 support you'd be in the same boat as the low-level support for cris. Support for DS1302 has a glue layer that's board-specific based on what GPIO pins are used to drive it. So if you had this driver for another PPC system like 83xx you'd still have no better starting point than the cris ds1302 driver glue since the GPIO mechanism/connection is different. Porting the board-specific glue from arch/cris/drivers/ds1302.c to 4xx GPIO is trivial to do though. -Matt ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1302 driver for powerpc
On Thu, Aug 31, 2006 at 08:51:22AM +0800, Chun Chung Lo wrote: Hi, Thanks for your help. But I also do not have this driver for 83xx. (as my linux is comes from Montavista) The 83xx reference was a hypothetical. There is no 83xx driver for the ds1302. Could you mind providing me a link / or a source of such driver for me to reference ? My advice is to port the cris DS1302 driver to your board-specific GPIO configuration. -Matt ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
DS1302 driver for powerpc
On Wed, Aug 30, 2006 at 07:54:16PM +0800, Chun Chung Lo wrote: Hi all, I am now doing a STB project and the development board uses a DS1302 (trickle charge timekeeping chip) as a RTC. Our board is a IBM PPC405EP with a linux kernel 2.4.20 running on it. And the DS1302 is controlled by 2 GPIO pins instead of I2C. I would like to ask are there any porting of DS1302 support under ppc architecture? (I can only find DS1302 is supported under cris architecture.) There doesn't seem to be any DS1302 support for ppc available. However, even if there were a platform with DS1302 support you'd be in the same boat as the low-level support for cris. Support for DS1302 has a glue layer that's board-specific based on what GPIO pins are used to drive it. So if you had this driver for another PPC system like 83xx you'd still have no better starting point than the cris ds1302 driver glue since the GPIO mechanism/connection is different. Porting the board-specific glue from arch/cris/drivers/ds1302.c to 4xx GPIO is trivial to do though. -Matt
Driver for OCP Driver for PPC405
On Wed, Aug 30, 2006 at 09:42:05PM +0530, akhilesh at innomedia.soft.net wrote: Hi, I need a OCP IDE driver for IBM PPC405 redwood6 platform for 2.6 kernel. Any pointer for same or similar driver would be highly appreciated. List archives are your friend. http://ozlabs.org/pipermail/linuxppc-embedded/2005-February/016715.html Read the whole thread...there's a patch that applies to linuxppc-2.5 (and the location to rsync that old tree) in a later mail. It didn't go upstream because the author didn't clean up some minor things needed for upstream inclusion. -Matt
DS1302 driver for powerpc
On Thu, Aug 31, 2006 at 08:51:22AM +0800, Chun Chung Lo wrote: Hi, Thanks for your help. But I also do not have this driver for 83xx. (as my linux is comes from Montavista) The 83xx reference was a hypothetical. There is no 83xx driver for the ds1302. Could you mind providing me a link / or a source of such driver for me to reference ? My advice is to port the cris DS1302 driver to your board-specific GPIO configuration. -Matt
2 Ethernet port operating in a PPC405EP system
On Wed, Aug 30, 2006 at 01:23:03PM -0500, Otto Solares wrote: Don't repeat the same mistake as the MediaMVP, it uses the same processor and same kernel version, it sucks badly... FWIW, MediaMVP doesn't use the same processor. It has an STBx25xx which is quite different from a 405EP. It is the same 405 core at least. -Matt
ARCH=ppc or ARCH=powerpc
On Thu, Aug 24, 2006 at 02:58:15PM +0200, Benjamin Delagoutte wrote: Le jeudi 24 ao?t 2006 ? 07:49 -0500, Josh Boyer a ?crit : On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote: ppc = 32bit. powerpc= 64bit. Correct me if I am wrong. Yes, you're wrong. Some 32 bit boards are also under arch/powerpc now. I am not sure why community didn't adopt the name ppc and ppc64 just like ia-32 and ia64. They did originally. The new direction is to have everything under arch/powerpc, both 32 and 64 bit. The reason arch/ppc still exists is because some 32 bit platforms have not been fully migrated to the requirements to be merged into arch/powerpc. Namely, the code has to boot from an OpenFirmware like flattened device tree. The PPC 4xx family of processors, as an example, does not do this yet though there is work going on to adapt it. I'm currently working on a PPC 405 based developement card. Does it mean I have to work using the arch/ppc tree ? PPC405 is only supported in the arch/ppc tree currenty. Unless you want to contribute to the effort to move to arch/powerpc, you'll have to work with arch/ppc/ What about the includes ? Do I have to use only include/asm-ppc or are include/asm-powerpc necessary as well ? When you do an arch/ppc build it automagically includes shared includes from asm-powerpc as necessary. There's nothing to worry about there. The goal is to have the new 4xx arch/powerpc support not break 4xx arch/ppc support. So as boards are merged and verified working, we'll remove the equivalent support from arch/ppc... Some boards/chips may just die if no maintainer step up to port them over...but all the important stuff should get an interested party once we get the initial 4xx support in arch/powerpc working. -Matt
ARCH=ppc or ARCH=powerpc
On Thu, Aug 24, 2006 at 08:07:20AM -0500, Josh Boyer wrote: On Thu, 2006-08-24 at 14:58 +0200, Benjamin Delagoutte wrote: What about the includes ? Do I have to use only include/asm-ppc or are include/asm-powerpc necessary as well ? I believe there are some hacks in the makefiles to pull common asm files from include/asm-powerpc when needed. Basically, you should be able to just do: #include asm/foo.h and it should work. If you're adding new .h files, I suppose asm-ppc is the place to add them for now. That's just my opinion though :) That's what I would recommend too. If this is for an out-of-tree custom port then there's no real concern anyway. -Matt
ioremap() fails for 64 MB
On Thu, Aug 24, 2006 at 10:54:23AM +0800, alva wrote: I think 64MB limitation of ioremap() is due to the kernel's page size. When compiling kernel, it has an option to choose the memory page size which is default 64MB. To use memory greater than 64MB, there is two methods. One is to make the kernel's page size larger as Phil Nitschke said. Another is to modify ioremap() a little bit --- just make it use another file for mmap while larger than 64MB. Since the central concept of linux is file-based, I think more files are not harmful that only waste a little bit inode structure. And it is much more feasible that one can choose to use file in memory or harddisk or mounted device harddisk/memory ... ... This is incorrect. There is no 64MB page size. Unless you are ioremapping a region overed by a BAT/CAM, the mapping is composed of default 4KB PTEs. The reason it fails is because of what I explained earlier. Just wanted to clarify so nobody was confused by these statements. We can map arbitrary sizes to the limit of what the kernel virtual address space settings allow. This varies from platform to platform. -Matt
ioremap() fails for 64 MB
On Wed, Aug 23, 2006 at 07:30:37PM +0930, Phil Nitschke wrote: On Tue, 2006-08-22 at 09:22 -0500, Matt Porter wrote: On Tue, Aug 22, 2006 at 05:11:09PM +0930, Phil Nitschke wrote: Hi all, I have 2 GB memory on a 7448 processor, and want to reserve a huge chunk of it at boot-time, then ioremap() it into the kernel space inside a device driver. So far I've succeeded with 64 MB, but can't go any higher, as mm/vmalloc.c tells me: allocation failed: out of vmalloc space - use vmalloc=size to increase size. So I tried adding a vmalloc line to the kernel command line as follows: Kernel cmd line: root=/dev/nfs rw mem=1920M vmalloc=1024M nfsroot=... Yeah, that suggestion is bogus. That option can't help with getting more vmalloc space in this case. So the vmalloc=size argument has made no difference. What do I need to do to make this work? Go to the Advanced setup menu. There's a number of options to provide fine-grained control of the PPC kernel virtual address space. SNIP Thanks Matt (and others) for your suggestions. Matt has given me the answers I was looking for. Since my (2 GB) memory is within the (4 GB) addressable by a 32-bit processor, why do I need high memory at all? Dan answered this one... Are there performance implications on this platform from having a non optimal low/high ratio? It depends. In PPC, we've always has kernelbase at 0xc000, however, the dirty secret is that we still haven't have a 3:1 user:kernel split like some other arches. We've always had TASK_SIZE at 0x8000 which really results in a 1:1 split. So, as long as you don't modify TASK_SIZE, there's no chance of starving memory hungry user space applications. There's already this waste space from 0x8000-0xbfff that was left due to legacy PReP reasons. Even if you do modify TASK_SIZE down to something like 0x4000, for a 1:3 split, many embedded apps are perfectly happy with this space, YMMV. It's important that you understand how the userspace works at the low level, plus VSIDs (on classic PPC), and the general concepts of the virtual memory organization between kernel and userspace before you mess with all these advanced options. They are under advanced options since they can easily make your system inoperable with the improper settings. That said, why don't you just use alloc_bootmem() to reserve memory for your driver at boot time? I avoided this simply because I wanted to load/unload my driver (during development), and alloc_bootmem() seemed better suited to drivers compiled into the kernel. But I'll look again at this idea if further problems arise with the approach above. I see. It doesn't have any bearing on using a loadable module since alloc_bootmem() is only called by your board port code. Your loadable module just uses that reserved area and manages it on its own. In any case, either approach will work. -Matt
ioremap() fails for 64 MB
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
ioremap() fails for 64 MB
On Tue, Aug 22, 2006 at 05:11:09PM +0930, Phil Nitschke wrote: Hi all, I have 2 GB memory on a 7448 processor, and want to reserve a huge chunk of it at boot-time, then ioremap() it into the kernel space inside a device driver. So far I've succeeded with 64 MB, but can't go any higher, as mm/vmalloc.c tells me: allocation failed: out of vmalloc space - use vmalloc=size to increase size. So I tried adding a vmalloc line to the kernel command line as follows: Kernel cmd line: root=/dev/nfs rw mem=1920M vmalloc=1024M nfsroot=... Yeah, that suggestion is bogus. That option can't help with getting more vmalloc space in this case. So the vmalloc=size argument has made no difference. What do I need to do to make this work? Go to the Advanced setup menu. There's a number of options to provide fine-grained control of the PPC kernel virtual address space. The key here is that you have lots of RAM. By default 768MB will be mapped into kernel lowmem space. This is mapped from 0xc000-0xefff. You probably have highmem on (I hope), so there is a highmem pool at 0xfe00. Your vmalloc space should start at 0xf100 (16 MB offset past end of lowmem). Any io_block_map() calls will further constrain your vmalloc space below the highmem pool. I imagine you have stuff permanently mapped that way down through about 0xf600 which would leave just about around 64MB+ for vmalloc space. The quick test is to modify the Set maximum low memory option to 0x2000 (512MB). This should immediately give you and additional 256MB of vmalloc space as the vmalloc range will now start at 0xe100. If that works to allow a 128MB ioremap and you still need much bigger ioremaps, you can also set virtual address of kernel base down to 0xa000 or 0x8000. That said, why don't you just use alloc_bootmem() to reserve memory for your driver at boot time? Then there's no need to bother with ioremap for your driver then. Just save the pointer to your reserved area somewhere and then use the space in your driver. A lot of people use this approach for unusual cases like this. If you need something dynamic (i.e. with cmdline control) alloc, then bigphysarea is basically a wrapper around bootmem allocation. -Matt
Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : differentoutputs
On Fri, Aug 11, 2006 at 11:08:59AM -0700, Haruki Dai-r35557 wrote: Why there are three TSEC on the MPC8540?? There aren't. There are two TSECs and one FEC on the MPC8540. gianfar drives them all (all the non-CPM enets, that is). -Matt
Pinned TLB entries with 2.6 linux kernel on PPC4xx
On Thu, Jun 01, 2006 at 12:51:29PM -0700, Eugene Surovegin wrote: On Thu, Jun 01, 2006 at 03:29:37PM -0400, Chris Dumoulin wrote: Does the idea of creating pinned TLB entries (ones that will never be overwritten) make sense for a PPC4xx (specifically PPC405) 2.6 linux kernel? If so, how would this be accomplished? 44x kernel already pins some TLB entries, 40x may use this approach to increase performance (I use this in my internal 2.4 tree quite successfully). Old 2.4 trees (linuxppc-2.4 or devel_2_4) have TLB pinning support for 40x, you can look at the implementation there. The partial kernel lowmem pinning for ppc405 was deprecated in favor of having all of kernel lowmem covered by large pages and then large TLBs loaded on tlb misses. This is regarding 2.6, of course. It can also be extended to handle arbitrary areas other than kernel lowmem. -Matt
Viable PPC platform?
On Tue, May 09, 2006 at 10:38:19AM -0400, geneSmith wrote: I have a ppc405gpr system with 64M ram and 4Meg flash in a AM29LV320. Is this a viable platform for linux? Can a filesystem (JFFS2?) be put this flash type? Yes. (Yes) Yes. -Matt
Calculating virtual address from physical address
On Fri, May 05, 2006 at 09:27:50PM +0200, Sylvain Munaut wrote: Chris Dumoulin wrote: I'm using a Virtex II Pro-based board with a PPC405. The board is hanging somewhere very early in the kernel boot process. I believe it may be dying at the point where the MMU is enabled. In order to determine the exact point at which my board hangs, I'm blinking two LEDs in the assembly code found in arch/ppc/kernel/head_4xx.S, . Currently I am only able to successfully access the LEDs before the MMU is turned on, but I can't be sure that I'm calculating the virtual address properly when I try to access the LED after the MMU is turned on. Typical when trying to bring up board ... Once the MMU is turned on, you leds register are most likely ... nowhere ... i.e. if you don't create a mapping your self there is just no virtual address that will access your leds physical address. What I did on some ppc work was tu use a quick BAT mapping to map some leds. It's pretty easy to setup. Be aware though that this mapping will get wiped out when the kernel sets up the BAT for itself. There are no BATs on 4xx. However, the same conceptual thing can be done by wiring a fixed TLB entry to cover those LEDs temporarily during bringup debug. The temporary TLB entry will be wiped out by normal tlb misses after things are running whenever the fixed entry is clobbered by the round robin replacement. -Matt
PPC 405GPr support in linux 2.4.32
On Wed, Apr 26, 2006 at 04:19:23PM -0700, Stephen Williams wrote: ... seems completely missing in the linux-2.3.32 tree from kernel.org. This used to be in the linuxppc-2.4 BK tree that no longer exists, so what happened to the ppc405GPr support?! There's some stuff that never got submitted upstream to kernel.org during 2.4 due partially to 2.5 appearing. All upstream devel moved to 2.5/2.6 and no effort was made to merge stuff from the linuxppc-2.4 tree to linux-2.4. Oh, and Marcelo didn't want to take new stuff into linux-2.4 at that time either. There's still rsync://source.mvista.com/linuxppc-2.4 available with the 405gpr/sycamore support. -Matt
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
On Thu, Feb 02, 2006 at 09:09:17AM +0100, Peter Korsgaard wrote:
On 2/2/06, Kumar Gala galak at kernel.crashing.org wrote:
What is the preferred way of accessing non-PCI devices then? Direct
pointer access?
No direct pointer access is bad. On PPC You can use
in_be{8,16,32}/out_be{8,16,32}
What about arch independent drivers? Are there any generic approach
for this or do you have to stick to ugly #ifdefs to decide between
in_be32/inl ?
ioread*be()/iowrite*be() can be used for this. Since the generic
big endian accessors became a standard thing a little while back,
all the PPC on-chip drivers should move to that. It's just a matter
of time.
-Matt
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
On Thu, Feb 02, 2006 at 01:46:41AM -0800, Eugene Surovegin wrote:
On Thu, Feb 02, 2006 at 09:35:56AM -, Jenkins, Clive wrote:
A driver for some device that could be connected to (or plugged into)
a variety of different platforms of different architecture.
A driver for a core that could be implemented within an FPGA on
multiple platforms.
Well, this is all nice but I was wondering about _real_ examples.
When you are talking about connecting or plugging you have to keep
in mind actual bus interconnect. So far AFAIK PCI (and derivatives)
are the only cross-arch bus.
So basically, you have no _real_ life examples, so I'm wondering why
people need this arch-independent non-PCI I/O accessors for
something which doesn't exist.
I think the reason why Linux doesn't have this stuff follows from the
previous paragraph.
I mentioned the BE iomap variants that are being used on some non-pci
parisc devices already. I'll give a partial example of something that
is non-pci yet arch-independent.
Take a non-pci EHCI core (yes, I know it's little endian by definition
but suspend reality for a second). You can create an arch-independent
EHCI driver that uses the platform bus by using the iomap accessors.
Since these cores are licensed every day by XYZ startups for their
latest gee-whiz SoC, it reasons that you'll see the same core on
multiple licensable SoC architectures. I've seen one such thing
on MIPS.
We also know that major semiconductor companies do the same thing
for their peripherals in some cases. They're just as willing to
buy somebody else's USB core, for example. So, having a BE
non-pci device cross platform isn't a stretch.
Take a look at drivers/scsi/53c700.{c,h}. That generic driver
is why BE iomap accessors were added. It's in the process of
being shared between parisc and m68k.
-Matt
Yosemite/440EP why are readl()/ioread32() setuptoreadlittle-endian?
On Thu, Feb 02, 2006 at 11:26:22AM -, Jenkins, Clive wrote: I'm not sure all this fuss is justified in response to: What is the preferred way of accessing non-PCI devices then? Direct pointer access? Bye, Peter Korsgaard Regardless of what standards or hardware might exist, I would be happy if Linux provided alternatives to readl()... that converted between big-endian and cpu-endian, so that I could write in my driver, for example: As I pointed out, there are such alternatives. The iomap interface provides what you need. -Matt
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
On Thu, Feb 02, 2006 at 09:45:04AM -0800, Eugene Surovegin wrote:
On Thu, Feb 02, 2006 at 07:37:01AM -0700, Matt Porter wrote:
I mentioned the BE iomap variants that are being used on some non-pci
parisc devices already. I'll give a partial example of something that
is non-pci yet arch-independent.
Take a non-pci EHCI core (yes, I know it's little endian by definition
but suspend reality for a second). You can create an arch-independent
EHCI driver that uses the platform bus by using the iomap accessors.
Since these cores are licensed every day by XYZ startups for their
latest gee-whiz SoC, it reasons that you'll see the same core on
multiple licensable SoC architectures. I've seen one such thing
on MIPS.
We also know that major semiconductor companies do the same thing
for their peripherals in some cases. They're just as willing to
buy somebody else's USB core, for example. So, having a BE
non-pci device cross platform isn't a stretch.
Take a look at drivers/scsi/53c700.{c,h}. That generic driver
is why BE iomap accessors were added. It's in the process of
being shared between parisc and m68k.
Matt, my problem with this approach is that it repeats the same
old mistakes but in BE-mode, e.g. _assuming_ some access mode and
hard-coding it into the driver. I fail to see how assuming big-endian
is any better than assuming little-endian in this case. And this is
not _portable_ in my book, no matter what some people want me to
believe.
This fails miserably when for example you have a bus which does byte
swaps in every half-word. And yes, I have such device on my table and
I have to port PCMCIA/PCI drivers to this SoC :).
Yuck. But a good example that there are always ill-behaved exceptions.
Here is how inb looks like:
static inline u8 fpi_inb(unsigned long port)
{
port ^= 1;
return inb(port);
}
IMO, truly portable and driver independent I/O accessors should be
implemented as a function pointers on per-bus (at least) basis which
can be overridden by arch or board code. In this case we can get rid
of ugly ifdefs in driver code :).
There are a ton of reasons for this too, but there's been resistance
in the past to anything adding an additional dereference to the ia32
case. I think there's been some proposals to get around this and
maybe even some small level of acceptance. However, since the server
folks don't need it, it's slow going to get such a major change pushed
through.
FWIW, some Xscale IXPs could use the per-bus pointer accessors to
manage the some floating I/O windows more cleanly as well. RapidIO
has some use for it too. It's not just byte swapping at least.
You could drive this change, you know. :)
-Matt
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
On Wed, Feb 01, 2006 at 09:02:31AM -0800, David Hawkins wrote: Jenkins, Clive wrote: readl() and ioread32() read the registers in little-endian format! Correct. That's how it is implemented on all platforms. Think for example of an pci device driver. Using these IO functions, the driver will become platform independent, running without modifications on little- and big-endian machines. I just stumbled across the section in Rubini 3rd Ed that mislead me into believing that the readl()/writel() were machine endianness dependent, i.e., LE on x86, BE on PPC. p453 of his book has a PCI DMA example, where he uses the cpu_to_le32() macros inside calls writel(). However, since these functions are internally implemented to perform LE operations, this example appears to be incorrect. Would you agree? No, I think it is correct. On most architectures readl() and writel() assume you are accessing MMIO on the PCI bus, which is little-endian. So these macros convert between the endian-ness of the CPU and the endian-ness of the PCI bus. Clive Hey Clive, Right, but in the 440EP source, and probably on other PowerPC ports, readl() and writel() perform the endian conversion for you, so if you wrote an operation as writel(register_address, cpu_to_le32(data)); you would get *two* little endian conversions, i.e., you would write the bytes in the wrong order. I haven't looked in the source for other big-endian architecures yet. I wonder if the ARM stuff is big, or little endian? Both The original question came about while I was trying to read back PLX-9054 registers (a PCI-to-local bus bridge on a PCI adapter board). Those regs are little endian since it's a PCI device. You use the old read*/write* or new ioread*/iowrite* since it's a PCI device. I search through the other drivers for the 440EP peripherals that are not on the PCI bus showed that the authors used the in_be32() and out_be32() calls. The comment at the top of this email indicates that the readl() and writel() are effectively 'reserved' for PCI accesses. I didn't get this impression from reading Rubini. The book implicitly focuses on x86 driver developers, that's why you don't get an explicit statement about this... everything is PCI in that world. read*/write* and ioread*/iowrite* generate outbound little endian cycles on ALL arches, period. They are intended only for PCI use and have generic names only because of the assumption that all the world is a PC. Now, what it takes to to generate outbound little endian cycles varies. On some arches, it's just a store (native LE) on other arches, it's a reversed store (PPC), others still configure their PCI bridge hardware to do byte swapping in hardware (typically if their arch doesn't have a simple byte-swapping store like PPC). The example you cite on pg. 453 of Rubini looks broken for BE systems. It works on LE systems since cpu_to_le32() does nothing and writel is a simply dereference. That's pure luck. On PPC, for example, that would write a big endian bus_addr to the fictitious PCI device which is not what they want. -Matt
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
On Wed, Feb 01, 2006 at 06:54:09PM -0600, Kumar Gala wrote:
On Wed, 1 Feb 2006, Peter Korsgaard wrote:
Matt == Matt Porter mporter at kernel.crashing.org writes:
Matt read*/write* and ioread*/iowrite* generate outbound little
Matt endian cycles on ALL arches, period. They are intended
Matt only for PCI use and have generic names only because of
Matt the assumption that all the world is a PC.
What is the preferred way of accessing non-PCI devices then? Direct
pointer access?
No direct pointer access is bad. On PPC You can use
in_be{8,16,32}/out_be{8,16,32}
Ack. Also, it should be pointed out that there are countless
examples of PPC drivers where this is done properly. 4xx, 83xx,
85xx, etc. on-chip peripherals all do this since they are
naturally BE registers.
-Matt
[PATCH 08/10] ML300 ML403 need embed_config.o linked in
On Fri, Jan 13, 2006 at 07:18:57PM +0100, Peter Korsgaard wrote: grant == grant likely grant.likely at secretlab.ca writes: grant +boot-$(CONFIG_XILINX_ML300) += embed_config.o grant +boot-$(CONFIG_XILINX_ML403) += embed_config.o Notice that the ML300 line already is in mainline and pending for 2.6.15.1. I asked Grant to rebase against current git for the patches to be submitted upstream so that will go away. -Matt
[PATCH] powerpc: generalize PPC44x_PIN_SIZE
On Thu, Dec 29, 2005 at 06:40:40PM -0200, Marcelo Tosatti wrote: Hi, The following patch generalizes PPC44x_PIN_SIZE by changing it to PPC_PIN_SIZE, which can be defined by any board to automatically adjust VMALLOC_START, avoiding conflicts with pinned virtual space. Also define it for 8xx. Matt, please review. ACK, looks good to me. -Matt
PPC 32bits and big RAM mapping problem
On Thu, Dec 01, 2005 at 12:43:02PM -0600, Rune Torgersen wrote: -Original Message- From: Laurent Lagrange Sent: Thursday, December 01, 2005 11:48 To: linuxppc-embedded at ozlabs.org Subject: PPC 32bits and big RAM mapping problem So I'm under the impression to be cornered in my shoes. Any idea, book, article, prediction would be welcome. I have 2GB of ram working on my PPC32 board. You have to change the following in the kernel config: Under Advanced Setup: Set Maximum Low memory (Set to 0x4000) Set Custom Kernel config address (Set to 0xA000) I do not remember if I had to change anything else. If you have 2GB you had to have something else. Right now you have it set to constrict the max lowmem to 1GB. So, you must have CONFIG_HIGHMEM on as well to utilize the other 1GB. To answer the original poster's question: simply enable CONFIG_HIGHMEM and UP system will have 768MB in lowmem and the rest in highmem. If there's some constraint on your application (like many embedded apps) that requires all 2GB in lowmem then configure: Set Maximum low memory (Set to 0x8000) Set custom kernel base address (Set to 0x4000) Set custom user task size (Set to 0x4000) Don't do this unless highmem won't work for your app. If you use this approach each process will be limited to 1GB of virtual memory which may or may not be an OK tradeoff for your app. -Matt
[PATCH 3/3] ppc32: MTD support for Yucca board
On Mon, Nov 21, 2005 at 06:02:57PM +0300, Vitaly Bordug wrote: Guess this should come through MTD community (linux-mtd at lists.infradead.org), rebased to the MTD tree of course. Indeed, however, it need to be split so the driver/mtd portion goes to the MTD maintainers. The arch/ppc portion will go in through the powerpc tree. -Matt
gianfar generic PHY assumptions.
On Thu, Nov 17, 2005 at 03:50:59PM -0600, David Updegraff wrote: Hi. This patch lets gianfar work on 83xx (or 85xx??) boards that have Generic PHYs on them that do _NOT_ happen to have an IRQ line wired to external_15. Surely reasonable that if we can't ID the PHY that its probably not irq-wired the Freescale-ADS way... It was critical for us; perhaps usefull for others. Aside from the fact that the patch doesn't apply against the current kernel due to the change of gianfar to use the phy layer...why wouldn't you just set the board_flags field appropriately in your board port? If you don't use a phy interrupt then don't set the flag claiming that you do. stx_gp3.c doesn't make use of the phy interrupt functionality, as an example. I looked at an older kernel and I'm not sure where you see external 15 being used. It seems to be EXT5 on all the Fscale boards. -Matt
[PATCH] ppc32: fix perf_irq extern on e500
On Mon, Nov 07, 2005 at 07:01:28PM -0800, Andrew Morton wrote:
Matt Porter mporter at kernel.crashing.org wrote:
Add an extern reference to perf_irq on e500.
snip
#ifdef CONFIG_E500
+extern perf_irq_t perf_irq;
+
void performance_monitor_exception(struct pt_regs *regs)
{
perf_irq(regs);
extern decls are placed in header files, please.
Here's the updated patch, addressing this for ppc64 as well. Paul,
would you prefer that this go through the powerpc-merge tree since
the updated version modifies arch/powerpc/?
-Matt
Fixes e500 build and cleans up traps.c by moving perf_irq extern to
pmc.h.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 07e5ee4..32cd797 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -898,10 +898,6 @@ void altivec_unavailable_exception(struc
die(Unrecoverable VMX/Altivec Unavailable Exception, regs, SIGABRT);
}
-#ifdef CONFIG_PPC64
-extern perf_irq_t perf_irq;
-#endif
-
#if defined(CONFIG_PPC64) || defined(CONFIG_E500)
void performance_monitor_exception(struct pt_regs *regs)
{
diff --git a/include/asm-powerpc/pmc.h b/include/asm-powerpc/pmc.h
index 2f3c3fc..5f41f3a 100644
--- a/include/asm-powerpc/pmc.h
+++ b/include/asm-powerpc/pmc.h
@@ -22,6 +22,7 @@
#include asm/ptrace.h
typedef void (*perf_irq_t)(struct pt_regs *);
+extern perf_irq_t perf_irq;
int reserve_pmc_hardware(perf_irq_t new_perf_irq);
void release_pmc_hardware(void);
[PATCH] ppc32: Fix STx GP3 build
Add missing include file to fix STx GP3 build. Signed-off-by: Matt Porter mporter at kernel.crashing.org diff --git a/arch/ppc/platforms/85xx/stx_gp3.h b/arch/ppc/platforms/85xx/stx_gp3.h index 95fdf4b..7bcc6c3 100644 --- a/arch/ppc/platforms/85xx/stx_gp3.h +++ b/arch/ppc/platforms/85xx/stx_gp3.h @@ -21,6 +21,7 @@ #include linux/config.h #include linux/init.h +#include linux/seq_file.h #include asm/ppcboot.h #define BOARD_CCSRBAR ((uint)0xe000)
[PATCH] ppc32: fix perf_irq extern on e500
On Mon, Nov 07, 2005 at 07:01:28PM -0800, Andrew Morton wrote:
Matt Porter mporter at kernel.crashing.org wrote:
Add an extern reference to perf_irq on e500.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
index 16adde6..ff1bdc2 100644
--- a/arch/ppc/kernel/traps.c
+++ b/arch/ppc/kernel/traps.c
@@ -888,6 +888,8 @@ void altivec_assist_exception(struct pt_
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_E500
+extern perf_irq_t perf_irq;
+
void performance_monitor_exception(struct pt_regs *regs)
{
perf_irq(regs);
extern decls are placed in header files, please.
Ok, but we'll have to fix the equivalent code in arch/powerpc/.
The problem is that these rules are applied inconsistently at best. :)
-Matt
[PATCH 1/2] ppc32: Add initial support for DAVE PPChameleon board.
On Wed, Oct 12, 2005 at 05:38:17PM +0200, Wolfgang Denk wrote: the following patch (against current kernel.org tree) adds suport for the PPChameleon modules / eval boards manufactured by DAVE s.r.l. See comments below. +config PPChameleonEVB + bool PPChameleonEVB + help + This option enables support for the DAVE 405EP evaluation board. + It's unusual to have a mixed case config option. Is there a better option that makes sense? PP_CHAM_EVB? /* DCR defines */ -#define DCRN_CPMSR_BASE 0x0BA -#define DCRN_CPMFR_BASE 0x0B9 +#define DCRN_CPMSR_BASE 0x0BA +#define DCRN_CPMFR_BASE 0x0B9 Please drop these whitespace changes. -#define IBM_CPM_GPT 0x8000 /* GPT interface */ -#define IBM_CPM_PCI 0x4000 /* PCI bridge */ -#define IBM_CPM_UIC 0x0001 /* Universal Int Controller */ -#define IBM_CPM_CPU 0x8000 /* processor core */ -#define IBM_CPM_EBC 0x2000 /* EBC controller */ -#define IBM_CPM_SDRAM0 0x4000 /* SDRAM memory controller */ -#define IBM_CPM_GPIO0 0x1000 /* General Purpose IO */ -#define IBM_CPM_TMRCLK 0x0400 /* CPU timers */ -#define IBM_CPM_PLB 0x0100 /* PLB bus arbiter */ -#define IBM_CPM_OPB 0x0080 /* PLB to OPB bridge */ -#define IBM_CPM_DMA 0x0040 /* DMA controller */ -#define IBM_CPM_IIC00x0010 /* IIC interface */ -#define IBM_CPM_UART1 0x0002 /* serial port 0 */ -#define IBM_CPM_UART0 0x0001 /* serial port 1 */ +#define IBM_CPM_GPT 0x8000 /* GPT interface */ +#define IBM_CPM_PCI 0x4000 /* PCI bridge */ +#define IBM_CPM_UIC 0x0001 /* Universal Int Controller */ +#define IBM_CPM_CPU 0x8000 /* processor core */ +#define IBM_CPM_EBC 0x2000 /* EBC controller */ +#define IBM_CPM_SDRAM0 0x4000 /* SDRAM memory controller */ +#define IBM_CPM_GPIO00x1000 /* General Purpose IO */ +#define IBM_CPM_TMRCLK 0x0400 /* CPU timers */ +#define IBM_CPM_PLB 0x0100 /* PLB bus arbiter */ +#define IBM_CPM_OPB 0x0080 /* PLB to OPB bridge */ +#define IBM_CPM_DMA 0x0040 /* DMA controller */ +#define IBM_CPM_IIC0 0x0010 /* IIC interface */ +#define IBM_CPM_UART10x0002 /* serial port 0 */ +#define IBM_CPM_UART00x0001 /* serial port 1 */ Same here, if whitespace chanes are important submit them separately. diff --git a/arch/ppc/platforms/4xx/ppchameleon.c b/arch/ppc/platforms/4xx/ppchameleon.c new file mode 100644 --- /dev/null snip +#if defined(CONFIG_BIOS_FIXUP) +void __init bios_fixup (struct pci_controller *hose, struct pcil0_regs *pcip) snip You don't use this bios_fixup garbage in this port (at least according to your defconfig) so just drop it. As an aside, this stuff is pretty awful and has been since 405 first came into the tree. If the basic functionality were required, a new port should simply reprogram the pci host bridge and let the pci subsystem place the BARs. -Matt
[PATCH 2/2] MTD: Add initial support for DAVE PPChameleon board.
On Wed, Oct 12, 2005 at 05:44:31PM +0200, Wolfgang Denk wrote: Hello, the following patch (against current kernel.org tree) adds MTD support for the NOR and NAND flashes on the PPChameleon modules / eval boards manufactured by DAVE s.r.l. This should be submitted to the MTD maintainer(s). -Matt
[PATCH] ppc32: Add missing initrd header on ppc440
On Mon, Oct 31, 2005 at 11:29:13AM +0200, Stefan Roese wrote: By the way: What is the current status of the pending 4xx patches. Are they going in in this 2-week merge window? The PPC44x U-Boot cleanup was queued and merged. The rest of PPC4xx cleanup patches are now pending with akpm and will probably be queued for Linus shortly. There will be no problem with them being merged. -Matt
[PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
On Thu, Sep 22, 2005 at 10:25:26PM -0700, Roland Dreier wrote: Eugene Well, new driver was sent to jgarzik and netdev list three Eugene weeks ago. So far I haven't heard anything technical from Eugene Jeff. I don't know when and even if it will be merged. Assuming everyone in the PPC4xx world thinks your driver should replace the old driver, it might be worth sending directly to Andrew. There's no reason Jeff has to become a bottleneck for this. We're working on this. It's not exactly that simple since Jeff established that all net drivers must enter through the netdev tree. I expect it can get merged post 2.6.14 if all goes well. -Matt
[PATCH 2/4] [PPC32] Add 440SPe support
On Thu, Sep 22, 2005 at 10:44:35PM -0700, Roland Dreier wrote: Eugene Roland, I recently added new field (.dcr_base) to this Eugene structure (as a preparation step for new EMAC driver), Eugene could you do this for 440SPe as well? It's not needed Eugene right now, but as soon as new EMAC driver is in, 440SPe Eugene will stop working. Eugene I think you probably missed this part :) Both fixed and pushed in a new git tree... Can you rebase off of Eugene's tree and resend patches? For the moment the new EMAC driver is the lynchpin in anything new PPC4xx. I want to hold off merging anything that involves current EMAC driver changes until the new driver is in. In any case, nothing like this can go upstream until after 2.6.14 is released. We are expecting the new EMAC driver to be merged at that point. If you have this stuff rebased from his tree we can easily merge them post-EMAC merge. -Matt
[PATCH 2/4] [PPC32] Add 440SPe support
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote: Add support for the AMCC PowerPC 440SPe SoC. Signed-off-by: Roland Dreier rolandd at cisco.com --- arch/ppc/kernel/cputable.c | 10 +++ arch/ppc/platforms/4xx/Kconfig |8 ++ arch/ppc/platforms/4xx/Makefile |1 arch/ppc/platforms/4xx/amcc440spe.c | 134 +++ arch/ppc/platforms/4xx/amcc440spe.h | 64 + Please change these new files to ppc440spe.*. After the new EMAC driver is merged, we are planning a Great Renaming(tm) to make the current filenames be vendor neutral. i.e. ibm4*-ppc4* -Matt
[PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
On Fri, Sep 23, 2005 at 01:25:09PM -0700, Roland Dreier wrote: Matt We're working on this. It's not exactly that simple since Matt Jeff established that all net drivers must enter through the Matt netdev tree. I expect it can get merged post 2.6.14 if all Matt goes well. Jeff may want all net drivers to go through his tree, but with all due respect to him, there's no law that says it has to be so. cf. Linus's recent post: http://lkml.org/lkml/2005/9/22/220 Yep, one step at a time. There's no rush for today or tomorrow... nothing like this is going into the tree until post 2.6.14 anyway. -Matt
[PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
On Mon, Sep 19, 2005 at 01:02:14PM +0200, Stefan Roese wrote: Hi Eugene, On Friday 16 September 2005 18:27, Eugene Surovegin wrote: On Fri, Sep 16, 2005 at 01:06:16PM +0200, Stefan Roese wrote: Add U-Boot support to AMCC PPC405 eval boards (bubinga, sycamore and walnut) and cleanup PPC440 eval boards (bamboo, ebony, luan and ocotea) to better support U-Boot as bootloader. In general, 44x pieces look OK, but 40x aren't. Notice, that we don't have any #ifdef CONFIG_UBOOT in 44x sources. Let's not add them for 40x, try to replicate the same boot-wrapper approach as Matt used for 44x. OK. I'll split the patch in two (44x and 40x stuff) so we can get the 44x pieces on the way. Just to be sure: The 44x boot-wrapper approach you mention is boot/simple/pibs.c? Yes, there's both boot/simple/pibs.c and boot/simple/openbios.c that were created so we could have the default firmware and u-boot use the same kernel build. -Matt
PPC4xx cleanup
On Thu, Sep 15, 2005 at 03:03:23PM -0400, Dan Malek wrote: On Sep 15, 2005, at 12:25 PM, Matt Porter wrote: Sounds great to me. This will have to wait to go in mainline until after 2.6.14 is out though. If you are considering this, I think you should be looking at the recent U-Boot discussion and patches for the flat OF tree and follow that path. We need to fix the kernel versus the current version of U-boot's data passing scheme for ppc32. Once the flat OF tree stuff is mainline we can convert to it...except we have to have a wrapper for older versions of u-boot assuming that somebody will have changed U-boot so 4xx dumps a flat OF tree. -Matt
emac driver broken in 2.6.12.2 ?
On Mon, Sep 19, 2005 at 09:23:36AM -0500, Josh Boyer wrote: On Mon, 2005-09-19 at 15:51 +0200, Peter Fercher wrote: I think that this MAC addresses are crap (sorry if not formulated clearly enough for you ;) am I wrong ? No, you're not wrong. My brain just didn't parse that as a problem with the emac code itself. Anyway, I think David and Stefan have pointed you in the right direction. Yep, he's got to configure the driver properly for his platform. -Matt
[PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
On Mon, Sep 19, 2005 at 05:06:23PM +0200, Stefan Roese wrote: Hi Matt, On Monday 19 September 2005 15:59, Matt Porter wrote: On Mon, Sep 19, 2005 at 01:02:14PM +0200, Stefan Roese wrote: Just to be sure: The 44x boot-wrapper approach you mention is boot/simple/pibs.c? Yes, there's both boot/simple/pibs.c and boot/simple/openbios.c that were created so we could have the default firmware and u-boot use the same kernel build. Yes, that's what I thought. But Eugene mentioned, that he boots vmlinux without any boot-wrapper on the OpenBIOS targets (except Ebony probably). You would loose this possibility, if I add this wrapper and switch from OpenBIOS to U-Boot bd_info struct in the kernel. Did I miss something here? How should I proceed? I thought he was talking about booting a uImage, which from the perspective of not having the zImage wrapper around it, is like booting a vmlinux. He may referring to his own production firmware capabilities too. I'll let him comment. In any case, if you follow the model used on 44x where the board info is the standard method of passing info into the kernel, then we'll be alright. This means you have to add additional code in the arch/ppc/boot/simple/openbios.c shim to generate some compatible board info. -Matt
PPC4xx cleanup
On Thu, Sep 15, 2005 at 06:03:14PM +0200, Stefan Roese wrote: Hi, I am right now testing and cleaning up some of the AMCC 4xx eval board ports to better support U-Boot as firmware. One question before I begin to send a few patches: All of the 44x boards I looked at (e.g. Ocotea) have to be extended in the platform file (e.g. platforms/4xx/ocotea.c) to not only copy the bd_info struct from r3, but also check r4 and r6 for initrd and kernel command line passing from the bootloader. Instead of adding this code to all different platform files, I would like to move this code to the common function ibm44x_platform_init (syslib/ibm44x_common.c) like it is done in the 40x ports ppc4xx_init (syslib/ppc4xx_setup.c). Any objections/remarks? Sounds great to me. This will have to wait to go in mainline until after 2.6.14 is out though. -Matt
Address mapping PPC 405
On Sun, Aug 28, 2005 at 06:26:06PM -0600, Grant Likely wrote: On 8/28/05, Jon Masters jonmasters at gmail.com wrote: On 8/26/05, P. Sadik psadik at gmail.com wrote: Lovely. We don't do it that way on 405 but we could - since the MMU is heavy soft assisted we could do that - we actually have everything run through the MMU once we've done initial MMU setup, but we do have the ability to mark ranges of addresses for IO and have the concept of TLB pinning to lock ranges of kernel addresses in large translated (BAT like for bigger PPC users) regions using just a few TLB slots. There is also a ZPR (zone protection register), but that's mostly used to fake the usual USER/KERNEL page distinction. I believe TLB pinning was removed in 2.6 in favor of large TLB entries for kernel space. Matt Porter pointed this out to me about a week ago. This will not matter of course if you're not using 2.6. Matt, is there any documentation covering the new design in the kernel tree? The docs are in the original threads from 3+ years ago. You'll need to read them all to have proper context about the tradeoffs between permanently pinning a couple TLBs versus faulting large TLB replacement. http://ozlabs.org/pipermail/linuxppc-embedded/2002-May/007257.html http://ozlabs.org/pipermail/linuxppc-embedded/2002-May/007317.html http://ozlabs.org/pipermail/linuxppc-embedded/2002-June/007370.html http://ozlabs.org/pipermail/linuxppc-embedded/2002-June/007404.html -Matt
[PATCH] Fix for TLB errata on early Xilinx Virtex-II Pro silicon
On Wed, Aug 17, 2005 at 02:05:47PM -0600, Grant Likely wrote: config EMBEDDEDBOOT bool - depends on EP405 || XILINX_ML300 + depends on EP405 || VIRTEX_II_PRO default y Grant, Can you post another patch without this hunk?..as Andrei pointed out, it's a board specific feature. Otherwise, looks good to go upstream. -Matt
[PATCH] PPC: Don't sleep in flush_dcache_icache_page()
On Thu, Aug 18, 2005 at 02:56:42PM -0300, Marcelo Tosatti wrote: Hi Roland, On Tue, Aug 16, 2005 at 01:56:49PM -0700, Roland Dreier wrote: flush_dcache_icache_page() will be called on an instruction page fault. We can't sleep in the fault handler, so use kmap_atomic() instead of just kmap() for the Book-E case. Signed-off-by: Roland Dreier rolandd at cisco.com Why do you need to disable interrupts during the kmap_atomic/flush_dcache_icache operation ? I fail to see how an interrupt could have any reference to the data being dealt with here (the user page). We just took care of this offline. The original patch is sharing a kmap slot with another kmap_atomic user I put in before...the sync page user. If an interrupt came in causing the DMA API to be used, we would have a problem. The clean solution was to use a different kmap slot. -Matt
[PATCH] Use platform device for 8250 registration
On Wed, Aug 17, 2005 at 11:16:39AM -0500, Kumar Gala wrote: On Aug 17, 2005, at 10:30 AM, Tom Rini wrote: On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote: So long as you convert arch/ppc/boot/ to this as well, why not (or at least being able to grab the infos from these structs somehow). Once everyone is on a flat tree, I don't object to killing all of the old-style uart definitions steaming out of asm-ppc/serial.h. Tom, do have a test system that I can look at converting that you would be willing to test the changes to arch/ppc/boot for me. With Matt's patch, you could boot a PReP kernel (no VGA con) :) But if you convert LoPEC, I'll throw the kernel at it. Does PReP use bootcode? I thought it was OF based, but what do I know. Are you asking on a real machine or on qemu? On real PReP hardwrae you can find both OF and other firmware like PPCBUG...in both cases they dump residual data. On qemu, jmayer wrote the openhackware bios with is supposed to be some minimal OF-like thing...it dumps residual data too. -Matt
Redwood-6 and 2.6
On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote: On Mon, Aug 15, 2005 at 10:25:10PM -0700, Matt Porter wrote: On Thu, Aug 11, 2005 at 09:28:19PM -0600, Otto Solares wrote: Hi! Redwood-6 support in 2.6 is broken. I subscribed to this list just to know if somebody is working on it? 2.4.30 works ok. I went ahead and fixed this compile issue in the following patch: http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019782.html Excellent!, it compiles now. Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the same thing as zImage.treebot that appears now in 2.6? Yes, this is the image that boots on the stock OpenBIOS firmware. It has the standard tree header on it. -Matt
[PATCH] ppc32: Fix PPC440SP SRAM controller DCRs
Fixes the incorrect DCR base value for the 440SP SRAM controller. Signed-off-by: Matt Porter mporter at kernel.crashing.org diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h --- a/include/asm-ppc/ibm44x.h +++ b/include/asm-ppc/ibm44x.h @@ -423,11 +423,7 @@ #define MQ0_CONFIG_SIZE_2G 0xc000 /* Internal SRAM Controller 440GX/440SP */ -#ifdef CONFIG_440SP -#define DCRN_SRAM0_BASE0x100 -#else /* 440GX */ #define DCRN_SRAM0_BASE0x000 -#endif #define DCRN_SRAM0_SB0CR (DCRN_SRAM0_BASE + 0x020) #define DCRN_SRAM0_SB1CR (DCRN_SRAM0_BASE + 0x021)
[PATCH] ppc32: add cputable entry for 440SP Rev. A
Adds the appropriate cputable entry for PPC440SP so cache line
sizes are configured correctly.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/arch/ppc/kernel/cputable.c b/arch/ppc/kernel/cputable.c
--- a/arch/ppc/kernel/cputable.c
+++ b/arch/ppc/kernel/cputable.c
@@ -922,6 +922,16 @@ struct cpu_speccpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
},
+ { /* 440SP Rev. A */
+ .pvr_mask = 0xff000fff,
+ .pvr_value = 0x53000891,
+ .cpu_name = 440SP Rev. A,
+ .cpu_features = CPU_FTR_SPLIT_ID_CACHE |
+ CPU_FTR_USE_TB,
+ .cpu_user_features = PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ },
#endif /* CONFIG_44x */
#ifdef CONFIG_FSL_BOOKE
{ /* e200z5 */
Redwood-6 and 2.6
On Tue, Aug 16, 2005 at 08:47:45PM -0600, Otto Solares wrote: On Tue, Aug 16, 2005 at 02:19:08PM -0700, Matt Porter wrote: On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote: Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the same thing as zImage.treebot that appears now in 2.6? Yes, this is the image that boots on the stock OpenBIOS firmware. It has the standard tree header on it. Thank you, just one more thing, do you know if the smc91x driver works for PPC? In 2.4 I had to set: It should work. CONFIG_SMC9=y CONFIG_SMC9_ADVANCED=y CONFIG_SMC9_BYTE_SWAP=y Looking in the driver itself I think it was developed for ARM. Well, the ARM folks were the earliest users of smc9 glued onto their parts. There have been multiple drivers over the years and then Nico recently unified them into smc91x. PPC has always had PCI Ethernets or on-chips Ethernet (like the other 4xx parts) so having a nasty little smc part glued onto a bus isn't that popular. :) It should still work. Dale Farnsworth took the time to add the proper redwood specific bits to smc91x.h for accessing the regs and add the bits to instantiate an smc91x platform device in the redwood kernel ports. I am unable to netboot, I don't have serial console so my only access to this little box (MediaMVP) is the net. Thank you. What kernel port are you using? You're trying boot a Redwood 6 kernel on the MediaMVP? -Matt
[PATCH] ppc32: fix ppc4xx stb03xxx dma build
Fixes build on 4xx stb03xxx when general purpose dma engine support is enabled. Signed-off-by: Matt Porter mporter at kernel.crashing.org diff --git a/arch/ppc/syslib/ppc4xx_dma.c b/arch/ppc/syslib/ppc4xx_dma.c --- a/arch/ppc/syslib/ppc4xx_dma.c +++ b/arch/ppc/syslib/ppc4xx_dma.c @@ -620,6 +620,7 @@ ppc4xx_clr_dma_status(unsigned int dmanr return DMA_STATUS_GOOD; } +#ifdef CONFIG_PPC4xx_EDMA /* * Enables the burst on the channel (BTEN bit in the control/count register) * Note: @@ -685,6 +686,11 @@ ppc4xx_set_burst_size(unsigned int dmanr return DMA_STATUS_GOOD; } +EXPORT_SYMBOL(ppc4xx_enable_burst); +EXPORT_SYMBOL(ppc4xx_disable_burst); +EXPORT_SYMBOL(ppc4xx_set_burst_size); +#endif /* CONFIG_PPC4xx_EDMA */ + EXPORT_SYMBOL(ppc4xx_init_dma_channel); EXPORT_SYMBOL(ppc4xx_get_channel_config); EXPORT_SYMBOL(ppc4xx_set_channel_priority); @@ -703,6 +709,4 @@ EXPORT_SYMBOL(ppc4xx_enable_dma_interrup EXPORT_SYMBOL(ppc4xx_disable_dma_interrupt); EXPORT_SYMBOL(ppc4xx_get_dma_status); EXPORT_SYMBOL(ppc4xx_clr_dma_status); -EXPORT_SYMBOL(ppc4xx_enable_burst); -EXPORT_SYMBOL(ppc4xx_disable_burst); -EXPORT_SYMBOL(ppc4xx_set_burst_size); + diff --git a/include/asm-ppc/ppc4xx_dma.h b/include/asm-ppc/ppc4xx_dma.h --- a/include/asm-ppc/ppc4xx_dma.h +++ b/include/asm-ppc/ppc4xx_dma.h @@ -285,7 +285,7 @@ typedef uint32_t sgl_handle_t; #define GET_DMA_POLARITY(chan) (DMAReq_ActiveLow(chan) | DMAAck_ActiveLow(chan) | EOT_ActiveLow(chan)) -#elif defined(CONFIG_STBXXX_DMA) /* stb03xxx */ +#elif defined(CONFIG_STB03xxx) /* stb03xxx */ #define DMA_PPC4xx_SIZE4096
Redwood-6 and 2.6
On Thu, Aug 11, 2005 at 09:28:19PM -0600, Otto Solares wrote: Hi! Redwood-6 support in 2.6 is broken. I subscribed to this list just to know if somebody is working on it? 2.4.30 works ok. I went ahead and fixed this compile issue in the following patch: http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019782.html -Matt
writel(), readl() in asm-ppc/io.h
On Sat, Aug 13, 2005 at 08:56:50PM -0700, Shawn Jin wrote: read*()/write*() are accessors for PCI and PCI only. PCI is little If read*()/write*() are designed for PCI access only as you claimed, that explains why they call in/out_leXX() funcitons. The problem is that read*()/write*() are misused in some places, e.g., serial drivers such as serial8250. The serial_in() and serial_out() call read*() and write*() respectively. So what's your recommendation in such a case? Keep misusing them. There's no generic accessors for memory mapped I/O. People just started using them in generic drivers because they are convenient. I use the the __raw_read*() for non byte swapped access (or in/outbe32() depending on my memory barrier requirements. Also, portions of the 8250 serial driver using readl/writel are assuming that the serial port in on PCI or other little endian bus. readb/writeb usage doesn't matter in that driver. -Matt
writel(), readl() in asm-ppc/io.h
On Fri, Aug 12, 2005 at 06:11:14PM -0700, Shawn Jin wrote: Hi, In asm-ppc/io.h, writew(), readw(), writel(), and readl() are defined to little endian access for all platforms unless either CONFIG_APUS or CONFIG_8260_PCI9 is defined. Why? Aren't they correct in big endian systems, are they? Maybe I miss something here. I'm not sure what your qustion is but I'll take a stab at an answer. :) read*()/write*() are accessors for PCI and PCI only. PCI is little endian. PPC is big endian. All platforms must byte swap on access to PCI memory space except in special cases. The two exceptions must byte swap in hardware. Looks like it is due to errata in the 8260 PCI bridge case. APUS is probably byte swapping in hardware because APUS is simply odd. -Matt
[PATCH] ppc32: Add usb support to IBM stb04xxx platforms
Support ochi-ppc-soc.c on IBM stb04xxx platforms
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Signed-off-by: Matt Porter mporter at kernel.crashing.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include linux/init.h
#include asm/ocp.h
+#include asm/ppc4xx_pic.h
#include platforms/4xx/ibmstb4.h
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,51 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr= USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0x7f01,
+ .triggering = 0x,
+ .ext_irq_mask = 0x007e, /* IRQ0 - IRQ5 */
+ }
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end= USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end= USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -18,6 +18,19 @@
#include linux/ioport.h
#include asm/io.h
#include asm/machdep.h
+#include asm/ppc4xx_pic.h
+
+/*
+ * Define external IRQ senses and polarities.
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 5 */
+};
static struct resource smc91x_resources[] = {
[0] = {
[PATCH] add field to struct ocp_func_emac_data for platform-specific unsupported PHY features
On Fri, Aug 05, 2005 at 04:26:30PM -0700, Wade Farnsworth wrote:
static int
--- linux-2.6/include/asm-ppc/ibm_ocp.h 2005-08-03 13:34:08.0
-0700
+++ linux-2.6-dev/include/asm-ppc/ibm_ocp.h 2005-08-02 10:49:42.0
-0700
@@ -67,6 +67,7 @@ struct ocp_func_emac_data {
int phy_mode; /* PHY type or configurable mode */
u8 mac_addr[6];/* EMAC mac address */
u32 phy_map;/* EMAC phy map */
+ u32 feat_unsupp;/* Unsupported phy features */
Could you update this field (and related usages) to be phy_ftr_exc?
For Excluded phy features. Eugene and I discussed this on IRC and
think it's a better name...for one it starts with the phy_ prefix like
other related phy data. Except for that, it's ready for upstream.
Thanks,
Matt
[PATCH] ppc32: fix ppc440 pagetable attributes
This patch fixes a bug in the PPC440 pagetable attributes that breaks swap support. It also adds some notes on the PPC440 attribute fields. Signed-off-by: Geoff Levand geoffrey.levand at am.sony.com for CELF Signed-off-by: Matt Porter mporter at kernel.crashing.org Index: linux-2.6.12-bhpm/include/asm-ppc/pgtable.h === --- linux-2.6.12-bhpm.orig/include/asm-ppc/pgtable.h2005-06-02 15:09:24.0 -0700 +++ linux-2.6.12-bhpm/include/asm-ppc/pgtable.h 2005-06-02 15:47:53.0 -0700 @@ -202,18 +202,64 @@ * * Note that these bits preclude future use of a page size * less than 4KB. + * + * + * PPC 440 core has following TLB attribute fields; + * + * TLB1: + * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 + * RPN. - - - - - - ERPN... + * + * TLB2: + * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 + * - - - - -- U0 U1 U2 U3 W I M G E - UX UW UR SX SW SR + * + * There are some constrains and options, to decide mapping software bits + * into TLB entry. + * + * - PRESENT *must* be in the bottom three bits because swap cache + * entries use the top 29 bits for TLB2. + * + * - FILE *must* be in the bottom three bits because swap cache + * entries use the top 29 bits for TLB2. + * + * - CACHE COHERENT bit (M) has no effect on PPC440 core, because it + * doesn't support SMP. So we can use this as software bit, like + * DIRTY. + * + * PPC Book-E Linux implementation uses PPC HW PTE bit field definition, + * even it doesn't have HW PTE. 0-11th LSB of PTE stand for memory + * protection-related function. (See PTE structure in include/asm-ppc/mmu.h) + * Definition of _PAGE_XXX in include/asm-ppc/pagetable.h stands for + * above bits. Note that those bits values are CPU dependent, not + * architecture. + * + * Kernel PTE entry holds arch-dependent swp_entry structure under certain + * situation. In other words, in such situation, some portion of PTE bits + * are used as swp_entry. In PPC implementation, 3-24th LSB are shared with + * swp_entry, however 0-2nd three LSB still hold protection values. + * That means three protection bits are reserved for both PTE and SWAP + * entry at the most three LSBs. + * + * There are three protection bits available for SWAP entry; + * _PAGE_PRESENT + * _PAGE_FILE + * _PAGE_HASHPTE (if HW has) + * + * So those three bits have to be inside of 0-2nd LSB of PTE. + * */ + #define _PAGE_PRESENT 0x0001 /* S: PTE valid */ #define_PAGE_RW0x0002 /* S: Write permission */ -#define_PAGE_DIRTY 0x0004 /* S: Page dirty */ +#define _PAGE_FILE 0x0004 /* S: nonlinear file mapping */ #define _PAGE_ACCESSED 0x0008 /* S: Page referenced */ #define _PAGE_HWWRITE 0x0010 /* H: Dirty RW */ #define _PAGE_HWEXEC 0x0020 /* H: Execute permission */ #define_PAGE_USER 0x0040 /* S: User page */ #define_PAGE_ENDIAN0x0080 /* H: E bit */ #define_PAGE_GUARDED 0x0100 /* H: G bit */ -#define_PAGE_COHERENT 0x0200 /* H: M bit */ -#define _PAGE_FILE 0x0400 /* S: nonlinear file mapping */ +#define_PAGE_DIRTY 0x0200 /* S: Page dirty */ #define_PAGE_NO_CACHE 0x0400 /* H: I bit */ #define_PAGE_WRITETHRU 0x0800 /* H: W bit */
[PATCH] ppc32: fix ppc440 pagetable attributes
On Fri, Aug 05, 2005 at 03:54:42PM -0700, Andrew Morton wrote: Matt Porter mporter at kernel.crashing.org wrote: This patch fixes a bug in the PPC440 pagetable attributes that breaks swap support. It also adds some notes on the PPC440 attribute fields. hm, that looks pretty serious, but it affects all ppc's, yes? Just PPC440. I originally organized the attributes incorrectly. Is this needed for 2.6.13? Are you super-sure it's safe? This should go into 2.6.13. I doublechecked it by inspection and ran numerous tests. It's only existed this long (years) due to the fact that few people run a disk-based PPC440 system. I would have sent it up sooner except I wanted to be very sure of my testing since I don't always trust my own inspection. :) -Matt
ATI Radeon with PPC 440 GX and kernel 2.6.12
On Fri, Jul 29, 2005 at 10:32:01AM +0200, David Grab wrote: Hello, i?m using on my custom board a ATI M6 Mobility Radeon with kernel 2.6.12. Now i have to initialize the ati and configure the kernel to support it. Did someone use this combination (ppc + ati radeon)? It would be appreciating to get some help or tipps in configuring to get the ati functioning. Especially the BIOS of the ATI chip, because i have actually found only x86 binaries. Is it also possible to set up the bios settings for the ati chip without an bios eeprom attached via the radeon driver? There is a x86 emulator that can execute x86 VGA BIOS code to initialize your VGA core in U-Boot. It's part of the MAI port so you can look at that code and port it to your board. It is actually some scitechsoft code that's been ported to build within U-Boot. Gabriel Paubert's preploader code also has an x86 real mode emulator written in PPC assembly that does the same thing, but it may be more convenient to work with the stuff in U-Boot. It doesn't help that I can seem to find a current link to the preploader code. Maybe Gabriel can appear and provide it. -Matt
[PATCH][5/5] RapidIO support: net driver over messaging
On Wed, Jul 27, 2005 at 01:36:15PM +0300, Avni Hillel-R58467 wrote: Hi Matt, Two questions: A. How can a node (not the host) know who is in the rionet to broadcast to them? All nodes in the rionet are flagged in the active peer list. There is an active peer list kept for the rionet instance on _each node_. There is no distinction as to whether a node was the winning enumerating host or is just another processing element that found devices in the system via passing discovery. The only inherently significant about a host in RapidIO is that it participates in enumeration. After the system is enumerated it's no longer special (unless your particular system application designates the hosts have some special network-wide ownership of resources or something). Broadcast works the same way on all nodes by sending the same packet to every node in the active peer list. B. How do you emulate broadcasting to all the mailboxes, in multi mbox systems? Is this done by the node getting the broadcast in MB 0 and forwarding it to the other MBs? rionet doesn't handle multiple mailboxes yet. However, it becomes tricky because we don't want to bridge separate Ethernet networks by policy in the driver. If two mailboxes are part of separate rio device trees, then it doesn't make sense to send broadcasts out on both mailboxes. It needs some thought and also docs on how new silicon might be implementing queues in new mailboxes. With RIO, there's so much left to be implementation specific in the silicon. It did not make sense to make assumptions and try to handle multiple mailboxes. If you have a multi mbox system it would help to have a description so we can work to support it. -Matt
[PATCH] Support for AMCC Yosemite 440EP Eval Board
On Wed, Jul 27, 2005 at 08:59:51AM -0700, Eugene Surovegin wrote: On Wed, Jul 27, 2005 at 06:58:21AM -0500, John Otken wrote: This patch adds support for the new AMCC Yosemite 440EP Eval Board. I tested it on the both Bamboo and Yosemite boards using the 2.6.12 kernel. This patch has three dependencies: 2005-04-07 Wade Farnsworth's PPC440EP SoC and Bamboo board support Why this old one? Updated patch was posted yesterday. It should be noted that yesterday's patch is what I'm splitting to send upstream. -Matt
[PATCH 00/14] ppc32: Remove board ports that are no longer maintained
On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote: On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote: Kumar, I thought that we had some volunteers to take care of some of those. I know that I still care about ep405, and I'm willing to maintain the code. Well, it has been almost two months since Kumar asked about maintenance for this board. Nothing happened since then. Why is it not fixed yet? Please, send a patch which fixes it. This is the _best_ way to keep this board in the tree, not some empty maintenance _promises_. When we recover our history from the linuxppc-2.4/2.5 trees we can show exactly how long it's been since anybody touched ep405. Quick googling shows that it's been almost 2 years since the last mention of ep405 (exluding removal discussions) on linuxppc-embedded. Last ep405-related commits are more than 2 years ago. -Matt
[PATCH][2/3] ppc32: add bamboo platform
Add Bamboo platform support. This is an AMCC 440EP-based
reference platform.
Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/arch/ppc/platforms/4xx/bamboo.c b/arch/ppc/platforms/4xx/bamboo.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/4xx/bamboo.c
@@ -0,0 +1,427 @@
+/*
+ * arch/ppc/platforms/4xx/bamboo.c
+ *
+ * Bamboo board specific routines
+ *
+ * Wade Farnsworth wfarnsworth at mvista.com
+ * Copyright 2004 MontaVista Software Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/config.h
+#include linux/stddef.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/reboot.h
+#include linux/pci.h
+#include linux/kdev_t.h
+#include linux/types.h
+#include linux/major.h
+#include linux/blkdev.h
+#include linux/console.h
+#include linux/delay.h
+#include linux/ide.h
+#include linux/initrd.h
+#include linux/irq.h
+#include linux/seq_file.h
+#include linux/root_dev.h
+#include linux/tty.h
+#include linux/serial.h
+#include linux/serial_core.h
+#include linux/ethtool.h
+
+#include asm/system.h
+#include asm/pgtable.h
+#include asm/page.h
+#include asm/dma.h
+#include asm/io.h
+#include asm/machdep.h
+#include asm/ocp.h
+#include asm/pci-bridge.h
+#include asm/time.h
+#include asm/todc.h
+#include asm/bootinfo.h
+#include asm/ppc4xx_pic.h
+#include asm/ppcboot.h
+
+#include syslib/gen550.h
+#include syslib/ibm440gx_common.h
+
+/*
+ * This is a horrible kludge, we eventually need to abstract this
+ * generic PHY stuff, so the standard phy mode defines can be
+ * easily used from arch code.
+ */
+#include ../../../../drivers/net/ibm_emac/ibm_emac_phy.h
+
+bd_t __res;
+
+static struct ibm44x_clocks clocks __initdata;
+
+/*
+ * Bamboo external IRQ triggering/polarity settings
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ0: Ethernet
transceiver */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* IRQ1: Expansion connector
*/
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ2: PCI slot 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ3: PCI slot 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ4: PCI slot 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ5: PCI slot 3 */
+ (IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE), /* IRQ6: SMI pushbutton */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ7: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ8: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ9: EXT */
+};
+
+static void __init
+bamboo_calibrate_decr(void)
+{
+ unsigned int freq;
+
+ if (mfspr(SPRN_CCR1) CCR1_TCS)
+ freq = BAMBOO_TMRCLK;
+ else
+ freq = clocks.cpu;
+
+ ibm44x_calibrate_decr(freq);
+
+}
+
+static int
+bamboo_show_cpuinfo(struct seq_file *m)
+{
+ seq_printf(m, vendor\t\t: IBM\n);
+ seq_printf(m, machine\t\t: PPC440EP EVB (Bamboo)\n);
+
+ return 0;
+}
+
+static inline int
+bamboo_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
+*/
+ {
+ { 28, 28, 28, 28 }, /* IDSEL 1 - PCI Slot 0 */
+ { 27, 27, 27, 27 }, /* IDSEL 2 - PCI Slot 1 */
+ { 26, 26, 26, 26 }, /* IDSEL 3 - PCI Slot 2 */
+ { 25, 25, 25, 25 }, /* IDSEL 4 - PCI Slot 3 */
+ };
+
+ const long min_idsel = 1, max_idsel = 4, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+
+static void __init bamboo_set_emacdata(void)
+{
+ unsigned char * selection1_base;
+ struct ocp_def *def;
+ struct ocp_func_emac_data *emacdata;
+ u8 selection1_val;
+ int mode;
+
+ selection1_base = ioremap64(BAMBOO_FPGA_SELECTION1_REG_ADDR, 16);
+ selection1_val = readb(selection1_base);
+ iounmap((void *) selection1_base);
+ if (BAMBOO_SEL_MII(selection1_val))
+ mode = PHY_MODE_MII;
+ else if (BAMBOO_SEL_RMII(selection1_val))
+ mode = PHY_MODE_RMII;
+ else
+ mode = PHY_MODE_SMII;
+
+ /* Set mac_addr and phy mode for each EMAC */
+
+ def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
+ emacdata = def-additions;
+ memcpy(emacdata-mac_addr, __res.bi_enetaddr, 6);
+ emacdata-phy_mode = mode;
+
+ def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
+ emacdata = def-additions;
+ memcpy(emacdata-mac_addr, __res.bi_enet1addr, 6
[PATCH][3/3] ppc32: add bamboo defconfig
Add Bamboo platform defconfig Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com Signed-off-by: Matt Porter mporter at kernel.crashing.org diff --git a/arch/ppc/configs/bamboo_defconfig b/arch/ppc/configs/bamboo_defconfig new file mode 100644 --- /dev/null +++ b/arch/ppc/configs/bamboo_defconfig @@ -0,0 +1,943 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.12 +# Tue Jun 28 15:24:25 2005 +# +CONFIG_MMU=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_HAVE_DEC_LOCK=y +CONFIG_PPC=y +CONFIG_PPC32=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_CLEAN_COMPILE=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION= +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +CONFIG_SYSCTL=y +# CONFIG_AUDIT is not set +# CONFIG_HOTPLUG is not set +CONFIG_KOBJECT_UEVENT=y +# CONFIG_IKCONFIG is not set +CONFIG_EMBEDDED=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SHMEM=y +CONFIG_CC_ALIGN_FUNCTIONS=0 +CONFIG_CC_ALIGN_LABELS=0 +CONFIG_CC_ALIGN_LOOPS=0 +CONFIG_CC_ALIGN_JUMPS=0 +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 + +# +# Loadable module support +# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_OBSOLETE_MODPARM=y +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y + +# +# Processor +# +# CONFIG_6xx is not set +# CONFIG_40x is not set +CONFIG_44x=y +# CONFIG_POWER3 is not set +# CONFIG_POWER4 is not set +# CONFIG_8xx is not set +# CONFIG_E200 is not set +# CONFIG_E500 is not set +CONFIG_PPC_FPU=y +CONFIG_BOOKE=y +CONFIG_PTE_64BIT=y +CONFIG_PHYS_64BIT=y +# CONFIG_MATH_EMULATION is not set +# CONFIG_KEXEC is not set +# CONFIG_CPU_FREQ is not set +CONFIG_4xx=y + +# +# IBM 4xx options +# +CONFIG_BAMBOO=y +# CONFIG_EBONY is not set +# CONFIG_LUAN is not set +# CONFIG_OCOTEA is not set +CONFIG_440EP=y +CONFIG_440=y +CONFIG_IBM440EP_ERR42=y +CONFIG_IBM_OCP=y +# CONFIG_PPC4xx_DMA is not set +CONFIG_PPC_GEN550=y +# CONFIG_PM is not set +CONFIG_NOT_COHERENT_CACHE=y + +# +# Platform options +# +# CONFIG_PC_KEYBOARD is not set +# CONFIG_SMP is not set +# CONFIG_PREEMPT is not set +# CONFIG_HIGHMEM is not set +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_CMDLINE_BOOL=y +CONFIG_CMDLINE=ip=on +CONFIG_SECCOMP=y +CONFIG_ISA_DMA_API=y + +# +# Bus options +# +CONFIG_PCI=y +CONFIG_PCI_DOMAINS=y +# CONFIG_PCI_LEGACY_PROC is not set +# CONFIG_PCI_NAMES is not set +# CONFIG_PCI_DEBUG is not set + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# Advanced setup +# +# CONFIG_ADVANCED_OPTIONS is not set + +# +# Default settings for advanced configuration options are used +# +CONFIG_HIGHMEM_START=0xfe00 +CONFIG_LOWMEM_SIZE=0x3000 +CONFIG_KERNEL_START=0xc000 +CONFIG_TASK_SIZE=0x8000 +CONFIG_CONSISTENT_START=0xff10 +CONFIG_CONSISTENT_SIZE=0x0020 +CONFIG_BOOT_LOAD=0x0100 + +# +# Device Drivers +# + +# +# Generic Driver Options +# +# CONFIG_STANDALONE is not set +CONFIG_PREVENT_FIRMWARE_BUILD=y +# CONFIG_FW_LOADER is not set +# CONFIG_DEBUG_DRIVER is not set + +# +# Memory Technology Devices (MTD) +# +# CONFIG_MTD is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# + +# +# Block devices +# +# CONFIG_BLK_DEV_FD is not set +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +# CONFIG_BLK_DEV_LOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_UB is not set +# CONFIG_BLK_DEV_RAM is not set +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_INITRAMFS_SOURCE= +# CONFIG_LBD is not set +# CONFIG_CDROM_PKTCDVD is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_ATA_OVER_ETH is not set + +# +# ATA/ATAPI/MFM/RLL support +# +CONFIG_IDE=y +CONFIG_BLK_DEV_IDE=y + +# +# Please see Documentation/ide.txt for help/info on IDE drives +# +# CONFIG_BLK_DEV_IDE_SATA is not set +CONFIG_BLK_DEV_IDEDISK=y +# CONFIG_IDEDISK_MULTI_MODE is not set +# CONFIG_BLK_DEV_IDECD is not set +# CONFIG_BLK_DEV_IDETAPE is not set +# CONFIG_BLK_DEV_IDEFLOPPY is not set +# CONFIG_BLK_DEV_IDESCSI is not set +# CONFIG_IDE_TASK_IOCTL is not set + +# +# IDE chipset support/bugfixes
[PATCH][1/3] ppc32: add 440ep support
Add PPC440EP core support. PPC440EP is a PPC440-based SoC with
a classic PPC FPU and another set of peripherals.
Signed-off-by: Wade Farnsworth wfarnsworth at mvista.com
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
--- a/arch/ppc/boot/simple/Makefile
+++ b/arch/ppc/boot/simple/Makefile
@@ -61,6 +61,12 @@ zimageinitrd-$(CONFIG_IBM_OPENBIOS) := z
end-$(CONFIG_EMBEDDEDBOOT):= embedded
misc-$(CONFIG_EMBEDDEDBOOT):= misc-embedded.o
+ zimage-$(CONFIG_BAMBOO) := zImage-TREE
+zimageinitrd-$(CONFIG_BAMBOO) := zImage.initrd-TREE
+ end-$(CONFIG_BAMBOO) := bamboo
+ entrypoint-$(CONFIG_BAMBOO) := 0x0100
+ extra.o-$(CONFIG_BAMBOO) := pibs.o
+
zimage-$(CONFIG_EBONY) := zImage-TREE
zimageinitrd-$(CONFIG_EBONY) := zImage.initrd-TREE
end-$(CONFIG_EBONY) := ebony
diff --git a/arch/ppc/boot/simple/pibs.c b/arch/ppc/boot/simple/pibs.c
--- a/arch/ppc/boot/simple/pibs.c
+++ b/arch/ppc/boot/simple/pibs.c
@@ -91,9 +91,11 @@ load_kernel(unsigned long load_addr, int
mac64 = simple_strtoull((char *)PIBS_MAC_BASE, 0, 16);
memcpy(hold_residual-bi_enetaddr, (char *)mac64+2, 6);
-#ifdef CONFIG_440GX
+#if defined(CONFIG_440GX) || defined(CONFIG_440EP)
mac64 = simple_strtoull((char *)(PIBS_MAC_BASE+PIBS_MAC_OFFSET), 0, 16);
memcpy(hold_residual-bi_enet1addr, (char *)mac64+2, 6);
+#endif
+#ifdef CONFIG_440GX
mac64 = simple_strtoull((char *)(PIBS_MAC_BASE+PIBS_MAC_OFFSET*2), 0,
16);
memcpy(hold_residual-bi_enet2addr, (char *)mac64+2, 6);
mac64 = simple_strtoull((char *)(PIBS_MAC_BASE+PIBS_MAC_OFFSET*3), 0,
16);
diff --git a/arch/ppc/kernel/cputable.c b/arch/ppc/kernel/cputable.c
--- a/arch/ppc/kernel/cputable.c
+++ b/arch/ppc/kernel/cputable.c
@@ -852,6 +852,26 @@ struct cpu_speccpu_specs[] = {
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
+ {
+ .pvr_mask = 0xffff,
+ .pvr_value = 0x4850,
+ .cpu_name = 440EP Rev. A,
+ .cpu_features = CPU_FTR_SPLIT_ID_CACHE |
+ CPU_FTR_USE_TB,
+ .cpu_user_features = COMMON_PPC, /* 440EP has an FPU */
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ },
+ {
+ .pvr_mask = 0xffff,
+ .pvr_value = 0x48d3,
+ .cpu_name = 440EP Rev. B,
+ .cpu_features = CPU_FTR_SPLIT_ID_CACHE |
+ CPU_FTR_USE_TB,
+ .cpu_user_features = COMMON_PPC, /* 440EP has an FPU */
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ },
{ /* 440GP Rev. B */
.pvr_mask = 0xffff,
.pvr_value = 0x4440,
diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
--- a/arch/ppc/kernel/entry.S
+++ b/arch/ppc/kernel/entry.S
@@ -215,6 +215,7 @@ syscall_dotrace_cont:
lwzxr10,r10,r0 /* Fetch system call handler [ptr] */
mtlrr10
addir9,r1,STACK_FRAME_OVERHEAD
+ PPC440EP_ERR42
blrl/* Call handler */
.globl ret_from_syscall
ret_from_syscall:
diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
--- a/arch/ppc/kernel/head_44x.S
+++ b/arch/ppc/kernel/head_44x.S
@@ -190,7 +190,9 @@ skpinv: addir4,r4,1 /*
Increment */
/* xlat fields */
lis r4,UART0_PHYS_IO_BASE at h /* RPN depends on SoC */
+#ifndef CONFIG_440EP
ori r4,r4,0x0001/* ERPN is 1 for second 4GB page */
+#endif
/* attrib fields */
li r5,0
@@ -228,6 +230,16 @@ skpinv:addir4,r4,1 /*
Increment */
lis r4,interrupt_base at h /* IVPR only uses the high 16-bits */
mtspr SPRN_IVPR,r4
+#ifdef CONFIG_440EP
+ /* Clear DAPUIB flag in CCR0 (enable APU between CPU and FPU) */
+ mfspr r2,SPRN_CCR0
+ lis r3,0xffef
+ ori r3,r3,0x
+ and r2,r2,r3
+ mtspr SPRN_CCR0,r2
+ isync
+#endif
+
/*
* This is where the main kernel code starts.
*/
diff --git a/arch/ppc/kernel/misc.S b/arch/ppc/kernel/misc.S
--- a/arch/ppc/kernel/misc.S
+++ b/arch/ppc/kernel/misc.S
@@ -1145,6 +1145,7 @@ _GLOBAL(kernel_thread)
stwur0,-16(r1)
mtlrr30 /* fn addr in lr */
mr r3,r31 /* load arg and call fn */
+ PPC440EP_ERR42
blrl
li r0,__NR_exit/* exit if function returns */
li r3,0
diff --git a/arch/ppc/platforms
AMCC 440EP (Bamboo board) support?
On Fri, Jul 22, 2005 at 06:17:25AM -0500, Josh Boyer wrote: On Fri, 2005-07-22 at 12:02 +0200, Gerhard Jaeger wrote: On Friday 22 July 2005 11:47, Frank Lautenbach wrote: Did anyone bring up linux already on this kind of board? If yes, please let me know. If not, any hints how to start from scratch starting with a kernel tree are higly welcome! Regards, Frank Yes, works for me here - Kernel 2.6.12 + Wade Farnsworth patches. and our own toolchain (see my sig ;) Speaking of which... when will those patches go upstream? Wade? I've only been waiting on updated patches that use the fpu.S code. If you'll recall, that was the major hold-up when they were posted before. I talked to Wade recently and he was busy with some other things but is planning on posting an update...at which point it will go upstream. -Matt
ppc_sys.c with platform device model or create opb bus?
On Sun, Jul 17, 2005 at 03:26:21PM +0900, Yasushi SHOJI wrote: Hi all, I've been reading some posts regarding to the transition of OCP to platform device mode while searching for a good way to implement a device driver for our fpga base platform. And now I have one question regarding to ppc_sys.c should I use ppc_sys_*() for platform like fpga? since I'm working on FPGA base platform, ppc_sys_spec seems to be too static. that is, IMHO, having static array of device list isn't ideal for a dynamic system like fpga. I feel that the ppc_sys_spec is for SoC, which doesn't dynamically change the peripherals it has. otoh, fpga based platform can have arbitrary number of devices if you configured so. I usually implement a device with PLB or OPB. for those bus, should I use platform device model or create new buses for each? Use the platform model. When you run into a case that can't be handled properly then the platform model should be expanded to handle it. If you instantiate a platform device by configuring the FPGA from userspace then that's a hotplug event. The platform model should be extended to handle hotplug for these kind of cases since they are pretty common. -Matt
[PATCH 0/3] Support for SPI busses and devices
On Sat, Jul 23, 2005 at 10:04:07AM -0400, Grant Likely wrote: Request for Comment: Here is a set of patches that adds SPI support to linux. I'm looking for feedback on these and I'd like to eventually get the SPI infrastructure into mainline There is also another attempt at an SPI subsystem (not based on the RMK code) that was posted to lkml. You might want to check out http://lkml.org/lkml/2005/5/31/162 for the original posting and then an updated version at http://lkml.org/lkml/2005/6/23/161 -Matt
mmap on 440gx
On Fri, Jun 17, 2005 at 01:42:07AM -0400, Ed Goforth wrote: On 6/17/05, Matt Porter mporter at kernel.crashing.org wrote: On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote: On 6/16/05, Matt Porter mporter at kernel.crashing.org wrote: On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote: Thanks for taking the time to reply. I've been struggling with implementing mmap on a 440gx-based custom board. I have been able to use ioremap(), but we really need a mmap() for our software. The kernel is 2.4.18 (TimeSys 4.0). For what it's worth, __pa(0x5000_) returns 0x9000_. Sure, you just asked it to subtract KERNELBASE from a physical address. Don't use __pa() in drivers. That's expected behavior. Why are you doing that? Desperation. Heh, I like that. :) snip Put some debug statements throughout fixup_bigphys_addr() to see what's going on. My include/asm/mmu.h has it defined as: #ifndef CONFIG_440 #include asm-generic/mmu.h #else typedef unsigned long long phys_addr_t; #define fixup_bigphys_addr(addr, size) (addr) #endif I see that in later 2.4 kernels and in mainline 2.6 it is implemented as an actual working routine. Perhaps that explains it all. The ioremap() in my tree implements the fixup code inline, which would explain why it works, right? It sure does. That code is 100% wrong. Just merge in mainline 2.4 stuff and you should be golden. -Matt
Adding RapidIO to Linux
On Thu, Jun 16, 2005 at 01:44:48PM +0300, Avni Hillel-R58467 wrote: Hi Matt, I want to install: [PATCH][1/3] RapidIO support: core [PATCH][2/3] RapidIO support: ppc32 [PATCH][3/3] RapidIO support: net driver over messaging 1. What specific version of Linux should I start from? 2.6.12-rc6 is the latest release that you can apply these against. Or they can go against the linux-2.6 git tree. 2. Are there any more patches that are relevant to RIO? Several sets of patches were posted after this set, and then there were several additions posted against the -mm tree. Check the list archives, I cced this list on everything. You could get the 2.6.12-rc6-mm1 patch which has a later version of these patches. There are additional changes in the -mm tree but there isn't a unified patch of them until another -mm patch is released. -Matt
mmap on 440gx
On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote: On 6/16/05, Matt Porter mporter at kernel.crashing.org wrote: On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote: Thanks for taking the time to reply. I've been struggling with implementing mmap on a 440gx-based custom board. I have been able to use ioremap(), but we really need a mmap() for our software. The kernel is 2.4.18 (TimeSys 4.0). There are some special things done for handling [io]_remap_page/pfn_range on other vendor kernels and the current mainline kernel. I'm not sure if your vendor kernel addressed them since it would be a vendor-specific patch in that timeframe. The special things are due to 36-bit addressing. I'm trying to access one of our FPGA's located at 0x5000. Offsets Let's start at the beginning. How do you have FPGA's at 0x5000? that address falls with the fix DDR SDRAM area on the 440GX memory map. All peripheral and EBC space is mapped by 4GB. You lost me right here. Oh wait, are you referring to the least significant 32-bits of the physical mapping. It's not really at 0x5000. Of course, you're correct. The 36-bit base address is 0x1__. It is mapped to the 32-bit address 0x5000_. That's an interesting way to look at it but there isn't really a mapping. You have configured a EBC chip selects to decode at 1_5000_. Should I pass the 36-bit address to remap_page_range()? No, it takes a 32-bit physical address and fixes it up using the fixup_bigphys_addr() method. Double check that the trap ranges are correct for you board port. They need to be modified to add the appropriate MS 4-bit. Since ioremap() also uses fixup_bigphys_addr() to fixup 32-bit addresses to 36-bit, it should just work. For what it's worth, __pa(0x5000_) returns 0x9000_. Sure, you just asked it to subtract KERNELBASE from a physical address. Don't use __pa() in drivers. That's expected behavior. Why are you doing that? You need something like the bigphys_remap patch for 2.4 that can be found at ftp://source.mvista.com/pub/linuxppc/ I just checked the source, and that patch has indeed been applied. Ok, assuming it's all correct then I don't know why it does work for you in your vendor tree. Have you asked Timesys for help? Put some debug statements throughout fixup_bigphys_addr() to see what's going on. -Matt
[PATCH][MM] ppc32: enable rapidio on mpc85xx ads boards
Enables RIO on the MPC8540/8560 ADS ref boards. RIO can be used
with a crossover cable between two of them.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
@@ -47,6 +47,8 @@
#include mm/mmu_decl.h
+#include syslib/ppc85xx_rio.h
+
#include platforms/85xx/mpc85xx_ads_common.h
#ifndef CONFIG_PCI
@@ -223,3 +225,11 @@ mpc85xx_exclude_device(u_char bus, u_cha
}
#endif /* CONFIG_PCI */
+
+#ifdef CONFIG_RAPIDIO
+void platform_rio_init(void)
+{
+ /* 512MB RIO LAW at 0xc000 */
+ mpc85xx_rio_setup(0xc000, 0x2000);
+}
+#endif /* CONFIG_RAPIDIO */
Read in /dev/port with Segmentation Fault
On Thu, Jun 09, 2005 at 09:30:43AM +0200, scarayol at assystembrime.com wrote: Hi all, I want to access to IO ports on a MPC885. The iopl() is not implemented, in my distribution, to use inw() outw(). So I use /dev/port. It works for open(/dev/port,..) and lseek() but when i do a read() i have a segmentation fault. I gave all the right to /dev/port Does anybody have an idea ? You are trying to use x86-specific interfaces to x86-specific IO space. By IO ports you must mean memory mapped I/O registers since you are on PPC. From userspace, use mmap() to map physical address space to a user virtual address range. -Matt
R?f. : Re: Read in /dev/port with Segmentation Fault
On Thu, Jun 09, 2005 at 11:30:53AM +0200, scarayol at assystembrime.com wrote: Matt, then what is the use of /dev/port driver file ? When i do cat /dev/port on the standard console, i have also a segmentation fault. Well, it's of no use on PPC. It's an x86-specific driver. It is simply an alternative method to access x86 I/O ports. This is a hardware construct that simply does not exist on PPC. Another question, if i use mmap to map physical addresses of I/O registers, could i dereference the pointer on virtual adresse to access data or should i use read/write on the file descriptor ? Yes you can dereference, that's the point of mmaping I/O into userspace. You may want to read Linux Device Drivers (either hardcopy or free version online) for more details. If you google around you'll find countless examples of people doing simple userspace driver work via mmaped regs...those might help as a guideline. -Matt
[PATCH][3/5] RapidIO support: core enum
On Mon, Jun 06, 2005 at 11:19:50PM -0600, Zwane Mwaikambo wrote:
On Mon, 6 Jun 2005, Matt Porter wrote:
+spinlock_t rio_global_list_lock = SPIN_LOCK_UNLOCKED;
spin_lock_init?
How about DEFINE_SPINLOCK() as they do the same thing (except the
difference in amount of babble)? This is what PCI is doing, for
example. I use the same init method in the static locks found
in rio-access.c, FWIW.
+extern struct rio_route_ops __start_rio_route_ops[];
+extern struct rio_route_ops __end_rio_route_ops[];
rio.h?
Yep, will move.
+static void
+rio_set_device_id(struct rio_mport *port, u16 destid, u8 hopcount, u16 did)
Shouldn't those be on the same line?
Yes, will fix.
+static int rio_device_has_destid(struct rio_mport *port, int src_ops,
+int dst_ops)
+{
+ if (((src_ops RIO_SRC_OPS_READ) ||
+(src_ops RIO_SRC_OPS_WRITE) ||
+(src_ops RIO_SRC_OPS_ATOMIC_TST_SWP) ||
+(src_ops RIO_SRC_OPS_ATOMIC_INC) ||
+(src_ops RIO_SRC_OPS_ATOMIC_DEC) ||
+(src_ops RIO_SRC_OPS_ATOMIC_SET) ||
+(src_ops RIO_SRC_OPS_ATOMIC_CLR))
+ ((dst_ops RIO_DST_OPS_READ) ||
+(dst_ops RIO_DST_OPS_WRITE) ||
+(dst_ops RIO_DST_OPS_ATOMIC_TST_SWP) ||
+(dst_ops RIO_DST_OPS_ATOMIC_INC) ||
+(dst_ops RIO_DST_OPS_ATOMIC_DEC) ||
+(dst_ops RIO_DST_OPS_ATOMIC_SET) ||
+(dst_ops RIO_DST_OPS_ATOMIC_CLR))) {
+ return 1;
Why not just;
mask = (RIO_DST_OPS_READ | RIO_DST_OPS_WRITE)
return !!((dst_ops mask) (src_ops mask))
Yes, that's good. I already had that comment from an IRC discussion
and neglected to address it in the last updates. Will do.
+ rdev-dev.dma_mask = (u64 *) 0x;
+ rdev-dev.coherent_dma_mask = 0xULL;
Shouldn't that be dma_set_mask?
There is a problem there, yes, but it shouldn't use dma_set_mask().
dma_set_mask() needs [struct device]-dma_mask to be non-zero
(initialized to something) to do anything in all the copied
implementations I've seen. I need to do something like the
following to initialize the struct device dma_mask properly:
rdev-dma_mask = 0xULL;
rdev-dev.dma_mask = rdev-dma_mask;
-Matt
[PATCH] rapidio: core updates
Addresses issues raised with the 2.6.12-rc6-mm1 RIO support.
Fix dma_mask init, shrink some code, general cleanup.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c
--- a/drivers/rapidio/rio-scan.c
+++ b/drivers/rapidio/rio-scan.c
@@ -15,6 +15,7 @@
#include linux/kernel.h
#include linux/delay.h
+#include linux/dma-mapping.h
#include linux/init.h
#include linux/rio.h
#include linux/rio_drv.h
@@ -33,7 +34,8 @@ static LIST_HEAD(rio_switches);
static void rio_enum_timeout(unsigned long);
-spinlock_t rio_global_list_lock = SPIN_LOCK_UNLOCKED;
+DEFINE_SPINLOCK(rio_global_list_lock);
+
static int next_destid = 0;
static int next_switchid = 0;
static int next_net = 0;
@@ -55,9 +57,6 @@ static int rio_sport_phys_table[] = {
-1,
};
-extern struct rio_route_ops __start_rio_route_ops[];
-extern struct rio_route_ops __end_rio_route_ops[];
-
/**
* rio_get_device_id - Get the base/extended device id for a device
* @port: RIO master port
@@ -85,8 +84,7 @@ static u16 rio_get_device_id(struct rio_
*
* Writes the base/extended device id from a device.
*/
-static void
-rio_set_device_id(struct rio_mport *port, u16 destid, u8 hopcount, u16 did)
+static void rio_set_device_id(struct rio_mport *port, u16 destid, u8 hopcount,
u16 did)
{
rio_mport_write_config_32(port, destid, hopcount, RIO_DID_CSR,
RIO_SET_DID(did));
@@ -192,23 +190,9 @@ static int rio_enum_host(struct rio_mpor
static int rio_device_has_destid(struct rio_mport *port, int src_ops,
int dst_ops)
{
- if (((src_ops RIO_SRC_OPS_READ) ||
-(src_ops RIO_SRC_OPS_WRITE) ||
-(src_ops RIO_SRC_OPS_ATOMIC_TST_SWP) ||
-(src_ops RIO_SRC_OPS_ATOMIC_INC) ||
-(src_ops RIO_SRC_OPS_ATOMIC_DEC) ||
-(src_ops RIO_SRC_OPS_ATOMIC_SET) ||
-(src_ops RIO_SRC_OPS_ATOMIC_CLR))
- ((dst_ops RIO_DST_OPS_READ) ||
-(dst_ops RIO_DST_OPS_WRITE) ||
-(dst_ops RIO_DST_OPS_ATOMIC_TST_SWP) ||
-(dst_ops RIO_DST_OPS_ATOMIC_INC) ||
-(dst_ops RIO_DST_OPS_ATOMIC_DEC) ||
-(dst_ops RIO_DST_OPS_ATOMIC_SET) ||
-(dst_ops RIO_DST_OPS_ATOMIC_CLR))) {
- return 1;
- } else
- return 0;
+ u32 mask = RIO_OPS_READ | RIO_OPS_WRITE | RIO_OPS_ATOMIC_TST_SWP |
RIO_OPS_ATOMIC_INC | RIO_OPS_ATOMIC_DEC | RIO_OPS_ATOMIC_SET |
RIO_OPS_ATOMIC_CLR;
+
+ return !!((src_ops | dst_ops) mask);
}
/**
@@ -383,8 +367,9 @@ static struct rio_dev *rio_setup_device(
rdev-dev.release = rio_release_dev;
rio_dev_get(rdev);
- rdev-dev.dma_mask = (u64 *) 0x;
- rdev-dev.coherent_dma_mask = 0xULL;
+ rdev-dma_mask = DMA_32BIT_MASK;
+ rdev-dev.dma_mask = rdev-dma_mask;
+ rdev-dev.coherent_dma_mask = DMA_32BIT_MASK;
if ((rdev-pef RIO_PEF_INB_DOORBELL)
(rdev-dst_ops RIO_DST_OPS_DOORBELL))
diff --git a/drivers/rapidio/rio.h b/drivers/rapidio/rio.h
--- a/drivers/rapidio/rio.h
+++ b/drivers/rapidio/rio.h
@@ -26,6 +26,9 @@ extern int rio_disc_mport(struct rio_mpo
extern struct device_attribute rio_dev_attrs[];
extern spinlock_t rio_global_list_lock;
+extern struct rio_route_ops __start_rio_route_ops[];
+extern struct rio_route_ops __end_rio_route_ops[];
+
/* Helpers internal to the RIO core code */
#define DECLARE_RIO_ROUTE_SECTION(section, vid, did, add_hook, get_hook) \
static struct rio_route_ops __rio_route_ops __attribute_used__ \
diff --git a/include/linux/rio.h b/include/linux/rio.h
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -91,6 +91,7 @@ struct rio_mport;
* @swpinfo: Switch port info
* @src_ops: Source operation capabilities
* @dst_ops: Destination operation capabilities
+ * @dma_mask: Mask of bits of RIO address this device implements
* @rswitch: Pointer to struct rio_switch if valid for this device
* @driver: Driver claiming this device
* @dev: Device model device
@@ -112,6 +113,7 @@ struct rio_dev {
u32 swpinfo;/* Only used for switches */
u32 src_ops;
u32 dst_ops;
+ u64 dma_mask;
struct rio_switch *rswitch; /* RIO switch info */
struct rio_driver *driver; /* RIO driver claiming this device */
struct device dev; /* LDM device structure */
diff --git a/include/linux/rio_regs.h b/include/linux/rio_regs.h
--- a/include/linux/rio_regs.h
+++ b/include/linux/rio_regs.h
@@ -78,6 +78,19 @@
#define RIO_DST_OPS_ATOMIC_CLR0x0010 /* [I] Atomic
clr op */
#define RIO_DST_OPS_PORT_WRITE0x0004 /* [I]
Port-write op */
+#define RIO_OPS_READ 0x8000 /* [I] Read op */
+#define RIO_OPS_WRITE 0x4000 /* [I] Write op */
+#define
[PATCH][4/5] RapidIO support: ppc32
On Tue, Jun 07, 2005 at 11:43:26PM -0500, Kumar Gala wrote: Two questions: 1. how well does will all of this handle 32-bit phys addr? It does and it doesn't handle 32-bit phys addr. It depends on which configuration you are talking about. If you are talking about I/O 32-bit, it's no problem. If you are talking about handling DMA 32-bit, then we need to handle a 64-bit DMA addr in the ppc32 implementations and also extend the arch messaging interface to let callers know when an implementation can handle high DMA (system memory 4GB). This is all pretty easy to handle once we need to support such a processor. So far, nothing is available publicly. :) For RIO MMIO purposes (which is functionality I'm working on now), it has the similar issues that PCI memory space has on processors with I/O above 4GB. However, on RIO our resources hold a bus address since a physical address doesn't make sense since address spaces our per-device. If we ever support a 66-bit address space device on 32-bit processor, we might need a u64 resource. 2. can we make any of this a platform driver? Hrm, so you would rather see RIO host bridges look like a driver on another bus? I have seen them as a component just like PCI host bridges. That is, they are instantiated by arch-code and then initialized by a subsys initcall. This does mean that we will be enumerating much later (during driver initcalls), but it might be a better model if we ever see a rumored PCIE-RIO bridge. Supporting that as a RIO master port would require driver time init of the RIO fabric. There's some ordering issues that we'd have to see about working out. None of this is needed right now, though. I would prefer if we could have the memory offsets and irq's not be straight from the #define's I think this and #2 are separate issues. We can pass the mpc85xx rio init code some parameters to abstract things to different parts. This is similar to how we init different SoC's PCI host bridges with some common code on PPC32 (marvell, 85xx, etc). I was just looking at doing this to support RIO on the 8548. At the time I wrote this 85xx support there wasn't any info on the 8548 available, but it's an easy thing to extend. -Matt
[PATCH][4/5] RapidIO support: ppc32
Adds PPC32 RIO support. Init code for the MPC85xx RIO ports and glue for the STx GP3 board to use it. Signed-off-by: Matt Porter mporter at kernel.crashing.org diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig --- a/arch/ppc/Kconfig +++ b/arch/ppc/Kconfig @@ -1177,6 +1177,14 @@ source drivers/pci/Kconfig source drivers/pcmcia/Kconfig +config RAPIDIO + bool RapidIO support if MPC8540 || MPC8560 + help + If you say Y here, the kernel will include drivers and + infrastructure code to support RapidIO interconnect devices. + +source drivers/rio/Kconfig + endmenu menu Advanced setup diff --git a/arch/ppc/configs/stx_gp3_defconfig b/arch/ppc/configs/stx_gp3_defconfig --- a/arch/ppc/configs/stx_gp3_defconfig +++ b/arch/ppc/configs/stx_gp3_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.11-rc2 -# Wed Jan 26 14:32:58 2005 +# Linux kernel version: 2.6.12-rc4 +# Tue May 24 18:11:04 2005 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y @@ -11,6 +11,7 @@ CONFIG_HAVE_DEC_LOCK=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # # Code maturity level options @@ -18,6 +19,7 @@ CONFIG_GENERIC_NVRAM=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup @@ -29,7 +31,6 @@ CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set -CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set @@ -37,6 +38,9 @@ CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set @@ -46,6 +50,7 @@ CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 # # Loadable module support @@ -69,9 +74,11 @@ CONFIG_KMOD=y CONFIG_E500=y CONFIG_BOOKE=y CONFIG_FSL_BOOKE=y +# CONFIG_PHYS_64BIT is not set # CONFIG_SPE is not set CONFIG_MATH_EMULATION=y # CONFIG_CPU_FREQ is not set +# CONFIG_PM is not set CONFIG_85xx=y CONFIG_PPC_INDIRECT_PCI_BE=y @@ -96,6 +103,7 @@ CONFIG_HIGHMEM=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_CMDLINE_BOOL is not set +CONFIG_ISA_DMA_API=y # # Bus options @@ -104,15 +112,15 @@ CONFIG_PCI=y CONFIG_PCI_DOMAINS=y # CONFIG_PCI_LEGACY_PROC is not set # CONFIG_PCI_NAMES is not set +# CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set - -# -# PC-card bridges -# +CONFIG_RAPIDIO=y +CONFIG_RAPIDIO_8_BIT_TRANSPORT=y +CONFIG_RAPIDIO_DISC_TIMEOUT=30 # # Advanced setup @@ -152,7 +160,7 @@ CONFIG_PARPORT=m CONFIG_PARPORT_PC=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set -# CONFIG_PARPORT_OTHER is not set +# CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_1284 is not set # @@ -264,7 +272,6 @@ CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set -# CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set @@ -274,7 +281,6 @@ CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set -# CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=m @@ -283,6 +289,7 @@ CONFIG_SCSI_QLA2XXX=m # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set +# CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set @@ -322,7 +329,6 @@ CONFIG_NET=y # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set -# CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y @@ -431,7 +437,7 @@ CONFIG_IP_NF_NAT_FTP=m # # Network testing # -# CONFIG_NET_PKTGEN is not set +CONFIG_NET_PKTGEN=y # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set @@ -499,6 +505,7 @@ CONFIG_GFAR_NAPI=y # Wan interfaces # # CONFIG_WAN is not set +CONFIG_RIONET=y # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set @@ -536,20 +543,6 @@ CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # -# Input I/O drivers -# -# CONFIG_GAMEPORT is not set -CONFIG_SOUND_GAMEPORT=y -CONFIG_SERIO=y -CONFIG_SERIO_I8042=y -CONFIG_SERIO_SERPORT=y -# CONFIG_SERIO_CT82C710 is not set -# CONFIG_SERIO_PARKBD is not set -# CONFIG_SERIO_PCIPS2 is not set -CONFIG_SERIO_LIBPS2=y -# CONFIG_SERIO_RAW is not set - -# # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y @@ -567,6 +560,19 @@ CONFIG_MOUSE_PS2=y # CONFIG_INPUT_MISC is not set # +# Hardware I/O ports
[PATCH][3/5] RapidIO support: core enum
Adds RapidIO enumeration/discovery.
The core code implements enumeration/discovery, management of
devices/resources, and interfaces for RIO drivers.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/drivers/rio/rio-scan.c b/drivers/rio/rio-scan.c
new file mode 100644
--- /dev/null
+++ b/drivers/rio/rio-scan.c
@@ -0,0 +1,960 @@
+/*
+ * RapidIO enumeration and discovery support
+ *
+ * Copyright 2005 MontaVista Software, Inc.
+ * Matt Porter mporter at kernel.crashing.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/config.h
+#include linux/types.h
+#include linux/kernel.h
+
+#include linux/delay.h
+#include linux/init.h
+#include linux/rio.h
+#include linux/rio_drv.h
+#include linux/rio_ids.h
+#include linux/rio_regs.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/timer.h
+
+#include rio.h
+
+LIST_HEAD(rio_devices);
+static LIST_HEAD(rio_switches);
+
+#define RIO_ENUM_CMPL_MAGIC0xdeadbeef
+
+static void rio_enum_timeout(unsigned long);
+
+spinlock_t rio_global_list_lock = SPIN_LOCK_UNLOCKED;
+static int next_destid = 0;
+static int next_switchid = 0;
+static int next_net = 0;
+
+static struct timer_list rio_enum_timer =
+TIMER_INITIALIZER(rio_enum_timeout, 0, 0);
+
+static int rio_mport_phys_table[] = {
+ RIO_EFB_PAR_EP_ID,
+ RIO_EFB_PAR_EP_REC_ID,
+ RIO_EFB_SER_EP_ID,
+ RIO_EFB_SER_EP_REC_ID,
+ -1,
+};
+
+static int rio_sport_phys_table[] = {
+ RIO_EFB_PAR_EP_FREE_ID,
+ RIO_EFB_SER_EP_FREE_ID,
+ -1,
+};
+
+extern struct rio_route_ops __start_rio_route_ops[];
+extern struct rio_route_ops __end_rio_route_ops[];
+
+/**
+ * rio_get_device_id - Get the base/extended device id for a device
+ * @port: RIO master port
+ * @destid: Destination ID of device
+ * @hopcount: Hopcount to device
+ *
+ * Reads the base/extended device id from a device. Returns the
+ * 8/16-bit device ID.
+ */
+static u16 rio_get_device_id(struct rio_mport *port, u16 destid, u8 hopcount)
+{
+ u32 result;
+
+ rio_mport_read_config_32(port, destid, hopcount, RIO_DID_CSR, result);
+
+ return RIO_GET_DID(result);
+}
+
+/**
+ * rio_set_device_id - Set the base/extended device id for a device
+ * @port: RIO master port
+ * @destid: Destination ID of device
+ * @hopcount: Hopcount to device
+ * @did: Device ID value to be written
+ *
+ * Writes the base/extended device id from a device.
+ */
+static void
+rio_set_device_id(struct rio_mport *port, u16 destid, u8 hopcount, u16 did)
+{
+ rio_mport_write_config_32(port, destid, hopcount, RIO_DID_CSR,
+ RIO_SET_DID(did));
+}
+
+/**
+ * rio_local_set_device_id - Set the base/extended device id for a port
+ * @port: RIO master port
+ * @did: Device ID value to be written
+ *
+ * Writes the base/extended device id from a device.
+ */
+static void rio_local_set_device_id(struct rio_mport *port, u16 did)
+{
+ rio_local_write_config_32(port, RIO_DID_CSR, RIO_SET_DID(did));
+}
+
+/**
+ * rio_clear_locks- Release all host locks and signal enumeration complete
+ * @port: Master port to issue transaction
+ *
+ * Marks the component tag CSR on each device with the enumeration
+ * complete flag. When complete, it then release the host locks on
+ * each device. Returns 0 on success or %-EINVAL on failure.
+ */
+static int rio_clear_locks(struct rio_mport *port)
+{
+ struct rio_dev *rdev;
+ u32 result;
+ int ret = 0;
+
+ /* Write component tag CSR magic complete value */
+ rio_local_write_config_32(port, RIO_COMPONENT_TAG_CSR,
+ RIO_ENUM_CMPL_MAGIC);
+ list_for_each_entry(rdev, rio_devices, global_list)
+ rio_write_config_32(rdev, RIO_COMPONENT_TAG_CSR,
+ RIO_ENUM_CMPL_MAGIC);
+
+ /* Release host device id locks */
+ rio_local_write_config_32(port, RIO_HOST_DID_LOCK_CSR,
+ port-host_deviceid);
+ rio_local_read_config_32(port, RIO_HOST_DID_LOCK_CSR, result);
+ if ((result 0x) != 0x) {
+ printk(KERN_INFO
+ RIO: badness when releasing host lock on master port,
result %8.8x\n,
+ result);
+ ret = -EINVAL;
+ }
+ list_for_each_entry(rdev, rio_devices, global_list) {
+ rio_write_config_32(rdev, RIO_HOST_DID_LOCK_CSR,
+ port-host_deviceid);
+ rio_read_config_32(rdev, RIO_HOST_DID_LOCK_CSR, result);
+ if ((result 0x) != 0x) {
+ printk(KERN_INFO
+ RIO: badness when releasing host lock on vid
%4.4x did %4.4x\n
[PATCH][2/5] RapidIO support: core includes
Add RapidIO core include files.
The core code implements enumeration/discovery, management of
devices/resources, and interfaces for RIO drivers.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/include/linux/rio.h b/include/linux/rio.h
new file mode 100644
--- /dev/null
+++ b/include/linux/rio.h
@@ -0,0 +1,321 @@
+/*
+ * RapidIO interconnect services
+ * (RapidIO Interconnect Specification, http://www.rapidio.org)
+ *
+ * Copyright 2005 MontaVista Software, Inc.
+ * Matt Porter mporter at kernel.crashing.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef LINUX_RIO_H
+#define LINUX_RIO_H
+
+#ifdef __KERNEL__
+
+#include linux/types.h
+#include linux/config.h
+#include linux/ioport.h
+#include linux/list.h
+#include linux/errno.h
+#include linux/device.h
+#include linux/rio_regs.h
+
+#define RIO_ANY_DESTID 0xff
+#define RIO_NO_HOPCOUNT-1
+
+#define RIO_MAX_MPORT_RESOURCES16
+#define RIO_MAX_DEV_RESOURCES 16
+
+#define RIO_GLOBAL_TABLE 0xff/* Indicates access of a switch's
+ global routing table if it
+ has multiple (or per port)
+ tables */
+
+#define RIO_INVALID_ROUTE 0xff/* Indicates that a route table
+ entry is invalid (no route
+ exists for the device ID) */
+
+#ifdef CONFIG_RAPIDIO_8_BIT_TRANSPORT
+#define RIO_MAX_ROUTE_ENTRIES (1 8)
+#else
+#define RIO_MAX_ROUTE_ENTRIES (1 16)
+#endif
+
+#define RIO_MAX_MBOX 4
+#define RIO_MAX_MSG_SIZE 0x1000
+
+/*
+ * Error values that may be returned by RIO functions.
+ */
+#define RIO_SUCCESSFUL 0x00
+#define RIO_BAD_SIZE 0x81
+
+/*
+ * For RIO devices, the region numbers are assigned this way:
+ *
+ * 0 RapidIO outbound doorbells
+ * 1-15 RapidIO memory regions
+ *
+ * For RIO master ports, the region number are assigned this way:
+ *
+ * 0 RapidIO inbound doorbells
+ * 1 RapidIO inbound mailboxes
+ * 1 RapidIO outbound mailboxes
+ */
+#define RIO_DOORBELL_RESOURCE 0
+#define RIO_INB_MBOX_RESOURCE 1
+#define RIO_OUTB_MBOX_RESOURCE 2
+
+extern struct bus_type rio_bus_type;
+extern struct list_head rio_devices; /* list of all devices */
+
+struct rio_mport;
+
+/**
+ * struct rio_dev - RIO device info
+ * @global_list: Node in list of all RIO devices
+ * @net_list: Node in list of RIO devices in a network
+ * @net: Network this device is a part of
+ * @did: Device ID
+ * @vid: Vendor ID
+ * @device_rev: Device revision
+ * @asm_did: Assembly device ID
+ * @asm_vid: Assembly vendor ID
+ * @asm_rev: Assembly revision
+ * @efptr: Extended feature pointer
+ * @pef: Processing element features
+ * @swpinfo: Switch port info
+ * @src_ops: Source operation capabilities
+ * @dst_ops: Destination operation capabilities
+ * @rswitch: Pointer to struct rio_switch if valid for this device
+ * @driver: Driver claiming this device
+ * @dev: Device model device
+ * @riores: RIO resources this device owns
+ * @destid: Network destination ID
+ */
+struct rio_dev {
+ struct list_head global_list; /* node in list of all RIO devices */
+ struct list_head net_list; /* node in per net list */
+ struct rio_net *net;/* RIO net this device resides in */
+ u16 did;
+ u16 vid;
+ u32 device_rev;
+ u16 asm_did;
+ u16 asm_vid;
+ u16 asm_rev;
+ u16 efptr;
+ u32 pef;
+ u32 swpinfo;/* Only used for switches */
+ u32 src_ops;
+ u32 dst_ops;
+ struct rio_switch *rswitch; /* RIO switch info */
+ struct rio_driver *driver; /* RIO driver claiming this device */
+ struct device dev; /* LDM device structure */
+ struct resource riores[RIO_MAX_DEV_RESOURCES];
+ u16 destid;
+};
+
+#define rio_dev_g(n) list_entry(n, struct rio_dev, global_list)
+#define rio_dev_f(n) list_entry(n, struct rio_dev, net_list)
+#defineto_rio_dev(n) container_of(n, struct rio_dev, dev)
+
+/**
+ * struct rio_msg - RIO message event
+ * @res: Mailbox resource
+ * @mcback: Message event callback
+ */
+struct rio_msg {
+ struct resource *res;
+ void (*mcback) (struct rio_mport * mport, int mbox, int slot);
+};
+
+/**
+ * struct rio_dbell - RIO doorbell event
+ * @node: Node in list of doorbell events
+ * @res: Doorbell resource
+ * @dinb: Doorbell event callback
+ */
+struct rio_dbell {
+ struct list_head node;
+ struct resource *res;
+ void (*dinb) (struct rio_mport * mport, u16 src, u16 dst, u16 info);
+};
+
+/**
+ * struct rio_mport
[PATCH][1/5] RapidIO support: core base
[Updated with latest comments] Adds a RapidIO subsystem to the kernel. RIO is a switched fabric interconnect used in higher-end embedded applications. The curious can look at the specs over at http://www.rapidio.org The core code implements enumeration/discovery, management of devices/resources, and interfaces for RIO drivers. There's a lot more to do to take advantages of all the hardware features. However, this should provide a good base for folks with RIO hardware to start contributing. Signed-off-by: Matt Porter mporter at kernel.crashing.org diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -10,7 +10,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mc kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ procfs-guide.xml writing_usb_driver.xml scsidrivers.xml \ sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \ - gadget.xml libata.xml mtdnand.xml librs.xml + gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml ### # The build process is as follows (targets): diff --git a/Documentation/DocBook/rapidio.tmpl b/Documentation/DocBook/rapidio.tmpl new file mode 100644 --- /dev/null +++ b/Documentation/DocBook/rapidio.tmpl @@ -0,0 +1,160 @@ +?xml version=1.0 encoding=UTF-8? +!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd; [ + !ENTITY rapidio SYSTEM rapidio.xml + ] + +book id=RapidIO-Guide + bookinfo + titleRapidIO Subsystem Guide/title + + authorgroup + author +firstnameMatt/firstname +surnamePorter/surname +affiliation + address + emailmporter at kernel.crashing.org/email + emailmporter at mvista.com/email + /address +/affiliation + /author + /authorgroup + + copyright + year2005/year + holderMontaVista Software, Inc./holder + /copyright + + legalnotice + para + This documentation is free software; you can redistribute + it and/or modify it under the terms of the GNU General Public + License version 2 as published by the Free Software Foundation. + /para + + para + This program is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the GNU General Public License for more details. + /para + + para + You should have received a copy of the GNU General Public + License along with this program; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, + MA 02111-1307 USA + /para + + para + For more details see the file COPYING in the source + distribution of Linux. + /para + /legalnotice + /bookinfo + +toc/toc + + chapter id=intro + titleIntroduction/title + para + RapidIO is a high speed switched fabric interconnect with + features aimed at the embedded market. RapidIO provides + support for memory-mapped I/O as well as message-based + transactions over the switched fabric network. RapidIO has + a standardized discovery mechanism not unlike the PCI bus + standard that allows simple detection of devices in a + network. + /para + para + This documentation is provided for developers intending + to support RapidIO on new architectures, write new drivers, + or to understand the subsystem internals. + /para + /chapter + + chapter id=bugs + titleKnown Bugs and Limitations/title + + sect1 + titleBugs/title + paraNone. ;)/para + /sect1 + sect1 + titleLimitations/title + para + orderedlist + listitemparaAccess/management of RapidIO memory regions is not supported/para/listitem + listitemparaMultiple host enumeration is not supported/para/listitem + /orderedlist +/para + /sect1 + /chapter + + chapter id=drivers + titleRapidIO driver interface/title + para + Drivers are provided a set of calls in order + to interface with the subsystem to gather info + on devices, request/map memory region resources, + and manage mailboxes/doorbells. + /para + sect1 + titleFunctions/title +!Iinclude/linux/rio_drv.h +!Edrivers/rio/rio-driver.c +!Edrivers/rio/rio.c + /sect1 + /chapter + + chapter id=internals + titleInternals/title + + para + This chapter contains the autogenerated documentation of the RapidIO + subsystem. + /para + + sect1titleStructures/title +!Iinclude/linux/rio.h + /sect1 + sect1titleEnumeration and Discovery/title +!Idrivers/rio/rio-scan.c + /sect1 + sect1titleDriver functionality/title +!Idrivers/rio/rio.c +!Idrivers/rio/rio-access.c + /sect1
[PATCH][5/5] RapidIO support: net driver
Adds an Ethernet driver which sends Ethernet packets over the
standard RapidIO messaging. This depends on the core RIO
patch for mailbox/doorbell access.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2185,6 +2185,20 @@ config ISERIES_VETH
tristate iSeries Virtual Ethernet driver support
depends on NETDEVICES PPC_ISERIES
+config RIONET
+ tristate RapidIO Ethernet over messaging driver support
+ depends on NETDEVICES RAPIDIO
+
+config RIONET_TX_SIZE
+ int Number of outbound queue entries
+ depends on RIONET
+ default 128
+
+config RIONET_RX_SIZE
+ int Number of inbound queue entries
+ depends on RIONET
+ default 128
+
config FDDI
bool FDDI driver support
depends on NETDEVICES (PCI || EISA)
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_SKFP) += skfp/
obj-$(CONFIG_VIA_RHINE) += via-rhine.o
obj-$(CONFIG_VIA_VELOCITY) += via-velocity.o
obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o
+obj-$(CONFIG_RIONET) += rionet.o
#
# end link order section
diff --git a/drivers/net/rionet.c b/drivers/net/rionet.c
new file mode 100644
--- /dev/null
+++ b/drivers/net/rionet.c
@@ -0,0 +1,597 @@
+/*
+ * rionet - Ethernet driver over RapidIO messaging services
+ *
+ * Copyright 2005 MontaVista Software, Inc.
+ * Matt Porter mporter at kernel.crashing.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/dma-mapping.h
+#include linux/delay.h
+#include linux/rio.h
+#include linux/rio_drv.h
+#include linux/rio_ids.h
+
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/skbuff.h
+#include linux/crc32.h
+#include linux/ethtool.h
+
+#define DRV_NAMErionet
+#define DRV_VERSION 0.1
+#define DRV_AUTHOR Matt Porter mporter at kernel.crashing.org
+#define DRV_DESCEthernet over RapidIO
+
+MODULE_AUTHOR(DRV_AUTHOR);
+MODULE_DESCRIPTION(DRV_DESC);
+MODULE_LICENSE(GPL);
+
+#define RIONET_DEFAULT_MSGLEVEL0
+#define RIONET_DOORBELL_JOIN 0x1000
+#define RIONET_DOORBELL_LEAVE 0x1001
+
+#define RIONET_MAILBOX 0
+
+#define RIONET_TX_RING_SIZECONFIG_RIONET_TX_SIZE
+#define RIONET_RX_RING_SIZECONFIG_RIONET_RX_SIZE
+
+static LIST_HEAD(rionet_peers);
+
+struct rionet_private {
+ struct rio_mport *mport;
+ struct sk_buff *rx_skb[RIONET_RX_RING_SIZE];
+ struct sk_buff *tx_skb[RIONET_TX_RING_SIZE];
+ struct net_device_stats stats;
+ int rx_slot;
+ int tx_slot;
+ int tx_cnt;
+ int ack_slot;
+ spinlock_t lock;
+ spinlock_t tx_lock;
+ u32 msg_enable;
+};
+
+struct rionet_peer {
+ struct list_head node;
+ struct rio_dev *rdev;
+ struct resource *res;
+};
+
+static int rionet_check = 0;
+static int rionet_capable = 1;
+static struct net_device *sndev = NULL;
+
+/*
+ * This is a fast lookup table for for translating TX
+ * Ethernet packets into a destination RIO device. It
+ * could be made into a hash table to save memory depending
+ * on system trade-offs.
+ */
+static struct rio_dev *rionet_active[RIO_MAX_ROUTE_ENTRIES];
+
+#define is_rionet_capable(pef, src_ops, dst_ops) \
+ ((pef RIO_PEF_INB_MBOX) \
+(pef RIO_PEF_INB_DOORBELL) \
+(src_ops RIO_SRC_OPS_DOORBELL) \
+(dst_ops RIO_DST_OPS_DOORBELL))
+#define dev_rionet_capable(dev) \
+ is_rionet_capable(dev-pef, dev-src_ops, dev-dst_ops)
+
+#define RIONET_MAC_MATCH(x)(*(u32 *)x == 0x00010001)
+#define RIONET_GET_DESTID(x) (*(u16 *)(x + 4))
+
+static struct net_device_stats *rionet_stats(struct net_device *ndev)
+{
+ struct rionet_private *rnet = ndev-priv;
+ return rnet-stats;
+}
+
+static int rionet_rx_clean(struct net_device *ndev)
+{
+ int i;
+ int error = 0;
+ struct rionet_private *rnet = ndev-priv;
+ void *data;
+
+ i = rnet-rx_slot;
+
+ do {
+ if (!rnet-rx_skb[i]) {
+ rnet-stats.rx_dropped++;
+ continue;
+ }
+
+ if (!(data = rio_get_inb_message(rnet-mport, RIONET_MAILBOX)))
+ break;
+
+ rnet-rx_skb[i]-data = data;
+ skb_put(rnet-rx_skb[i], RIO_MAX_MSG_SIZE);
+ rnet-rx_skb[i]-dev = ndev;
+ rnet-rx_skb[i]-protocol =
+ eth_type_trans(rnet-rx_skb[i], ndev);
+ error = netif_rx(rnet
[PATCH][RIO] -mm: Fix macro indenting
Fix up indenting that Lindent fubared. Signed-off-by: Matt Porter mporter at kernel.crashing.org commit 87ff3372a005e4cf927b1b62c23e1c2339d46507 tree 16e1d9454a95a4a1e8b9e50dacd218f8e14dfe14 parent 6e9e41d480cf54c69d47df11f5cba696461ebe1a author Matt Porter mporter at kernel.crashing.org Mon, 06 Jun 2005 09:23:49 -0700 committer Matt Porter mporter at kernel.crashing.org Mon, 06 Jun 2005 09:23:49 -0700 drivers/rio/rio-access.c | 24 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/rio/rio-access.c b/drivers/rio/rio-access.c --- a/drivers/rio/rio-access.c +++ b/drivers/rio/rio-access.c @@ -77,13 +77,13 @@ int __rio_local_write_config_##size \ } RIO_LOP_READ(8, u8, 1) -RIO_LOP_READ(16, u16, 2) -RIO_LOP_READ(32, u32, 4) -RIO_LOP_WRITE(8, u8, 1) -RIO_LOP_WRITE(16, u16, 2) -RIO_LOP_WRITE(32, u32, 4) +RIO_LOP_READ(16, u16, 2) +RIO_LOP_READ(32, u32, 4) +RIO_LOP_WRITE(8, u8, 1) +RIO_LOP_WRITE(16, u16, 2) +RIO_LOP_WRITE(32, u32, 4) -EXPORT_SYMBOL(__rio_local_read_config_8); +EXPORT_SYMBOL(__rio_local_read_config_8); EXPORT_SYMBOL(__rio_local_read_config_16); EXPORT_SYMBOL(__rio_local_read_config_32); EXPORT_SYMBOL(__rio_local_write_config_8); @@ -137,13 +137,13 @@ int rio_mport_write_config_##size \ } RIO_OP_READ(8, u8, 1) -RIO_OP_READ(16, u16, 2) -RIO_OP_READ(32, u32, 4) -RIO_OP_WRITE(8, u8, 1) -RIO_OP_WRITE(16, u16, 2) -RIO_OP_WRITE(32, u32, 4) +RIO_OP_READ(16, u16, 2) +RIO_OP_READ(32, u32, 4) +RIO_OP_WRITE(8, u8, 1) +RIO_OP_WRITE(16, u16, 2) +RIO_OP_WRITE(32, u32, 4) -EXPORT_SYMBOL(rio_mport_read_config_8); +EXPORT_SYMBOL(rio_mport_read_config_8); EXPORT_SYMBOL(rio_mport_read_config_16); EXPORT_SYMBOL(rio_mport_read_config_32); EXPORT_SYMBOL(rio_mport_write_config_8);
[PATCH][RIO] -mm: sysfs config space fixes
Fix sysfs config space access similar to the recent PCI sysfs changes.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
commit 2a28743938495ab6055db2e29f3e0721bba022cc
tree 09d592a46eff8592327b20c609595eb8b7d5e333
parent d45c2d2fedcafd50a860267ff1d517c3071ab585
author Matt Porter mporter at kernel.crashing.org Mon, 06 Jun 2005 14:50:28
-0700
committer Matt Porter mporter at kernel.crashing.org Mon, 06 Jun 2005
14:50:28 -0700
drivers/rio/rio-sysfs.c | 82 +--
1 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/drivers/rio/rio-sysfs.c b/drivers/rio/rio-sysfs.c
--- a/drivers/rio/rio-sysfs.c
+++ b/drivers/rio/rio-sysfs.c
@@ -74,10 +74,11 @@ rio_read_config(struct kobject *kobj, ch
to_rio_dev(container_of(kobj, struct device, kobj));
unsigned int size = 0x100;
loff_t init_off = off;
+ u8 *data = (u8 *) buf;
/* Several chips lock up trying to read undefined config space */
if (capable(CAP_SYS_ADMIN))
- size = 0x8;
+ size = 0x20;
if (off size)
return 0;
@@ -88,30 +89,47 @@ rio_read_config(struct kobject *kobj, ch
size = count;
}
- while (off 3) {
- unsigned char val;
+ if ((off 1) size) {
+ u8 val;
rio_read_config_8(dev, off, val);
- buf[off - init_off] = val;
+ data[off - init_off] = val;
off++;
- if (--size == 0)
- break;
+ size--;
+ }
+
+ if ((off 3) size 2) {
+ u16 val;
+ rio_read_config_16(dev, off, val);
+ data[off - init_off] = (val 8) 0xff;
+ data[off - init_off + 1] = val 0xff;
+ off += 2;
+ size -= 2;
}
while (size 3) {
- unsigned int val;
+ u32 val;
rio_read_config_32(dev, off, val);
- buf[off - init_off] = (val 24) 0xff;
- buf[off - init_off + 1] = (val 16) 0xff;
- buf[off - init_off + 2] = (val 8) 0xff;
- buf[off - init_off + 3] = val 0xff;
+ data[off - init_off] = (val 24) 0xff;
+ data[off - init_off + 1] = (val 16) 0xff;
+ data[off - init_off + 2] = (val 8) 0xff;
+ data[off - init_off + 3] = val 0xff;
off += 4;
size -= 4;
}
- while (size 0) {
- unsigned char val;
+ if (size = 2) {
+ u16 val;
+ rio_read_config_16(dev, off, val);
+ data[off - init_off] = (val 8) 0xff;
+ data[off - init_off + 1] = val 0xff;
+ off += 2;
+ size -= 2;
+ }
+
+ if (size 0) {
+ u8 val;
rio_read_config_8(dev, off, val);
- buf[off - init_off] = val;
+ data[off - init_off] = val;
off++;
--size;
}
@@ -126,6 +144,7 @@ rio_write_config(struct kobject *kobj, c
to_rio_dev(container_of(kobj, struct device, kobj));
unsigned int size = count;
loff_t init_off = off;
+ u8 *data = (u8 *) buf;
if (off 0x20)
return 0;
@@ -134,25 +153,40 @@ rio_write_config(struct kobject *kobj, c
count = size;
}
- while (off 3) {
- rio_write_config_8(dev, off, buf[off - init_off]);
+ if ((off 1) size) {
+ rio_write_config_8(dev, off, data[off - init_off]);
off++;
- if (--size == 0)
- break;
+ size--;
+ }
+
+ if ((off 3) (size 2)) {
+ u16 val = data[off - init_off + 1];
+ val |= (u16) data[off - init_off] 8;
+ rio_write_config_16(dev, off, val);
+ off += 2;
+ size -= 2;
}
while (size 3) {
- unsigned int val = buf[off - init_off + 3];
- val |= (unsigned int)buf[off - init_off + 2] 8;
- val |= (unsigned int)buf[off - init_off + 1] 16;
- val |= (unsigned int)buf[off - init_off] 24;
+ u32 val = data[off - init_off + 3];
+ val |= (u32) data[off - init_off + 2] 8;
+ val |= (u32) data[off - init_off + 1] 16;
+ val |= (u32) data[off - init_off] 24;
rio_write_config_32(dev, off, val);
off += 4;
size -= 4;
}
- while (size 0) {
- rio_write_config_8(dev, off, buf[off - init_off]);
+ if (size = 2) {
+ u16 val = data[off - init_off + 1];
+ val |= (u16) data[off - init_off] 8;
+ rio_write_config_16(dev, off, val
[PATCH][RIO] -mm: rionet updates
Cleanups, eliminate unused paths, and add LLTX support.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
commit d651f0979ebfb203624159507a2b04ac896844ab
tree c9dffe54b25b6992025f074de1fe9901adc8d6ef
parent 7cfb63a2fce0dbb82507bb6035352df1718624f2
author Matt Porter mporter at kernel.crashing.org Mon, 06 Jun 2005 13:57:52
-0700
committer Matt Porter mporter at kernel.crashing.org Mon, 06 Jun 2005
13:57:52 -0700
drivers/net/rionet.c | 73 --
1 files changed, 24 insertions(+), 49 deletions(-)
diff --git a/drivers/net/rionet.c b/drivers/net/rionet.c
--- a/drivers/net/rionet.c
+++ b/drivers/net/rionet.c
@@ -42,7 +42,7 @@ MODULE_LICENSE(GPL);
#define RIONET_TX_RING_SIZECONFIG_RIONET_TX_SIZE
#define RIONET_RX_RING_SIZECONFIG_RIONET_RX_SIZE
-LIST_HEAD(rionet_peers);
+static LIST_HEAD(rionet_peers);
struct rionet_private {
struct rio_mport *mport;
@@ -54,6 +54,7 @@ struct rionet_private {
int tx_cnt;
int ack_slot;
spinlock_t lock;
+ spinlock_t tx_lock;
u32 msg_enable;
};
@@ -112,9 +113,9 @@ static int rionet_rx_clean(struct net_de
rnet-rx_skb[i]-data = data;
skb_put(rnet-rx_skb[i], RIO_MAX_MSG_SIZE);
- rnet-rx_skb[i]-dev = sndev;
+ rnet-rx_skb[i]-dev = ndev;
rnet-rx_skb[i]-protocol =
- eth_type_trans(rnet-rx_skb[i], sndev);
+ eth_type_trans(rnet-rx_skb[i], ndev);
error = netif_rx(rnet-rx_skb[i]);
if (error == NET_RX_DROP) {
@@ -183,13 +184,20 @@ static int rionet_start_xmit(struct sk_b
struct rionet_private *rnet = ndev-priv;
struct ethhdr *eth = (struct ethhdr *)skb-data;
u16 destid;
+ unsigned long flags;
- spin_lock_irq(rnet-lock);
-
+ local_irq_save(flags);
+ if (!spin_trylock(rnet-tx_lock)) {
+ local_irq_restore(flags);
+ return NETDEV_TX_LOCKED;
+ }
+
if ((rnet-tx_cnt + 1) RIONET_TX_RING_SIZE) {
netif_stop_queue(ndev);
- spin_unlock_irq(rnet-lock);
- return -EBUSY;
+ spin_unlock_irqrestore(rnet-tx_lock, flags);
+ printk(KERN_ERR %s: BUG! Tx Ring full when queue awake!\n,
+ ndev-name);
+ return NETDEV_TX_BUSY;
}
if (eth-h_dest[0] 0x01) {
@@ -211,7 +219,7 @@ static int rionet_start_xmit(struct sk_b
rionet_queue_tx_msg(skb, ndev, rionet_active[destid]);
}
- spin_unlock_irq(rnet-lock);
+ spin_unlock_irqrestore(rnet-tx_lock, flags);
return 0;
}
@@ -228,27 +236,6 @@ static int rionet_set_mac_address(struct
return 0;
}
-static int rionet_change_mtu(struct net_device *ndev, int new_mtu)
-{
- struct rionet_private *rnet = ndev-priv;
-
- if (netif_msg_drv(rnet))
- printk(KERN_WARNING
- %s: rionet_change_mtu(): not implemented\n, DRV_NAME);
-
- return 0;
-}
-
-static void rionet_set_multicast_list(struct net_device *ndev)
-{
- struct rionet_private *rnet = ndev-priv;
-
- if (netif_msg_drv(rnet))
- printk(KERN_WARNING
- %s: rionet_set_multicast_list(): not implemented\n,
- DRV_NAME);
-}
-
static void rionet_dbell_event(struct rio_mport *mport, u16 sid, u16 tid,
u16 info)
{
@@ -358,10 +345,6 @@ static int rionet_open(struct net_device
rnet-tx_cnt = 0;
rnet-ack_slot = 0;
- spin_lock_init(rnet-lock);
-
- rnet-msg_enable = RIONET_DEFAULT_MSGLEVEL;
-
netif_carrier_on(ndev);
netif_start_queue(ndev);
@@ -434,11 +417,6 @@ static void rionet_remove(struct rio_dev
}
}
-static int rionet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
-{
- return -EOPNOTSUPP;
-}
-
static void rionet_get_drvinfo(struct net_device *ndev,
struct ethtool_drvinfo *info)
{
@@ -464,16 +442,11 @@ static void rionet_set_msglevel(struct n
rnet-msg_enable = value;
}
-static u32 rionet_get_link(struct net_device *ndev)
-{
- return netif_carrier_ok(ndev);
-}
-
static struct ethtool_ops rionet_ethtool_ops = {
.get_drvinfo = rionet_get_drvinfo,
.get_msglevel = rionet_get_msglevel,
.set_msglevel = rionet_set_msglevel,
- .get_link = rionet_get_link,
+ .get_link = ethtool_op_get_link,
};
static int rionet_setup_netdev(struct rio_mport *mport)
@@ -517,16 +490,18 @@ static int rionet_setup_netdev(struct ri
ndev-hard_start_xmit = rionet_start_xmit;
ndev-stop = rionet_close;
ndev-get_stats = rionet_stats;
- ndev-change_mtu = rionet_change_mtu;
ndev-set_mac_address = rionet_set_mac_address;
- ndev-set_multicast_list = rionet_set_multicast_list
[PATCH][1/5] RapidIO support: core
On Fri, Jun 03, 2005 at 12:11:33AM -0700, Greg KH wrote:
On Thu, Jun 02, 2005 at 02:03:59PM -0700, Matt Porter wrote:
+RIO_LOP_READ(8, u8, 1)
+RIO_LOP_READ(16, u16, 2)
+RIO_LOP_READ(32, u32, 4)
+RIO_LOP_WRITE(8, u8, 1)
+RIO_LOP_WRITE(16, u16, 2)
+RIO_LOP_WRITE(32, u32, 4)
+
+EXPORT_SYMBOL(__rio_local_read_config_8);
+EXPORT_SYMBOL(__rio_local_read_config_16);
+EXPORT_SYMBOL(__rio_local_read_config_32);
+EXPORT_SYMBOL(__rio_local_write_config_8);
+EXPORT_SYMBOL(__rio_local_write_config_16);
+EXPORT_SYMBOL(__rio_local_write_config_32);
Odd indenting here.
Lindent got me here. I didn't doublecheck its munging on this file.
Updated that.
And why the __rio* stuff for public functions? You should drop the __
part.
This may seem silly but I was trying to have the automagic DocBook
stuff pick up the complete set of kernel interfaces without have
to duplicate anything in the DocBook template. Since these functions
are macro-generated I could have a comment block for each one that
the docs stuff would pick up. So, I put rio_local_*() up in
include/linux/rio_drv.h as inline wrappers around these implementations.
Too ugly to live? Maybe there's a better way to make this work, it
would nice to have it autogenerate the docs.
snip
+EXPORT_SYMBOL(rio_mport_send_doorbell);
Just a question, should these be EXPORT_SYMBOL_GPL() as this is GPL
code? Just to be explicit that is.
Good point. I'm going to go through and make all RIO interfaces
EXPORT_SYMBOL_GPL(). Embedded folks need the extra encouragement
to do the right thing when writing drivers.
+static ssize_t
+rio_read_config(struct kobject *kobj, char *buf, loff_t off, size_t count)
snip
You might want to compare this to the recent changes in the 2.6.12-rc
kernels in the pci sysfs config code. There were some 64 and endian
issues fixed up there that you might want to make sure are also done
properly here.
I see that in the current git tree. I think some of it applies (note
that RIO is a big-endian system, not surprising since it originates
from Motorola/Fscale), I'll look more closely and add the appropriate
fixes into the next patch. Since Andrew took these into -mm I will
just post patches against -mm.
+static struct bin_attribute rio_config_attr = {
+ .attr = {
+.name = config,
+.mode = S_IRUGO | S_IWUSR,
+.owner = THIS_MODULE,
+},
+ .size = 0x20,
+ .read = rio_read_config,
+ .write = rio_write_config,
+};
Wow, that's a huge config space (just a comment, not an issue...)
Heh, yes. The maintenance packets that are used to access config
space on RIO devices have a 21-bit offset field. I guess the
spec guys didn't want to run out of config space too quickly. :)
-Matt
[PATCH][1/5] RapidIO support: core
On Fri, Jun 03, 2005 at 12:20:27AM -0700, Greg KH wrote:
On Thu, Jun 02, 2005 at 02:03:59PM -0700, Matt Porter wrote:
+static struct device rio_bus = {
+ .bus_id = rapidio,
+};
Why do you need this device? You shouldn't have a static struct device
to start with. Or you just don't like having your root rio device
showing up in /sys/devices/ ?
Exactly. There's no hierarchy in this interconnect. So it seemed
that having a static rio_bus device made the most sense. Everything
exists as peers since it works more like a network than a hierarchical
bus like PCI. Right now, you can't see the endpoint which actually
implements your port into the switch fabric...there's no device
created for it. I'm still trying to determine if that should change
but it's not critical to usability with the current generation
hardware.
One argument I have _for_ it is that it would be easy to show
and manipulate a network from userspace if all nodes had a device
associated with them. That's not a real world problem yet so
I decided not to complicate things yet.
If so, just create a kobject and put it there, and then base your
devices off of it, no need for a real device.
Oh wait, that's what the platform and system code does. bah,
nevermind...
Ok. I did pull this part right from the platform code, in fact.
-Matt
[PATCH][5/5] RapidIO support: net driver over messaging
On Thu, Jun 02, 2005 at 03:05:43PM -0700, Stephen Hemminger wrote:
How much is this like ethernet? does it still do ARP?
It's nothing like Ethernet, the only relation is that an Ethernet network
driver is easy to implement over top of raw message ports on a switched
fabric network. It gives easy access to RIO messaging from userspace
without inventing a new interface.
ARP works by the driver emulating a broadcast over RIO by sending the
same ARP packet to each node that is participating in the rionet. Nodes
join/leave the rionet by sending RIO-specific doorbell messages to
potential participants on the switched fabric. A table is kept to
flag active participants such that a fast lookup can be made to translate
the dst MAC address to a RIO device struct that is used to actually
send the Ethernet packet encapsulated into a standard RIO message
to the appropriate node(s).
Can it do promiscious receive?
No.
+LIST_HEAD(rionet_peers);
Does this have to be global?
Nope, should be static. Fixing.
Not sure about the locking of this stuff, are you
relying on the RTNL?
Yes, last I looked that was sufficient for all the entry points.
I protect the driver-specific data (tx skb rings, etc.) with
a private lock.
+
+static int rionet_change_mtu(struct net_device *ndev, int new_mtu)
+{
+ struct rionet_private *rnet = ndev-priv;
+
+ if (netif_msg_drv(rnet))
+ printk(KERN_WARNING
+ %s: rionet_change_mtu(): not implemented\n, DRV_NAME);
+
+ return 0;
+}
If you can allow any mtu then don't need this at all.
Or if you are limited then better return an error for bad values.
Ok, I do have a upper limit of 4082 as the RIO messages have a
max 4096 byte payload. That's the default on open as well. I'll
fix this up.
+static void rionet_set_multicast_list(struct net_device *ndev)
+{
+ struct rionet_private *rnet = ndev-priv;
+
+ if (netif_msg_drv(rnet))
+ printk(KERN_WARNING
+ %s: rionet_set_multicast_list(): not implemented\n,
+ DRV_NAME);
+}
If you can't handle it then just leave dev-set_multicast_list
as NULL and all attempts to add or delete will get -EINVAL
Will do. It was a placeholder at one point when I thought I might
emulate multicast in the driver...it's fallen down my priority
list.
+
+static int rionet_open(struct net_device *ndev)
+{
+ /* Initialize inbound message ring */
+ for (i = 0; i RIONET_RX_RING_SIZE; i++)
+ rnet-rx_skb[i] = NULL;
+ rnet-rx_slot = 0;
+ rionet_rx_fill(ndev, 0);
+
+ rnet-tx_slot = 0;
+ rnet-tx_cnt = 0;
+ rnet-ack_slot = 0;
+
+ spin_lock_init(rnet-lock);
+
+ rnet-msg_enable = RIONET_DEFAULT_MSGLEVEL;
Better to do all initialization of the per device data
in the place it is allocated (rio_setup_netdev)
Right, will do.
+static int rionet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
+{
+ return -EOPNOTSUPP;
+}
Unneeded, if dev-do_ioctl is NULL, then all private ioctl's will
return -EINVAL that is what you want.
Ah, ok. Good, none of the MII stuff applies in this case.
+static u32 rionet_get_link(struct net_device *ndev)
+{
+ return netif_carrier_ok(ndev);
+}
Use ethtool_op_get_link
Ok
snip
+ /* Fill in the driver function table */
+ ndev-open = rionet_open;
+ ndev-hard_start_xmit = rionet_start_xmit;
+ ndev-stop = rionet_close;
+ ndev-get_stats = rionet_stats;
+ ndev-change_mtu = rionet_change_mtu;
+ ndev-set_mac_address = rionet_set_mac_address;
+ ndev-set_multicast_list = rionet_set_multicast_list;
+ ndev-do_ioctl = rionet_ioctl;
+ SET_ETHTOOL_OPS(ndev, rionet_ethtool_ops);
+
+ ndev-mtu = RIO_MAX_MSG_SIZE - 14;
+
+ SET_MODULE_OWNER(ndev);
Can you set any ndev-features to get better performance.
Can you take 32bit data addresses? then set HIGHDMA
You are doing your on locking, can you use LLTX?
Does the hardware support scatter gather?
Some of these get tricky. In general, rionet could support
SG and with driver help we can flag IP_CSUM. In practice, the
current generation MPC85xx HW on my development system have
some problems with their message port dma queues. In short,
their implementation is such that the arch-specific code is
forced to do a copy of the skb on both tx and rx. Because of
this, adding SG/IP_CSUM doesn't have any value yet...it'll make
sense to add the addtional features once we get a platform with
better messaging hardware. HIGHDMA may not be suitable on all
platforms. Since rionet sits on top of a hardware abstraction,
it doesn't have full knowledge of the DMA capabilities of the
hardware. We can eventually have some interfaces to the arch
code to learn that info, but it's not there yet. I have to
look into LLTX, I know what it stands for, but I'm not sure
of the details. Do you have a good LLTX example reference?
That said, my goal is
[PATCH][1/5] RapidIO support: core
Adds a RapidIO subsystem to the kernel. RIO is a switched fabric interconnect used in higher-end embedded applications. The curious can look at the specs over at http://www.rapidio.org The core code implements enumeration/discovery, management of devices/resources, and interfaces for RIO drivers. There's a lot more to do to take advantages of all the hardware features. However, this should provide a good base for folks with RIO hardware to start contributing. Signed-off-by: Matt Porter mporter at kernel.crashing.org Index: Documentation/DocBook/Makefile === --- 3c5e9440c6a37c3355b50608836a23c8fa4eec99/Documentation/DocBook/Makefile (mode:100644) +++ ca27a5320b5c022df402fce5cab0f3d9ea94/Documentation/DocBook/Makefile (mode:100644) @@ -10,7 +10,7 @@ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ procfs-guide.xml writing_usb_driver.xml scsidrivers.xml \ sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \ - gadget.xml libata.xml mtdnand.xml librs.xml + gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml ### # The build process is as follows (targets): Index: Documentation/DocBook/rapidio.tmpl === --- /dev/null (tree:3c5e9440c6a37c3355b50608836a23c8fa4eec99) +++ ca27a5320b5c022df402fce5cab0f3d9ea94/Documentation/DocBook/rapidio.tmpl (mode:100644) @@ -0,0 +1,160 @@ +?xml version=1.0 encoding=UTF-8? +!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd; [ + !ENTITY rapidio SYSTEM rapidio.xml + ] + +book id=RapidIO-Guide + bookinfo + titleRapidIO Subsystem Guide/title + + authorgroup + author +firstnameMatt/firstname +surnamePorter/surname +affiliation + address + emailmporter at kernel.crashing.org/email + emailmporter at mvista.com/email + /address +/affiliation + /author + /authorgroup + + copyright + year2005/year + holderMontaVista Software, Inc./holder + /copyright + + legalnotice + para + This documentation is free software; you can redistribute + it and/or modify it under the terms of the GNU General Public + License version 2 as published by the Free Software Foundation. + /para + + para + This program is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the GNU General Public License for more details. + /para + + para + You should have received a copy of the GNU General Public + License along with this program; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, + MA 02111-1307 USA + /para + + para + For more details see the file COPYING in the source + distribution of Linux. + /para + /legalnotice + /bookinfo + +toc/toc + + chapter id=intro + titleIntroduction/title + para + RapidIO is a high speed switched fabric interconnect with + features aimed at the embedded market. RapidIO provides + support for memory-mapped I/O as well as message-based + transactions over the switched fabric network. RapidIO has + a standardized discovery mechanism not unlike the PCI bus + standard that allows simple detection of devices in a + network. + /para + para + This documentation is provided for developers intending + to support RapidIO on new architectures, write new drivers, + or to understand the subsystem internals. + /para + /chapter + + chapter id=bugs + titleKnown Bugs and Limitations/title + + sect1 + titleBugs/title + paraNone. ;)/para + /sect1 + sect1 + titleLimitations/title + para + orderedlist + listitemparaAccess/management of RapidIO memory regions is not supported/para/listitem + listitemparaMultiple host enumeration is not supported/para/listitem + /orderedlist +/para + /sect1 + /chapter + + chapter id=drivers + titleRapidIO driver interface/title + para + Drivers are provided a set of calls in order + to interface with the subsystem to gather info + on devices, request/map memory region resources, + and manage mailboxes/doorbells. + /para + sect1 + titleFunctions/title +!Iinclude/linux/rio_drv.h +!Edrivers/rio/rio-driver.c +!Edrivers/rio/rio.c + /sect1 + /chapter + + chapter id=internals + titleInternals/title + + para + This chapter contains the autogenerated documentation of the RapidIO + subsystem. + /para + + sect1titleStructures/title +!Iinclude/linux/rio.h + /sect1
[PATCH][2/5] RapidIO support: core includes
Add RapidIO core include files.
The core code implements enumeration/discovery, management of
devices/resources, and interfaces for RIO drivers.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
Index: include/linux/rio.h
===
--- /dev/null (tree:ca27a5320b5c022df402fce5cab0f3d9ea94)
+++ 8d5a02e2174e1dad478b22653de9f2a346e1c996/include/linux/rio.h (mode:100644)
@@ -0,0 +1,321 @@
+/*
+ * RapidIO interconnect services
+ * (RapidIO Interconnect Specification, http://www.rapidio.org)
+ *
+ * Copyright 2005 MontaVista Software, Inc.
+ * Matt Porter mporter at kernel.crashing.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef LINUX_RIO_H
+#define LINUX_RIO_H
+
+#ifdef __KERNEL__
+
+#include linux/types.h
+#include linux/config.h
+#include linux/ioport.h
+#include linux/list.h
+#include linux/errno.h
+#include linux/device.h
+#include linux/rio_regs.h
+
+#define RIO_ANY_DESTID 0xff
+#define RIO_NO_HOPCOUNT-1
+
+#define RIO_MAX_MPORT_RESOURCES16
+#define RIO_MAX_DEV_RESOURCES 16
+
+#define RIO_GLOBAL_TABLE 0xff/* Indicates access of a switch's
+ global routing table if it
+ has multiple (or per port)
+ tables */
+
+#define RIO_INVALID_ROUTE 0xff/* Indicates that a route table
+ entry is invalid (no route
+ exists for the device ID) */
+
+#ifdef CONFIG_RAPIDIO_8_BIT_TRANSPORT
+#define RIO_MAX_ROUTE_ENTRIES (1 8)
+#else
+#define RIO_MAX_ROUTE_ENTRIES (1 16)
+#endif
+
+#define RIO_MAX_MBOX 4
+#define RIO_MAX_MSG_SIZE 0x1000
+
+/*
+ * Error values that may be returned by RIO functions.
+ */
+#define RIO_SUCCESSFUL 0x00
+#define RIO_BAD_SIZE 0x81
+
+/*
+ * For RIO devices, the region numbers are assigned this way:
+ *
+ * 0 RapidIO outbound doorbells
+ * 1-15 RapidIO memory regions
+ *
+ * For RIO master ports, the region number are assigned this way:
+ *
+ * 0 RapidIO inbound doorbells
+ * 1 RapidIO inbound mailboxes
+ * 1 RapidIO outbound mailboxes
+ */
+#define RIO_DOORBELL_RESOURCE 0
+#define RIO_INB_MBOX_RESOURCE 1
+#define RIO_OUTB_MBOX_RESOURCE 2
+
+extern struct bus_type rio_bus_type;
+extern struct list_head rio_devices; /* list of all devices */
+
+struct rio_mport;
+
+/**
+ * struct rio_dev - RIO device info
+ * @global_list: Node in list of all RIO devices
+ * @net_list: Node in list of RIO devices in a network
+ * @net: Network this device is a part of
+ * @did: Device ID
+ * @vid: Vendor ID
+ * @device_rev: Device revision
+ * @asm_did: Assembly device ID
+ * @asm_vid: Assembly vendor ID
+ * @asm_rev: Assembly revision
+ * @efptr: Extended feature pointer
+ * @pef: Processing element features
+ * @swpinfo: Switch port info
+ * @src_ops: Source operation capabilities
+ * @dst_ops: Destination operation capabilities
+ * @rswitch: Pointer to struct rio_switch if valid for this device
+ * @driver: Driver claiming this device
+ * @dev: Device model device
+ * @riores: RIO resources this device owns
+ * @destid: Network destination ID
+ */
+struct rio_dev {
+ struct list_head global_list; /* node in list of all RIO devices */
+ struct list_head net_list; /* node in per net list */
+ struct rio_net *net;/* RIO net this device resides in */
+ u16 did;
+ u16 vid;
+ u32 device_rev;
+ u16 asm_did;
+ u16 asm_vid;
+ u16 asm_rev;
+ u16 efptr;
+ u32 pef;
+ u32 swpinfo;/* Only used for switches */
+ u32 src_ops;
+ u32 dst_ops;
+ struct rio_switch *rswitch; /* RIO switch info */
+ struct rio_driver *driver; /* RIO driver claiming this device */
+ struct device dev; /* LDM device structure */
+ struct resource riores[RIO_MAX_DEV_RESOURCES];
+ u16 destid;
+};
+
+#define rio_dev_g(n) list_entry(n, struct rio_dev, global_list)
+#define rio_dev_f(n) list_entry(n, struct rio_dev, net_list)
+#defineto_rio_dev(n) container_of(n, struct rio_dev, dev)
+
+/**
+ * struct rio_msg - RIO message event
+ * @res: Mailbox resource
+ * @mcback: Message event callback
+ */
+struct rio_msg {
+ struct resource *res;
+ void (*mcback) (struct rio_mport * mport, int mbox, int slot);
+};
+
+/**
+ * struct rio_dbell - RIO doorbell event
+ * @node: Node in list of doorbell events
+ * @res: Doorbell resource
+ * @dinb: Doorbell event callback
+ */
+struct rio_dbell {
+ struct list_head node;
+ struct
[PATCH][3/5] RapidIO support: enumeration
Adds RapidIO enumeration/discovery.
The core code implements enumeration/discovery, management of
devices/resources, and interfaces for RIO drivers.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
Index: drivers/rio/rio-scan.c
===
--- /dev/null (tree:8d5a02e2174e1dad478b22653de9f2a346e1c996)
+++ b4a27e4c90f11413fa6828321141c43cb9ad6c12/drivers/rio/rio-scan.c
(mode:100644)
@@ -0,0 +1,960 @@
+/*
+ * RapidIO enumeration and discovery support
+ *
+ * Copyright 2005 MontaVista Software, Inc.
+ * Matt Porter mporter at kernel.crashing.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/config.h
+#include linux/types.h
+#include linux/kernel.h
+
+#include linux/delay.h
+#include linux/init.h
+#include linux/rio.h
+#include linux/rio_drv.h
+#include linux/rio_ids.h
+#include linux/rio_regs.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/timer.h
+
+#include rio.h
+
+LIST_HEAD(rio_devices);
+static LIST_HEAD(rio_switches);
+
+#define RIO_ENUM_CMPL_MAGIC0xdeadbeef
+
+static void rio_enum_timeout(unsigned long);
+
+spinlock_t rio_global_list_lock = SPIN_LOCK_UNLOCKED;
+static int next_destid = 0;
+static int next_switchid = 0;
+static int next_net = 0;
+
+static struct timer_list rio_enum_timer =
+TIMER_INITIALIZER(rio_enum_timeout, 0, 0);
+
+static int rio_mport_phys_table[] = {
+ RIO_EFB_PAR_EP_ID,
+ RIO_EFB_PAR_EP_REC_ID,
+ RIO_EFB_SER_EP_ID,
+ RIO_EFB_SER_EP_REC_ID,
+ -1,
+};
+
+static int rio_sport_phys_table[] = {
+ RIO_EFB_PAR_EP_FREE_ID,
+ RIO_EFB_SER_EP_FREE_ID,
+ -1,
+};
+
+extern struct rio_route_ops __start_rio_route_ops[];
+extern struct rio_route_ops __end_rio_route_ops[];
+
+/**
+ * rio_get_device_id - Get the base/extended device id for a device
+ * @port: RIO master port
+ * @destid: Destination ID of device
+ * @hopcount: Hopcount to device
+ *
+ * Reads the base/extended device id from a device. Returns the
+ * 8/16-bit device ID.
+ */
+static u16 rio_get_device_id(struct rio_mport *port, u16 destid, u8 hopcount)
+{
+ u32 result;
+
+ rio_mport_read_config_32(port, destid, hopcount, RIO_DID_CSR, result);
+
+ return RIO_GET_DID(result);
+}
+
+/**
+ * rio_set_device_id - Set the base/extended device id for a device
+ * @port: RIO master port
+ * @destid: Destination ID of device
+ * @hopcount: Hopcount to device
+ * @did: Device ID value to be written
+ *
+ * Writes the base/extended device id from a device.
+ */
+static void
+rio_set_device_id(struct rio_mport *port, u16 destid, u8 hopcount, u16 did)
+{
+ rio_mport_write_config_32(port, destid, hopcount, RIO_DID_CSR,
+ RIO_SET_DID(did));
+}
+
+/**
+ * rio_local_set_device_id - Set the base/extended device id for a port
+ * @port: RIO master port
+ * @did: Device ID value to be written
+ *
+ * Writes the base/extended device id from a device.
+ */
+static void rio_local_set_device_id(struct rio_mport *port, u16 did)
+{
+ rio_local_write_config_32(port, RIO_DID_CSR, RIO_SET_DID(did));
+}
+
+/**
+ * rio_clear_locks- Release all host locks and signal enumeration complete
+ * @port: Master port to issue transaction
+ *
+ * Marks the component tag CSR on each device with the enumeration
+ * complete flag. When complete, it then release the host locks on
+ * each device. Returns 0 on success or %-EINVAL on failure.
+ */
+static int rio_clear_locks(struct rio_mport *port)
+{
+ struct rio_dev *rdev;
+ u32 result;
+ int ret = 0;
+
+ /* Write component tag CSR magic complete value */
+ rio_local_write_config_32(port, RIO_COMPONENT_TAG_CSR,
+ RIO_ENUM_CMPL_MAGIC);
+ list_for_each_entry(rdev, rio_devices, global_list)
+ rio_write_config_32(rdev, RIO_COMPONENT_TAG_CSR,
+ RIO_ENUM_CMPL_MAGIC);
+
+ /* Release host device id locks */
+ rio_local_write_config_32(port, RIO_HOST_DID_LOCK_CSR,
+ port-host_deviceid);
+ rio_local_read_config_32(port, RIO_HOST_DID_LOCK_CSR, result);
+ if ((result 0x) != 0x) {
+ printk(KERN_INFO
+ RIO: badness when releasing host lock on master port,
result %8.8x\n,
+ result);
+ ret = -EINVAL;
+ }
+ list_for_each_entry(rdev, rio_devices, global_list) {
+ rio_write_config_32(rdev, RIO_HOST_DID_LOCK_CSR,
+ port-host_deviceid);
+ rio_read_config_32(rdev, RIO_HOST_DID_LOCK_CSR, result);
+ if ((result 0x) != 0x) {
+ printk(KERN_INFO
[PATCH][4/5] RapidIO support: ppc32
Adds PPC32 RIO support. Init code for the MPC85xx RIO ports and glue for the STx GP3 board to use it. Signed-off-by: Matt Porter mporter at kernel.crashing.org Index: arch/ppc/Kconfig === --- b4a27e4c90f11413fa6828321141c43cb9ad6c12/arch/ppc/Kconfig (mode:100644) +++ 711ec47634f5d5ded866eaa965a0f7dadcbc65f4/arch/ppc/Kconfig (mode:100644) @@ -1177,6 +1177,14 @@ source drivers/pcmcia/Kconfig +config RAPIDIO + bool RapidIO support if MPC8540 || MPC8560 + help + If you say Y here, the kernel will include drivers and + infrastructure code to support RapidIO interconnect devices. + +source drivers/rio/Kconfig + endmenu menu Advanced setup Index: arch/ppc/configs/stx_gp3_defconfig === --- b4a27e4c90f11413fa6828321141c43cb9ad6c12/arch/ppc/configs/stx_gp3_defconfig (mode:100644) +++ 711ec47634f5d5ded866eaa965a0f7dadcbc65f4/arch/ppc/configs/stx_gp3_defconfig (mode:100644) @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.11-rc2 -# Wed Jan 26 14:32:58 2005 +# Linux kernel version: 2.6.12-rc4 +# Tue May 24 18:11:04 2005 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y @@ -11,6 +11,7 @@ CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # # Code maturity level options @@ -18,6 +19,7 @@ CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup @@ -29,7 +31,6 @@ # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set -CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set @@ -37,6 +38,9 @@ CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set @@ -46,6 +50,7 @@ CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 # # Loadable module support @@ -69,9 +74,11 @@ CONFIG_E500=y CONFIG_BOOKE=y CONFIG_FSL_BOOKE=y +# CONFIG_PHYS_64BIT is not set # CONFIG_SPE is not set CONFIG_MATH_EMULATION=y # CONFIG_CPU_FREQ is not set +# CONFIG_PM is not set CONFIG_85xx=y CONFIG_PPC_INDIRECT_PCI_BE=y @@ -96,6 +103,7 @@ CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_CMDLINE_BOOL is not set +CONFIG_ISA_DMA_API=y # # Bus options @@ -104,15 +112,15 @@ CONFIG_PCI_DOMAINS=y # CONFIG_PCI_LEGACY_PROC is not set # CONFIG_PCI_NAMES is not set +# CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set - -# -# PC-card bridges -# +CONFIG_RAPIDIO=y +CONFIG_RAPIDIO_8_BIT_TRANSPORT=y +CONFIG_RAPIDIO_DISC_TIMEOUT=30 # # Advanced setup @@ -152,7 +160,7 @@ CONFIG_PARPORT_PC=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set -# CONFIG_PARPORT_OTHER is not set +# CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_1284 is not set # @@ -264,7 +272,6 @@ # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set -# CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set @@ -274,7 +281,6 @@ # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set -# CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=m @@ -283,6 +289,7 @@ # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set +# CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set @@ -322,7 +329,6 @@ # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set -# CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y @@ -431,7 +437,7 @@ # # Network testing # -# CONFIG_NET_PKTGEN is not set +CONFIG_NET_PKTGEN=y # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set @@ -499,6 +505,7 @@ # Wan interfaces # # CONFIG_WAN is not set +CONFIG_RIONET=y # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set @@ -536,20 +543,6 @@ # CONFIG_INPUT_EVBUG is not set # -# Input I/O drivers -# -# CONFIG_GAMEPORT is not set -CONFIG_SOUND_GAMEPORT=y -CONFIG_SERIO=y -CONFIG_SERIO_I8042=y -CONFIG_SERIO_SERPORT=y -# CONFIG_SERIO_CT82C710 is not set -# CONFIG_SERIO_PARKBD is not set -# CONFIG_SERIO_PCIPS2 is not set -CONFIG_SERIO_LIBPS2=y -# CONFIG_SERIO_RAW is not set - -# # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y @@ -567,6 +560,19 @@ # CONFIG_INPUT_MISC is not set # +# Hardware I/O ports +# +CONFIG_SERIO=y +CONFIG_SERIO_I8042=y +CONFIG_SERIO_SERPORT=y
[PATCH][5/5] RapidIO support: net driver over messaging
Adds an Ethernet driver which sends Ethernet packets over the
standard RapidIO messaging. This depends on the core RIO
patch for mailbox/doorbell access.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
Index: drivers/net/Kconfig
===
--- 711ec47634f5d5ded866eaa965a0f7dadcbc65f4/drivers/net/Kconfig (mode:100644)
+++ 8bdd37ff79724c95795ed39c28588a94e1f13e60/drivers/net/Kconfig (mode:100644)
@@ -2185,6 +2185,20 @@
tristate iSeries Virtual Ethernet driver support
depends on NETDEVICES PPC_ISERIES
+config RIONET
+ tristate RapidIO Ethernet over messaging driver support
+ depends on NETDEVICES RAPIDIO
+
+config RIONET_TX_SIZE
+ int Number of outbound queue entries
+ depends on RIONET
+ default 128
+
+config RIONET_RX_SIZE
+ int Number of inbound queue entries
+ depends on RIONET
+ default 128
+
config FDDI
bool FDDI driver support
depends on NETDEVICES (PCI || EISA)
Index: drivers/net/Makefile
===
--- 711ec47634f5d5ded866eaa965a0f7dadcbc65f4/drivers/net/Makefile (mode:100644)
+++ 8bdd37ff79724c95795ed39c28588a94e1f13e60/drivers/net/Makefile (mode:100644)
@@ -58,6 +58,7 @@
obj-$(CONFIG_VIA_RHINE) += via-rhine.o
obj-$(CONFIG_VIA_VELOCITY) += via-velocity.o
obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o
+obj-$(CONFIG_RIONET) += rionet.o
#
# end link order section
Index: drivers/net/rionet.c
===
--- /dev/null (tree:711ec47634f5d5ded866eaa965a0f7dadcbc65f4)
+++ 8bdd37ff79724c95795ed39c28588a94e1f13e60/drivers/net/rionet.c (mode:100644)
@@ -0,0 +1,622 @@
+/*
+ * rionet - Ethernet driver over RapidIO messaging services
+ *
+ * Copyright 2005 MontaVista Software, Inc.
+ * Matt Porter mporter at kernel.crashing.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/dma-mapping.h
+#include linux/delay.h
+#include linux/rio.h
+#include linux/rio_drv.h
+#include linux/rio_ids.h
+
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/skbuff.h
+#include linux/crc32.h
+#include linux/ethtool.h
+
+#define DRV_NAMErionet
+#define DRV_VERSION 0.1
+#define DRV_AUTHOR Matt Porter mporter at kernel.crashing.org
+#define DRV_DESCEthernet over RapidIO
+
+MODULE_AUTHOR(DRV_AUTHOR);
+MODULE_DESCRIPTION(DRV_DESC);
+MODULE_LICENSE(GPL);
+
+#define RIONET_DEFAULT_MSGLEVEL0
+#define RIONET_DOORBELL_JOIN 0x1000
+#define RIONET_DOORBELL_LEAVE 0x1001
+
+#define RIONET_MAILBOX 0
+
+#define RIONET_TX_RING_SIZECONFIG_RIONET_TX_SIZE
+#define RIONET_RX_RING_SIZECONFIG_RIONET_RX_SIZE
+
+LIST_HEAD(rionet_peers);
+
+struct rionet_private {
+ struct rio_mport *mport;
+ struct sk_buff *rx_skb[RIONET_RX_RING_SIZE];
+ struct sk_buff *tx_skb[RIONET_TX_RING_SIZE];
+ struct net_device_stats stats;
+ int rx_slot;
+ int tx_slot;
+ int tx_cnt;
+ int ack_slot;
+ spinlock_t lock;
+ u32 msg_enable;
+};
+
+struct rionet_peer {
+ struct list_head node;
+ struct rio_dev *rdev;
+ struct resource *res;
+};
+
+static int rionet_check = 0;
+static int rionet_capable = 1;
+static struct net_device *sndev = NULL;
+
+/*
+ * This is a fast lookup table for for translating TX
+ * Ethernet packets into a destination RIO device. It
+ * could be made into a hash table to save memory depending
+ * on system trade-offs.
+ */
+static struct rio_dev *rionet_active[RIO_MAX_ROUTE_ENTRIES];
+
+#define is_rionet_capable(pef, src_ops, dst_ops) \
+ ((pef RIO_PEF_INB_MBOX) \
+(pef RIO_PEF_INB_DOORBELL) \
+(src_ops RIO_SRC_OPS_DOORBELL) \
+(dst_ops RIO_DST_OPS_DOORBELL))
+#define dev_rionet_capable(dev) \
+ is_rionet_capable(dev-pef, dev-src_ops, dev-dst_ops)
+
+#define RIONET_MAC_MATCH(x)(*(u32 *)x == 0x00010001)
+#define RIONET_GET_DESTID(x) (*(u16 *)(x + 4))
+
+static struct net_device_stats *rionet_stats(struct net_device *ndev)
+{
+ struct rionet_private *rnet = ndev-priv;
+ return rnet-stats;
+}
+
+static int rionet_rx_clean(struct net_device *ndev)
+{
+ int i;
+ int error = 0;
+ struct rionet_private *rnet = ndev-priv;
+ void *data;
+
+ i = rnet-rx_slot;
+
+ do {
+ if (!rnet-rx_skb[i]) {
+ rnet-stats.rx_dropped++;
+ continue;
+ }
+
+ if (!(data = rio_get_inb_message(rnet-mport
Getting ownership for various boards/platforms configs
On Thu, Jun 02, 2005 at 06:19:11PM -0500, Kumar Gala wrote: One issue that comes up from time to time is knowing who to contact about some of the various boards that are supported for PPC. I've suggested in the past that we create a MAINTAINERS file in arch/ppc/platforms. I've started with a list of all the _defconfigs that we have and would like to see if we can get contacts for the boards. All this list is meant to be is a contact point. The following is the list, I'll keep a live copy at http://gate.crashing.org/~galak/platform-owners. Once it gets flushed out I'll turn it into file that looks more like the toplevel MAINTAINERS file. If we dont have any owners for a board we can discuss if support for it should be removed. Please email me if you feel you are the owner of any board/config. thanks - kumar ash beech These are't in 2.6, remove the defconfig bubinga me/ebs cedar This isn't in 2.6, remove the defconfig ebony me/ebs k2 I did the original port, now unmaintained/obsolete..die die die. lopec trini is probably the maintainer here...he likes this board. luan me menf1 Dead (Matt Porter) Remove it, yes. oak I think it's time to remove it...unmaintained. ocotea me/ebs rainier Not in 2.6...remove defconfig redwood5 redwood6 um...dfarnsworth, want them formally? redwood Not in 2.6...remove defconfig stx_gp3 me sycamore me walnut me
[PATCH] cpm_uart: Route SCC2 pins for the STx GP3 board
On Thu, Jun 02, 2005 at 03:35:40PM -0700, Andrew Morton wrote:
Matt Porter mporter at kernel.crashing.org wrote:
+++ uncommitted/drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644)
@@ -134,12 +134,21 @@
void scc2_lineif(struct uart_cpm_port *pinfo)
{
+ /*
+* STx GP3 uses the SCC2 secondary option pin assignment
+* which this driver doesn't account for in the static
+* pin assignments. This kind of board specific info
+* really has to get out of the driver so boards can
+* be supported in a sane fashion.
+*/
+#ifndef CONFIG_STX_GP3
volatile iop_cpm2_t *io = cpm2_immr-im_ioport;
io-iop_pparb |= 0x008b;
Silly question: why is this driver using a volatile pointer to
memory-mapped I/O rather than readl and writel?
readl/writel just won't work. They are byte swapped on PPC since
they are specifically for PCI access. In other on-chip drivers
for PPC32, we typically ioremap() to a non-volatile type and then
use out_be32()/in_be32() since everything except PCI on PPC is
in right-endian (big endian) form. out_be*()/in_be*() contain
an eieio instruction to guarantee proper ordering.
I know this driver was recently rewritten but the authors may have
missed the past threads about why volatile use is discouraged. We
do something similar with register overlay structures in
drivers/net/ibm_emac. However, we don't use a volatile type and do
use PPC32-specific (these are PPC-specific drivers anyway)
out_be32()/in_be32() for correctness.
-Matt
[PATCH] cpm_uart: Route SCC2 pins for the STx GP3 board
Adds SCC2 pin routing specific to the GP3 board.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
Signed-off-by: Kumar Gala kumar.gala at freescale.com
Index: drivers/serial/cpm_uart/cpm_uart_cpm2.c
===
---
b4bedd69e60ae8cc7d89f3c97c617a444eb43292/drivers/serial/cpm_uart/cpm_uart_cpm2.c
(mode:100644)
+++ uncommitted/drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644)
@@ -134,12 +134,21 @@
void scc2_lineif(struct uart_cpm_port *pinfo)
{
+ /*
+* STx GP3 uses the SCC2 secondary option pin assignment
+* which this driver doesn't account for in the static
+* pin assignments. This kind of board specific info
+* really has to get out of the driver so boards can
+* be supported in a sane fashion.
+*/
+#ifndef CONFIG_STX_GP3
volatile iop_cpm2_t *io = cpm2_immr-im_ioport;
io-iop_pparb |= 0x008b;
io-iop_pdirb |= 0x0088;
io-iop_psorb |= 0x0088;
io-iop_pdirb = ~0x0003;
io-iop_psorb = ~0x0003;
+#endif
cpm2_immr-im_cpmux.cmx_scr = 0xff00;
cpm2_immr-im_cpmux.cmx_scr |= 0x0009;
pinfo-brg = 2;
[PATCH][1/3] RapidIO support: core
Adds a RapidIO subsystem to the kernel. RIO is a switched fabric interconnect used in higher-end embedded applications. The curious can look at the specs over at http://www.rapidio.org The core code implements enumeration/discovery, management of devices/resources, and interfaces for RIO drivers. There's a lot more to do to take advantages of all the hardware features. However, this should provide a good base for folks with RIO hardware to start contributing. Signed-off-by: Matt Porter mporter at kernel.crashing.org Patch is 108KB and can be found here: ftp://source.mvista.com/pub/rio/l26_rio_core.patch -Matt
