* Linux MPC8280 patch
From: Srivatsan @ 2004-12-13 4:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20041213010004.457862BF24@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
Dear all,
1) I am trying to bring up a Rattler board by using MPC8260ADS
kernel. From what I am seeing from all my trials MPC8260ADS kernel is
not bringing up the MPC8280 based board.
2) Is there any patch to be added to the MPC8260 based kernel to
bring up the MPC8280 based board? If so, May I know the name of the
patch?
Expecting all your help.
With Best Regards,
C.R.Srivatsan
********************************DISCLAIMER**********************************
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.
****************************************************************************
^ permalink raw reply
* Re: video card for Lite5200
From: Mark Jonas @ 2004-12-12 17:17 UTC (permalink / raw)
To: wangwenbin; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <20041210015932.A3B692BDA0@ozlabs.org>
Hello Tony,
> I have successfully boot Linux 2.4.22 on my Lite5200 Evaluation Board with the ELDK. but when I want to use PCI slot for the video card,something goes wrong. The whole board loses supply of electricity. And i take the video card out ,the board is still ok. So i change to put RTL81390 network card into PCI slot. The same thing happen.
> The video card i have tried :
> S3 Trio64V
> Trident TGUI9680
> S3 ViRGE/DX
>
>
According to my experience with the Lite5200 board there are three
things that might have gone wrong in your experiments:
1.) You plugged in a 5V-only card. Make sure your card 3.3V compliant.
Check that by looking at the data sheet _and_ by looking a the PCI
card's edge connector. The coding gap must be in to the front of the card.
2.) You plugged in a card which claims to be 3.3V PCI compliant card but
is not. Even if the coding gap marks it as 3.3V compliant I've seen
cards before that aren't. They usually make a short between V I/O and +5
VDC which results in what you can see: The power supply goes into
protection.
3.) You placed the PCI card into the PCI slot turned by 180 degrees.
That also usually results in a short and the power supply goes into
protection. Please consult the Lite5200's user manual and make sure you
plug in the card the right way.
If had to make a bet what your problem is I would put my money on 3. I
think so because RTL8139 cards are usually 3.3V compliant. Additionally,
the graphics cards you mentioned are usually not 3.3V compliant but if
you turn them by 180 degrees their coding gap will fit.
Regards
Mark
^ permalink raw reply
* [2.6 patch] (mostly i386) mm cleanup
From: Adrian Bunk @ 2004-12-12 2:10 UTC (permalink / raw)
To: Dave Hansen, linux-kernel, paulus, linuxppc-dev, jdike,
user-mode-linux-devel, dhowells
The patch below contains the following fixes:
- arch/i386/mm/boot_ioremap.c: make a variable static:
- frv/ppc highmem.c: remove stale kmap_init prototypes
- arch/um/kernel/mem.c: make kmap_init static
- arch/i386/mm/init.c: make five functions static.
diffstat output:
arch/i386/mm/boot_ioremap.c | 4 ++--
arch/i386/mm/init.c | 10 +++++-----
arch/um/kernel/mem.c | 2 +-
include/asm-frv/highmem.h | 2 --
include/asm-i386/highmem.h | 2 --
include/asm-ppc/highmem.h | 2 --
6 files changed, 8 insertions(+), 14 deletions(-)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.10-rc2-mm4-full/arch/i386/mm/boot_ioremap.c.old 2004-12-11 23:55:28.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/arch/i386/mm/boot_ioremap.c 2004-12-11 23:55:49.000000000 +0100
@@ -61,8 +61,8 @@
/* the virtual space we're going to remap comes from this array */
#define BOOT_IOREMAP_PAGES 4
#define BOOT_IOREMAP_SIZE (BOOT_IOREMAP_PAGES*PAGE_SIZE)
-__initdata char boot_ioremap_space[BOOT_IOREMAP_SIZE]
- __attribute__ ((aligned (PAGE_SIZE)));
+static __initdata char boot_ioremap_space[BOOT_IOREMAP_SIZE]
+ __attribute__ ((aligned (PAGE_SIZE)));
/*
* This only applies to things which need to ioremap before paging_init()
--- linux-2.6.10-rc2-mm4-full/include/asm-frv/highmem.h.old 2004-12-11 23:57:40.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/include/asm-frv/highmem.h 2004-12-11 23:57:51.000000000 +0100
@@ -44,8 +44,6 @@
#define kmap_pte ______kmap_pte_in_TLB
extern pte_t *pkmap_page_table;
-extern void kmap_init(void);
-
#define flush_cache_kmaps() do { } while (0)
/*
--- linux-2.6.10-rc2-mm4-full/include/asm-ppc/highmem.h.old 2004-12-11 23:58:00.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/include/asm-ppc/highmem.h 2004-12-11 23:58:03.000000000 +0100
@@ -35,8 +35,6 @@
extern pgprot_t kmap_prot;
extern pte_t *pkmap_page_table;
-extern void kmap_init(void) __init;
-
/*
* Right now we initialize only a single pte table. It can be extended
* easily, subsequent pte tables have to be allocated in one physical
--- linux-2.6.10-rc2-mm4-full/arch/um/kernel/mem.c.old 2004-12-11 23:58:14.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/arch/um/kernel/mem.c 2004-12-11 23:58:21.000000000 +0100
@@ -141,7 +141,7 @@
pte_offset_kernel(pmd_offset(pml4_pgd_offset(pml4_offset_k(vaddr), \
vaddr), (vaddr)), (vaddr))
-void __init kmap_init(void)
+static void __init kmap_init(void)
{
unsigned long kmap_vstart;
--- linux-2.6.10-rc2-mm4-full/include/asm-i386/highmem.h.old 2004-12-11 23:58:54.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/include/asm-i386/highmem.h 2004-12-11 23:58:57.000000000 +0100
@@ -33,8 +33,6 @@
extern pgprot_t kmap_prot;
extern pte_t *pkmap_page_table;
-extern void kmap_init(void);
-
/*
* Right now we initialize only a single pte table. It can be extended
* easily, subsequent pte tables have to be allocated in one physical
--- linux-2.6.10-rc2-mm4-full/arch/i386/mm/init.c.old 2004-12-11 23:58:29.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/arch/i386/mm/init.c 2004-12-12 00:15:07.000000000 +0100
@@ -254,7 +254,7 @@
#define kmap_get_fixmap_pte(vaddr) \
pte_offset_kernel(pmd_offset(pml4_pgd_offset(pml4_offset_k(vaddr), vaddr), (vaddr)), (vaddr))
-void __init kmap_init(void)
+static void __init kmap_init(void)
{
unsigned long kmap_vstart;
@@ -265,7 +265,7 @@
kmap_prot = PAGE_KERNEL;
}
-void __init permanent_kmaps_init(pgd_t *pgd_base)
+static void __init permanent_kmaps_init(pgd_t *pgd_base)
{
pgd_t *pgd;
pmd_t *pmd;
@@ -294,7 +294,7 @@
}
#ifndef CONFIG_DISCONTIGMEM
-void __init set_highmem_pages_init(int bad_ppro)
+static void __init set_highmem_pages_init(int bad_ppro)
{
int pfn;
for (pfn = highstart_pfn; pfn < highend_pfn; pfn++)
@@ -408,7 +408,7 @@
}
#ifndef CONFIG_DISCONTIGMEM
-void __init zone_sizes_init(void)
+static void __init zone_sizes_init(void)
{
unsigned long zones_size[MAX_NR_ZONES] = {0, 0, 0};
unsigned int max_dma, high, low;
@@ -545,7 +545,7 @@
* but fortunately the switch to using exceptions got rid of all that.
*/
-void __init test_wp_bit(void)
+static void __init test_wp_bit(void)
{
printk("Checking if this processor honours the WP bit even in supervisor mode... ");
^ permalink raw reply
* [PATCH] drivers/ide/ppc/mpc8xx.c - volatile fix
From: Magnus Damm @ 2004-12-11 14:48 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
Hello,
I fixed this in a local tree for a customer half a year ago (mvl-3.1)
and forgot to report it to the lists. Now I came across it in vanilla
2.5.10-rc3. I have not tested the fix but it is pretty obvious that
access with a non-volatile pointer to hardware is bad, at least with
gcc-3 or above.
Please apply. Or ignore if already fixed. =)
Thanks.
/ magnus (needs CC)
[-- Attachment #2: linux-2.6.9-mpc8xx-volatile.patch --]
[-- Type: application/octet-stream, Size: 377 bytes --]
--- linux-2.6.9/drivers/ide/ppc/mpc8xx.c 2004-12-11 13:05:09.000000000 +0100
+++ linux-2.6.9-mpc8xx-volatile/drivers/ide/ppc/mpc8xx.c 2004-12-11 15:49:16.000000000 +0100
@@ -172,7 +172,7 @@
volatile pcmcia_win_t *win;
volatile pcmconf8xx_t *pcmp;
- uint *pgcrx;
+ volatile uint *pgcrx;
u32 pcmcia_phy_base;
u32 pcmcia_phy_end;
static unsigned long pcmcia_base = 0;
^ permalink raw reply
* Re: Write Combining on PowerPC
From: Randy Vinson @ 2004-12-10 23:21 UTC (permalink / raw)
To: Kendall Bennett; +Cc: linuxppc-embedded
In-Reply-To: <41B9A33A.21673.5DDD7F64@localhost>
Kendall Bennett wrote:
[snip]
> Does anyone know if it is possible to do something similar to Write
> Combining for the PowerPC architecture, to speed up CPU access to the
> linear framebuffer?
Yes, it is possible. First you will need to enable Store Gathering for
the Sandpoint's MPC107 bridge. (Go to Platform options->Enable MPC10x
store gathering). You will then need to set the page protections for the
video memory such that _PAGE_GUARDED is removed. The hardware will not
store gather to an area mapped guarded. There appears to be some code to
support this in the PCI MMap routines, but I'm not familiar with the
details.
Randy Vinson
^ permalink raw reply
* Write Combining on PowerPC
From: Kendall Bennett @ 2004-12-10 21:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi Guys,
We are working on some PowerPC machines and noticed that the boxes don't
appear to support the equivalent of Write Combining that we get on x86
boxes. Copies to Video Memory on our Motorola Sandpoint box run about
10Mb/s, which is terribly, terribly slow!
Does anyone know if it is possible to do something similar to Write
Combining for the PowerPC architecture, to speed up CPU access to the
linear framebuffer? Part of the problem is that for video overlay support
(not motion compensation) you have to dump the entire YUV frame into
video memory for the hardware overlay, and even on a 1GHz PPC box playing
an MPEG2 stream is not possible as X takes up over 80% of the CPU just to
copy the YUV data to video memory!
Obviously bus mastering will help solve this problem, but it would be
better if there was a way to enabling faster CPU access to the
framebuffer as well.
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
^ permalink raw reply
* Write Combining for PowerPC?
From: Kendall Bennett @ 2004-12-10 21:23 UTC (permalink / raw)
To: linuxppc-dev
Hi Guys,
We are working on some PowerPC machines and noticed that the boxes don't
appear to support the equivalent of Write Combining that we get on x86
boxes. Copies to Video Memory on our Motorola Sandpoint box run about
10Mb/s, which is terribly, terribly slow!
Does anyone know if it is possible to do something similar to Write
Combining for the PowerPC architecture, to speed up CPU access to the
linear framebuffer? Part of the problem is that for video overlay support
(not motion compensation) you have to dump the entire YUV frame into
video memory for the hardware overlay, and even on a 1GHz PPC box playing
an MPEG2 stream is not possible as X takes up over 80% of the CPU just to
copy the YUV data to video memory!
Obviously bus mastering will help solve this problem, but it would be
better if there was a way to enabling faster CPU access to the
framebuffer as well.
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
^ permalink raw reply
* Re: PPC4XX DMA polarity bug in linuxppc-2.6.9
From: Stephen Williams @ 2004-12-10 17:22 UTC (permalink / raw)
To: Matt Porter; +Cc: Colin Wernham, linuxppc-embedded
In-Reply-To: <20041210100958.C31319@home.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matt Porter wrote:
| On Fri, Dec 10, 2004 at 09:09:39AM -0000, Colin Wernham wrote:
|>Is there anyone else using the PPC4XX DMA?
|
|
| Yes, I've used this library code for simple memory<->memory DMA
| tests to verify that programmed and SG mode work. For more common
| setups like peripheral driven DMA from the EBC, I've simply programmed
| the DMA engine directly. This library doesn't seem to simplify anything
| for me in those cases (it's just a thin wrapper around registers) so
| I find it easier to program the DMA engine regs directly within the
| driver that is making use of a channel. I've been keeping it around
| since apparently a lot of people make use of it in hopes that
| somebody might take the time to improve it.
I found the library as thin and undocumented, and didn't seem to
actually solve any problems. Certainly not mine. So I wrote my
own.
I haven't isolated it into its own module yet, as I got to the point
where it's working for my client driver, and didn't submit it as
there is some driver for some oddball hardware that seems to use
the existing library, and this would clash.
Here's the header file for my functions, in case this piques any
interest.
/*
~ * Copyright (c) 2004 Picture Elements, Inc.
~ * Stephen Williams (steve@icarus.com)
~ *
~ * This source code is free software; you can redistribute it
~ * and/or modify it in source code form 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.
~ *
~ * 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.
~ *
~ * 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
~ */
#ident "$Id: jsedma.h,v 1.3 2004/08/09 19:04:07 steve Exp $"
# include <linux/module.h>
# include <linux/kernel.h>
# include <asm/uaccess.h>
/*
~ * This module provides a reuseable interface to IBM PPC405GP(r) DMA
~ * controllers. It allows clients to request a suitable controller, to
~ * set up an operation, and see the transaction through. The general
~ * order of events is to:
~ *
~ * map your user data with the map_user_kiobuf function.
~ *
~ * Use jsedma_chain_from_kiobuf to turn that map into a string of DMA
~ * chain cells.
~ *
~ * Select a DMA controller to use with jsedma_alloc_controller().
~ *
~ * Start the operation with jsedma_start_chain(...)
~ *
~ * Wait for it to finish with jsedma_wait_interruptible(...)
~ *
~ * Then release everything when done.
~ */
/*
~ * Allocate an available DMA controller that has been set up for
~ * memory-to-memory transfers. There may be as many as 4 of
~ * these. The return value is >= 0 if a controller is allocated, or <0
~ * on error.
~ *
~ * When done, release the controller.
~ */
extern int jsedma_alloc_controller(void);
extern void jsedma_free_controller(int dmanr);
/*
~ * Allocate a DMA chain based on the mapped kiobuf. Free the chain
~ * when the DMA in use is completed. This may allocate consistent
~ * pages, so be careful where you use it. Free the chain when you are
~ * done with it.
~ *
~ * The direction is either PCI_DMA_TODEVICE or PCI_DMA_FROMDEVICE.
~ *
~ * WARNING: Just like with pci_map_single, the memory of the iobuf
~ * should not be touched between the creation of this chain and the
~ * completion of the transfer. This function flushes caches (if
~ * needed) so if you touch buffers during the transfer, data can be
~ * lost.
~ *
~ * The jsedma_chain is an opaque type.
~ */
extern struct jsedma_chain* jsedma_chain_from_kiobuf(phys_addr_t dest,
struct kiobuf*iobuf,
int direction);
extern void jsedma_chain_free(struct jsedma_chain*chp);
/*
~ * Start a DMA of the chain on the specified DMA controller. The
~ * controller should be allocated, and the target address mapped.
~ */
extern int jsedma_start_chain(int dmanr, struct jsedma_chain*chn);
/*
~ * Wait for the channel to be done. When it is done, this function
~ * returns 0. If there is an error, or the wait is interrupted, return
~ * an error code <0.
~ */
extern int jsedma_wait_interruptible(int dmanr);
/*
~ * $Log: jsedma.h,v $
~ * Revision 1.3 2004/08/09 19:04:07 steve
~ * Use DMA controller to read from frame memory.
~ *
~ * Revision 1.2 2004/05/05 17:39:51 steve
~ * Make sure caching does not get in the way of transfer.
~ *
~ * Revision 1.1 2004/04/17 02:20:42 steve
~ * Make frame output use PPC DMA controllers.
~ *
~ */
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBudtprPt1Sc2b3ikRAn2VAJ9zFcfBN5/lBgs/iV++OwQuSwuFGQCgp9CC
c+1dmQF0GoZcuslUCPn23oU=
=cUut
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: PPC4XX DMA polarity bug in linuxppc-2.6.9
From: Matt Porter @ 2004-12-10 17:09 UTC (permalink / raw)
To: Colin Wernham; +Cc: linuxppc-embedded
In-Reply-To: <3506EDCDEC47904CBE6FD2E1DEEA89840205BCAA@fs5.airspan.com>
On Fri, Dec 10, 2004 at 09:09:39AM -0000, Colin Wernham wrote:
> I believe that there is a PPC4xx DMA driver bug in the following kernel,
<snip>
> Cause is (I believe):
> /arch/ppc/syslib/ppc4xx_dma.c:
> On line 469 the old polarity bits in p_dma_ch are ORed in when it should
> be ORing in the new polarity bits from p_init. p_init is then saved into
> p_dma_ch. This means that it only gets correctly programmed when the
> function is called twice:
>
> 467 /* clear all polarity signals and then "or" in new signal levels */
> 468 polarity &= ~GET_DMA_POLARITY(dmanr);
> 469 polarity |= p_dma_ch->polarity;
>
> Fix should be:
> 469 polarity |= p_init->polarity;
Yes, that's a real bug. Can you make a patch according to
Documentation/SubmittingPatches, add your signed off line, and
send to me or this list? This clear bug fix should go in
before 2.6.10.
> Is there anyone else using the PPC4XX DMA?
Yes, I've used this library code for simple memory<->memory DMA
tests to verify that programmed and SG mode work. For more common
setups like peripheral driven DMA from the EBC, I've simply programmed
the DMA engine directly. This library doesn't seem to simplify anything
for me in those cases (it's just a thin wrapper around registers) so
I find it easier to program the DMA engine regs directly within the
driver that is making use of a channel. I've been keeping it around
since apparently a lot of people make use of it in hopes that
somebody might take the time to improve it.
Since the my apps that would exercise the polarity bits in the
init code don't use this library, I guess that's why I've never
run into this problem. :)
-Matt
^ permalink raw reply
* [PATCH][EMAC] fix ibm_emac autonegotiation result parsing
From: Matt Porter @ 2004-12-10 16:51 UTC (permalink / raw)
To: jgarzik, akpm; +Cc: linuxppc-embedded
Fix aneg result parsing in ibm_emac driver.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
===== drivers/net/ibm_emac/ibm_emac_phy.c 1.1 vs edited =====
--- 1.1/drivers/net/ibm_emac/ibm_emac_phy.c 2004-05-22 10:13:08 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_phy.c 2004-11-24 15:23:54 -08:00
@@ -191,17 +191,18 @@
u16 lpa;
if (phy->autoneg) {
- lpa = phy_read(phy, MII_LPA);
+ lpa = phy_read(phy, MII_LPA) & phy_read(phy, MII_ADVERTISE);
- if (lpa & (LPA_10FULL | LPA_100FULL))
- phy->duplex = DUPLEX_FULL;
- else
- phy->duplex = DUPLEX_HALF;
- if (lpa & (LPA_100FULL | LPA_100HALF))
- phy->speed = SPEED_100;
- else
- phy->speed = SPEED_10;
+ phy->speed = SPEED_10;
+ phy->duplex = DUPLEX_HALF;
phy->pause = 0;
+
+ if (lpa & (LPA_100FULL | LPA_100HALF)) {
+ phy->speed = SPEED_100;
+ if (lpa & LPA_100FULL)
+ phy->duplex = DUPLEX_FULL;
+ } else if (lpa & LPA_10FULL)
+ phy->duplex = DUPLEX_FULL;
}
/* On non-aneg, we assume what we put in BMCR is the speed,
* though magic-aneg shouldn't prevent this case from occurring
^ permalink raw reply
* AW: video card for Lite5200
From: Martin Krause @ 2004-12-10 15:45 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
Hi Clemens,
Clemens Koller wrotes on Freitag, 10. Dezember 2004 16:11:
> > From the silicon motion homepage you could get a framebuffer driver
> > for the SM501 PCI card. This should work without great
> > modifications for PPC systems.
>=20
> Thank you, I know that thing. I started with that driver, but I did
> quite a lot of code cleanup (I guess there are lots of leftovers from
> the SM7xx parts). I am about to put this into a loadable
> kernel module fbdev driver.
> Later on, we might need some power management, use it on
> different resolutions and use the other on-chip peripherals...
Oh, sounds interesting. We took the driver from SMI and hacked it
to run on our board. Three different resolutions are possible:
640x480, 800x600 and 1024x768. We use "fbset" to change it.
But with the higher two resolutions, the picture is very noise.=20
I think this is because of two high SM501 internal memory clocks.
Unforunately the datasheet of the grafic controler is very spare -
not to say poor. So I yet couldn't figure out, at wich speed the
memory clock is running actually and how to change it.
> Do you use any of the other peripherals of the SM501, too? (USB,
> Audio, 8051)=20
No, actually not.
Regards,
Martin
^ permalink raw reply
* Re: AW: video card for Lite5200
From: Clemens Koller @ 2004-12-10 15:11 UTC (permalink / raw)
To: Martin Krause, linuxppc-embedded
In-Reply-To: <DE2CC66C40EAB74EA6D66AC71BF98E1E016AF54E@TQ-MAILSRV-1>
Hi, Martin!
> From the silicon motion homepage you could get a framebuffer driver for
> the SM501 PCI card. This should work without great modifications for
> PPC systems.
Thank you, I know that thing. I started with that driver, but I did
quite a lot of code cleanup (I guess there are lots of leftovers from
the SM7xx parts). I am about to put this into a loadable kernel module
fbdev driver. Later on, we might need some power management, use it on
different resolutions and use the other on-chip peripherals...
> On our board (with MPC5200 CPU), we connected the SM501 not over PCI,
> but over the local bus. You could find the driver in the
> linuxppc_2_4_devel Kernel from the Denx CVS server. Look at: http://www.denx.de/e/index1.php?head=solution-se-head&main=solution-se&subnav=solution-se-subnav&logo=logo-se&mainnav=softwarenav&bottom=bottom-se
I'll have a look at that one, too. Thanks...
Do you use any of the other peripherals of the SM501, too?
(USB, Audio, 8051)
Best greets,
Clemens Koller
^ permalink raw reply
* AW: video card for Lite5200
From: Martin Krause @ 2004-12-10 13:48 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
SGkgQ2xlbWVucywNCg0KQ2xlbWVucyBLb2xsZXIgd3JvdGVzIG9uIEZyZWl0YWcsIDEwLiBEZXpl
bWJlciAyMDA0IDExOjM1Og0KPiBJIHVzZSBhIFNpbGljb24gTW90aW9uIEluYy4gU001MDEgVm95
YWdlciBHWCBQQ0kgRGVtbyBCb2FyZCByaWdodCBub3cNCj4gd2hpY2ggaXMgc3VwcG9zZWQgdG8g
d29yayB3aXRoIGFsbCB0aGUgZW1iZWRkZWQgc3lzdGVtcy4gWW91IGNhbiBnZXQNCj4gdGhhdCBi
b2FyZCBmb3IgYWJvdXQgRVVSIDQ5NS4tIGluIEdlcm1hbnkuDQo+IEkgYW0gY3VycmVudGx5IHdv
cmtpbmcgb24gdGhlIGZyYW1lYnVmZmVyIGRyaXZlcnMgZm9yIHRoZSBWb3lhZ2VyIG9uDQo+IFBQ
Qy4gVGhpbmdzIHNlZW0gdG8gbWFrZSBnb29kIHByb2dyZXNzLCBoZXJlICh0aGVyZSBpcyBhbiBp
bWFnZSBvbg0KPiBzY3JlZW4gOi0pLg0KDQpGcm9tIHRoZSBzaWxpY29uIG1vdGlvbiBob21lcGFn
ZSB5b3UgY291bGQgZ2V0IGEgZnJhbWVidWZmZXIgZHJpdmVyIGZvcg0KdGhlIFNNNTAxIFBDSSBj
YXJkLiBUaGlzIHNob3VsZCB3b3JrIHdpdGhvdXQgZ3JlYXQgbW9kaWZpY2F0aW9ucyBmb3INClBQ
QyBzeXN0ZW1zLg0KT24gb3VyIGJvYXJkICh3aXRoIE1QQzUyMDAgQ1BVKSwgd2UgY29ubmVjdGVk
IHRoZSBTTTUwMSBub3Qgb3ZlciBQQ0ksDQpidXQgb3ZlciB0aGUgbG9jYWwgYnVzLiBZb3UgY291
bGQgZmluZCB0aGUgZHJpdmVyIGluIHRoZSANCmxpbnV4cHBjXzJfNF9kZXZlbCBLZXJuZWwgZnJv
bSB0aGUgRGVueCBDVlMgc2VydmVyLiBMb29rIGF0OiBodHRwOi8vd3d3LmRlbnguZGUvZS9pbmRl
eDEucGhwP2hlYWQ9c29sdXRpb24tc2UtaGVhZCZtYWluPXNvbHV0aW9uLXNlJnN1Ym5hdj1zb2x1
dGlvbi1zZS1zdWJuYXYmbG9nbz1sb2dvLXNlJm1haW5uYXY9c29mdHdhcmVuYXYmYm90dG9tPWJv
dHRvbS1zZQ0KDQpSZWdhcmRzLA0KTWFydGluDQo=
^ permalink raw reply
* Re: video card for Lite5200
From: Clemens Koller @ 2004-12-10 10:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200412100845.14486.g.jaeger@sysgo.com>
Hello, Tony!
>> I have successfully boot Linux 2.4.22 on my Lite5200 Evaluation Boar=
d with the ELDK. but when I want to use PCI slot for the video card,somet=
hing goes wrong. The whole board loses supply of electricity. And i take =
the video card out ,the board is still ok. So i change to put RTL81390 ne=
twork card into PCI slot. The same thing happen.
>> The video card i have tried :
>> S3 Trio64V
>> Trident TGUI9680
>> S3 ViRGE/DX
Don't use old (5V only) cards, the S3 drivers might be unmaintained for=20
your platform, too. If you want to integrate video into your final
system, you might want to check out some embedded solutions.
>> Then I ask the Freescale support, they tell me that these board can =
operate in 5V slot only, While the PCI slot on Lite5200 only offers 3.3V.=
These days though I search much information about vedio card. I still do=
n't which card can fit Lite5200.And I knew that the new CoralP PCI video =
card can support Lite5200. Can I get it from market? Anyway I really worr=
y about this, so I turn here and ask your help.and I really appreciate yo=
ur help! thanks a lot! (There was something wrong with my mailbox,I could=
not receive the letters these days.So I post it again)=20
>> Best Regards, =20
>> Tony Wang
>>=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
stcwang@163.net
>=20
>=20
> first of all, you need to take care of the PCI cards you use. As the Fr=
eescale support and=20
> also the manuals say: "Only 3.3V compliant PCI cards". In the meantime =
there are quite a lot
> of burned-out boards because of "wrong" cards.
> Next problem with the PCI bus on this board is, that because of some ti=
ming issues not all=20
> cards will be detected, so it'll be hard to find a video card, that mat=
ches these requirements.
> The only card that I know, which seems to work AND is somehow supported=
is a CORAL-P evaluation=20
> board from Fujitsu. But this one is rather expensive.=20
> I tried also and old Nvidia Riva 128 card, which was detected correctly=
, but is not
> initialized correctly by the framebuffer driver.
>
> Regards,
> Gerhard
>
Yes, the Fujitsu Coral P should work also.
I use a Silicon Motion Inc. SM501 Voyager GX PCI Demo Board right now=20
which is supposed to work with all the embedded systems. You can get
that board for about EUR 495.- in Germany.
I am currently working on the framebuffer drivers for the Voyager on=20
PPC. Things seem to make good progress, here (there is an image on=20
screen :-). There is also an Epson or Asilient solution for embedded=20
systems, maybe you can check that also. YMMV
Best greets,
--=20
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* CFP: 3th EMBEDDED SYSTEMS and OPERATING SYSTEMS track at FOSDEM 2005
From: Geert Uytterhoeven @ 2004-12-10 9:38 UTC (permalink / raw)
To: linuxppc-embedded
At the start of next year FOSDEM, the most important Belgian Free
Software event will be back again. As on the previous occasions there
will also be an embedded track, for which we are looking for speakers.
All the necessary info can be found in the following call for papers.
Feel free to distribute, and tell other people about it.
3th EMBEDDED SYSTEMS and OPERATING SYSTEMS track at FOSDEM 2005
===============================================================
26 - 27 February 2005, Brussels
Call for papers
----------------
The 2005 edition of FOSDEM (Free and Open Source Developers' European
Meeting; http://www.fosdem.org) will take place in Brussels, Belgium
on 26 and 27 February 2005. For the third time, a track on Embedded
Systems and Operating Systems will be organized. The second edition
was quite succesful and attracted up to 150 attendants for certain
topics.
For last year's program see:
http://www.embedded-kernel-track.org/2004/papers.html
The use of Free Software in the infrastructure of embedded systems
is booming, e.g. by the use of Linux, uClinux, eCos, RedBoot, RTEMS
and many other Free Software components. More companies are supporting
embedded Free Software each day because of the reliability and cheap
licensing.
Operating system development has always been a very important topic in
Free Software.
As embedded and real-time systems typically have special OS requirements,
we organise this Free Embedded and OS development track at FOSDEM.
This track provides a remarkable opportunity to present and
discuss the ongoing work in these areas, and we invite developers to
present their current projects. Technical topics of the conference
include but are not limited to :
* OS Development : kernel architecture and implementation, libraries
(e.g. Linux, BSD, uClinux, uClibc, newlib, ...)
* Practical experiences in implementing Free Software in embedded systems
(e.g. reverse engineering, porting to (and adapting of) commercial devices
(iPAQ, Linksys WRT54G,...), ...)
* Toolchain and build environment
(e.g. crosstool, emdebian, openembedded, PTX dist, packaging, scratchbox,
Eclipse, Valgrind,...)
* GUIs for embedded systems
(Gtk, Qt-(embedded), GPE, Qtopia, UI design with touchscreen, ...)
* Multimedia applications for embedded systems
(e.g. integer-only decoders, Opieplayer, ... )
* Real-time extensions, nanokernels and hardware virtualization software
(e.g. RTAI, Adeos, KURT, L4, Qemu, Xen, User Mode Linux, ...)
* Hard real-time OS's
(eCos, RTEMS, ...)
* Open hardware and softcores
(e.g opencores.org, OpenRISC, LEON, FPGA's, specific design
restrictions for free systems...)
* Safety and security certifications applied to Free software
(e.g. security measures in Embedded systems, SSL libraries, ...)
* Free software licenses and embedded systems
Authors are requested to submit their abstracts online to
embedded@fosdem.org before january 3th 2005. Notification of receipt
will be sent within 48 hours. Authors wishing to submit a full
paper (between 6 and 12 A4 pages), can do so in PS or PDF format.
The program committee will evaluate the abstracts and consists of:
* Herman Bruyninckx, Professor at K.U.Leuven, Belgium
* Geert Uytterhoeven, Sony NSCE, Belgium
* Karim Yaghmour, Opersys, Canada
* Peter De Schrijver (p2), Mind, Belgium
* Russell King (RMK), ARM Linux Kernel Engineer, Deep Blue Solutions Ltd
See you at FOSDEM!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* PPC4XX DMA polarity bug in linuxppc-2.6.9
From: Colin Wernham @ 2004-12-10 9:09 UTC (permalink / raw)
To: linuxppc-embedded
[a copy of this has also been posted on linuxppc-dev]
I believe that there is a PPC4xx DMA driver bug in the following kernel, =
file and function:
linuxppc-2.6.9,
/arch/ppc/syslib/ppc4xx_dma.c,
ppc4xx_init_dma_channel()
Symptoms are:
DMA does not work as the polarity bits (DMA Req, Ack, EOT) are not set=20
correctly in the DMA controller using the ppc4xx_init_dma_channel()=20
function call, but when this is called twice in succession, then it does =
work.
Cause is (I believe):
/arch/ppc/syslib/ppc4xx_dma.c:
On line 469 the old polarity bits in p_dma_ch are ORed in when it should =
be ORing in the new polarity bits from p_init. p_init is then saved into =
p_dma_ch. This means that it only gets correctly programmed when the=20
function is called twice:
467 /* clear all polarity signals and then "or" in new signal =
levels */
468 polarity &=3D ~GET_DMA_POLARITY(dmanr);
469 polarity |=3D p_dma_ch->polarity;
Fix should be:
469 polarity |=3D p_init->polarity;
Is there anyone else using the PPC4XX DMA?
Colin Wernham
^ permalink raw reply
* Re: video card for Lite5200
From: Gerhard Jaeger @ 2004-12-10 7:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20041210015932.A3B692BDA0@ozlabs.org>
Hi,
On Friday 10 December 2004 02:33, wangwenbin wrote:
> Hi all
>=20
> I have successfully boot Linux 2.4.22 on my Lite5200 Evaluation Board =
with the ELDK. but when I want to use PCI slot for the video card,something=
goes wrong. The whole board loses supply of electricity. And i take the vi=
deo card out ,the board is still ok. So i change to put RTL81390 network ca=
rd into PCI slot. The same thing happen.
> The video card i have tried :
> S3 Trio64V
> Trident TGUI9680
> S3 ViRGE/DX
> Then I ask the Freescale support, they tell me that these board can op=
erate in 5V slot only, While the PCI slot on Lite5200 only offers 3.3V. The=
se days though I search much information about vedio card. I still don't wh=
ich card can fit Lite5200.And I knew that the new CoralP PCI video card can=
support Lite5200. Can I get it from market? Anyway I really worry about th=
is, so I turn here and ask your help.and I really appreciate your help! tha=
nks a lot! (There was something wrong with my mailbox,I could not receive t=
he letters these days.So I post it again)=20
> Best Regards, =20
> Tony Wang
> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80s=
tcwang@163.net
first of all, you need to take care of the PCI cards you use. As the Freesc=
ale support and=20
also the manuals say: "Only 3.3V compliant PCI cards". In the meantime ther=
e are quite a lot
of burned-out boards because of "wrong" cards.
Next problem with the PCI bus on this board is, that because of some timing=
issues not all=20
cards will be detected, so it'll be hard to find a video card, that matches=
these requirements.
The only card that I know, which seems to work AND is somehow supported is =
a CORAL-P evaluation=20
board from Fujitsu. But this one is rather expensive.=20
I tried also and old Nvidia Riva 128 card, which was detected correctly, bu=
t is not
initialized correctly by the framebuffer driver.
Regards,
Gerhard
=2D-=20
Gerhard Jaeger <gjaeger@sysgo.com> =20
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com
^ permalink raw reply
* video card for Lite5200
From: wangwenbin @ 2004-12-10 1:33 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
SGkgYWxsDQoNCiAgIEkgaGF2ZSBzdWNjZXNzZnVsbHkgYm9vdCBMaW51eCAyLjQuMjIgb24gbXkg
TGl0ZTUyMDAgRXZhbHVhdGlvbiBCb2FyZCB3aXRoIHRoZSBFTERLLiBidXQgd2hlbiBJIHdhbnQg
dG8gdXNlIFBDSSBzbG90IGZvciB0aGUgdmlkZW8gY2FyZCxzb21ldGhpbmcgZ29lcyB3cm9uZy4g
VGhlIHdob2xlIGJvYXJkIGxvc2VzIHN1cHBseSBvZiBlbGVjdHJpY2l0eS4gQW5kIGkgdGFrZSB0
aGUgdmlkZW8gY2FyZCBvdXQgLHRoZSBib2FyZCBpcyBzdGlsbCBvay4gU28gaSBjaGFuZ2UgdG8g
cHV0IFJUTDgxMzkwIG5ldHdvcmsgY2FyZCBpbnRvIFBDSSBzbG90LiBUaGUgc2FtZSB0aGluZyBo
YXBwZW4uDQogICAgVGhlIHZpZGVvIGNhcmQgaSBoYXZlIHRyaWVkIDoNCiAgICAgICAgICAgIFMz
IFRyaW82NFYNCiAgICAgICAgICAgIFRyaWRlbnQgVEdVSTk2ODANCiAgICAgICAgICAgIFMzIFZp
UkdFL0RYDQogICBUaGVuIEkgYXNrIHRoZSBGcmVlc2NhbGUgc3VwcG9ydCwgdGhleSB0ZWxsIG1l
IHRoYXQgdGhlc2UgYm9hcmQgY2FuIG9wZXJhdGUgaW4gNVYgc2xvdCBvbmx5LCBXaGlsZSB0aGUg
UENJIHNsb3Qgb24gTGl0ZTUyMDAgb25seSBvZmZlcnMgMy4zVi4gVGhlc2UgZGF5cyB0aG91Z2gg
SSBzZWFyY2ggbXVjaCBpbmZvcm1hdGlvbiBhYm91dCB2ZWRpbyBjYXJkLiBJIHN0aWxsIGRvbid0
IHdoaWNoIGNhcmQgY2FuIGZpdCBMaXRlNTIwMC5BbmQgSSBrbmV3IHRoYXQgdGhlIG5ldyBDb3Jh
bFAgUENJIHZpZGVvIGNhcmQgY2FuIHN1cHBvcnQgTGl0ZTUyMDAuIENhbiBJIGdldCBpdCBmcm9t
IG1hcmtldD8gQW55d2F5IEkgcmVhbGx5IHdvcnJ5IGFib3V0IHRoaXMsIHNvIEkgdHVybiBoZXJl
IGFuZCBhc2sgeW91ciBoZWxwLmFuZCBJIHJlYWxseSBhcHByZWNpYXRlIHlvdXIgaGVscCEgdGhh
bmtzIGEgbG90ISAoVGhlcmUgd2FzIHNvbWV0aGluZyB3cm9uZyB3aXRoIG15IG1haWxib3gsSSBj
b3VsZCBub3QgcmVjZWl2ZSB0aGUgbGV0dGVycyB0aGVzZSBkYXlzLlNvIEkgcG9zdCBpdCBhZ2Fp
bikgDQogICAgICAgICAgICAgICBCZXN0IFJlZ2FyZHMsICANCgkJCSAgIFRvbnkgV2FuZw0KoaGh
oaGhoaGhoaGhoaGhoXN0Y3dhbmdAMTYzLm5ldA0KoaGhoaGhoaGhoaGhoaGhoaGhoaENCg==
^ permalink raw reply
* Software routing in 8275
From: Jostein Pettersen @ 2004-12-09 15:43 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
Hi,
We consider using a MPC8275 running Embedded Linux to route two 100MB/s
Ethernet links in software. The traffic will mostly be incoming on the two
FE links and outgoing on the PCI bus, which is connected to a gigabit
routing chip (can't connect the two FE links to the routing chip directly,
since it only has GE ports).
My question is:
Will the MPC8275 be able to handle 2xFE full speed?
Doing the calculations about bus speeds etc, it looks ok, but I know Linux
does not like high interrupt rates. Is there a rule of thumb about what's
the maximum recommended interrupt rate at a given clock speed?
Hope to hear from you,
Regards
Jostein Pettersen
[-- Attachment #2: Type: text/html, Size: 730 bytes --]
^ permalink raw reply
* RE: MPC8280 Linux Kernel Patch
From: Srivatsan @ 2004-12-09 15:32 UTC (permalink / raw)
To: 'Geert Uytterhoeven'; +Cc: linuxppc-embedded
In-Reply-To: <Pine.GSO.4.61.0412091627120.9956@waterleaf.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]
I am sorry about that
With Best Regards,
C.R.Srivatsan
-----Original Message-----
From: geert@sonycom.com [mailto:geert@sonycom.com] On Behalf Of Geert
Uytterhoeven
Sent: Thursday, December 09, 2004 8:58 PM
To: Srivatsan
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC8280 Linux Kernel Patch
On Thu, 9 Dec 2004, Srivatsan wrote:
> Can anyone give me pointers where I can find patch for supporting
> MPC8280 processor for Linuxppc Kernel 2.4.20(has support for MPC8260)?
>
> The help would be highly appreciated.
When replying, please reply _below_ the part your replying to, and cut
away
superfluous text (especially when replying to a digest).
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-embedded digest..."
Perhaps these simple rules of netiquette can be added here as well?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker.
But
when I'm talking to journalists I just say "programmer" or something
like that.
-- Linus
Torvalds
********************************DISCLAIMER**********************************
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.
****************************************************************************
^ permalink raw reply
* Re: MPC8280 Linux Kernel Patch
From: Geert Uytterhoeven @ 2004-12-09 15:28 UTC (permalink / raw)
To: Srivatsan; +Cc: linuxppc-embedded
In-Reply-To: <000201c4de01$b26e4080$4501a8c0@bgcw301>
On Thu, 9 Dec 2004, Srivatsan wrote:
> Can anyone give me pointers where I can find patch for supporting
> MPC8280 processor for Linuxppc Kernel 2.4.20(has support for MPC8260)?
>
> The help would be highly appreciated.
When replying, please reply _below_ the part your replying to, and cut away
superfluous text (especially when replying to a digest).
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-embedded digest..."
Perhaps these simple rules of netiquette can be added here as well?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* MPC8280 Linux Kernel Patch
From: Srivatsan @ 2004-12-09 15:13 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20041209045615.DDD462BF0E@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 34186 bytes --]
Greetings to all.
Can anyone give me pointers where I can find patch for supporting
MPC8280 processor for Linuxppc Kernel 2.4.20(has support for MPC8260)?
The help would be highly appreciated.
With Best Regards,
C.R.Srivatsan
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
linuxppc-embedded-request@ozlabs.org
Sent: Thursday, December 09, 2004 10:26 AM
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 4, Issue 13
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. Linux PCI support on Ocotea (Chris Love)
2. Re: Linux PCI support on Ocotea (Matt Porter)
3. Re: Linux PCI support on Ocotea (Chris Love)
4. [RFC][PPC32] platform device / driver model usage (Kumar Gala)
----------------------------------------------------------------------
Message: 1
Date: Wed, 08 Dec 2004 17:10:54 -0800
From: Chris Love <love@ccpu.com>
Subject: Linux PCI support on Ocotea
To: linuxppc-embedded@ozlabs.org
Message-ID: <41B7A61E.9000602@ccpu.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Hi folks,
We have an Ocotea reference board (PPC 440GX) w/256M and have
tried running both stable 2.4.26 and 2.6.10-rc3 kernels from
penguinppc.org. For now the bootloader is still PIBS, though
we'll get U-Boot installed shortly.
As a first experiment we've tried installing a legacy card
with an Intel 82559 device on it. The warning seen from
pci_setup_device() suggests that PCI config space wasn't
read cleanly: a header type of 0x7f is encountered. Nothing
shows up under /proc/bus/pci. The card we'd actually like to
install has a transparent bridge (Intel 21152) and other devices
behind the bridge. Both cards are PCI-33 versus PCI-X.
To ask some really stupid questions first: what is the state of
PCI support with linux on this board? Have others tried to do
something like this with 33/66 Mhz PCI devices or am I in
uncharted waters?
Of the PCI #defines in platforms/ocotea.h I can correlate most
with data from the user's manual, but not the following:
#define OCOTEA_PCI_LOWER_IO 0x00000000
#define OCOTEA_PCI_UPPER_IO 0x0000ffff
#define OCOTEA_PCI_LOWER_MEM 0x80000000
#define OCOTEA_PCI_UPPER_MEM 0xffffefff
Is there some documentation I'm missing on these values?
Thanks in advance for any suggestions,
Chris
--
Chris Love // Continuous Computing Corporation
love@ccpu.com // http://www.ccpu.com
------------------------------
Message: 2
Date: Wed, 8 Dec 2004 18:49:58 -0700
From: Matt Porter <mporter@kernel.crashing.org>
Subject: Re: Linux PCI support on Ocotea
To: Chris Love <love@ccpu.com>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <20041208184958.A22430@home.com>
Content-Type: text/plain; charset=us-ascii
On Wed, Dec 08, 2004 at 05:10:54PM -0800, Chris Love wrote:
> Hi folks,
>
> We have an Ocotea reference board (PPC 440GX) w/256M and have
> tried running both stable 2.4.26 and 2.6.10-rc3 kernels from
> penguinppc.org. For now the bootloader is still PIBS, though
> we'll get U-Boot installed shortly.
>
> As a first experiment we've tried installing a legacy card
> with an Intel 82559 device on it. The warning seen from
> pci_setup_device() suggests that PCI config space wasn't
> read cleanly: a header type of 0x7f is encountered. Nothing
> shows up under /proc/bus/pci. The card we'd actually like to
> install has a transparent bridge (Intel 21152) and other devices
> behind the bridge. Both cards are PCI-33 versus PCI-X.
Sounds like something is wrong with your hardware configuration.
> To ask some really stupid questions first: what is the state of
> PCI support with linux on this board? Have others tried to do
> something like this with 33/66 Mhz PCI devices or am I in
> uncharted waters?
No, this works fine for many other people, so don't get too worried.
Do verify that you have jumpered for 33Mhz operation since you
are using a 33Mhz device. PIBS should warn you about this and
advise to make the change, but maybe you have a different
version than I've seen. What rev. ocotea board and version of
PIBS do you have?
> Of the PCI #defines in platforms/ocotea.h I can correlate most
> with data from the user's manual, but not the following:
>
> #define OCOTEA_PCI_LOWER_IO 0x00000000
> #define OCOTEA_PCI_UPPER_IO 0x0000ffff
> #define OCOTEA_PCI_LOWER_MEM 0x80000000
> #define OCOTEA_PCI_UPPER_MEM 0xffffefff
>
> Is there some documentation I'm missing on these values?
The code is self-documenting as they say. :) These are the address
ranges used by the pci_auto code to assign base addresses to each
BAR that is encountered.
-Matt
------------------------------
Message: 3
Date: Wed, 08 Dec 2004 18:20:29 -0800
From: Chris Love <love@ccpu.com>
Subject: Re: Linux PCI support on Ocotea
To: Matt Porter <mporter@kernel.crashing.org>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <41B7B66D.2000409@ccpu.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Matt Porter wrote:
> On Wed, Dec 08, 2004 at 05:10:54PM -0800, Chris Love wrote:
>
>>Hi folks,
>>
>>We have an Ocotea reference board (PPC 440GX) w/256M and have
>>tried running both stable 2.4.26 and 2.6.10-rc3 kernels from
>>penguinppc.org. For now the bootloader is still PIBS, though
>>we'll get U-Boot installed shortly.
>>
>>As a first experiment we've tried installing a legacy card
>>with an Intel 82559 device on it. The warning seen from
>>pci_setup_device() suggests that PCI config space wasn't
>>read cleanly: a header type of 0x7f is encountered. Nothing
>>shows up under /proc/bus/pci. The card we'd actually like to
>>install has a transparent bridge (Intel 21152) and other devices
>>behind the bridge. Both cards are PCI-33 versus PCI-X.
>
>
> Sounds like something is wrong with your hardware configuration.
>
>
>>To ask some really stupid questions first: what is the state of
>>PCI support with linux on this board? Have others tried to do
>>something like this with 33/66 Mhz PCI devices or am I in
>>uncharted waters?
>
>
> No, this works fine for many other people, so don't get too worried.
> Do verify that you have jumpered for 33Mhz operation since you
> are using a 33Mhz device. PIBS should warn you about this and
> advise to make the change, but maybe you have a different
> version than I've seen. What rev. ocotea board and version of
> PIBS do you have?
Hi Matt,
PIBS version text is "Version 1.80 JUNE/17/2004".
Ocotea rev appears to be rev 5.
Changing the settings for the U80 switches did the trick, at
least as far as silencing the PIBS warning and enumerating the bus
by Linux.
Thanks for the suggestion; this was lurking on the board schematics.
Chris
--
Chris Love // Continuous Computing Corporation
love@ccpu.com // http://www.ccpu.com
------------------------------
Message: 4
Date: Wed, 8 Dec 2004 22:56:03 -0600 (CST)
From: Kumar Gala <galak@somerset.sps.mot.com>
Subject: [RFC][PPC32] platform device / driver model usage
To: linux-kernel@vger.kernel.org
Cc: linuxppc-embedded@ozlabs.org
Message-ID:
<Pine.LNX.4.61.0412082233440.14848@blarg.somerset.sps.mot.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Moves the MPC85xx to using the driver model instead of OCP for
driver/device binding. Transitioned the gianfar ethernet driver over as
an example, this currently only works on the MPC8540ADS with TSEC1. The
patch is a work in progress to get feedback on.
This is based on patches from Jason McMullan at TimeSys.
I wanted to get feedback on the addition of a flags field to struct
platform_device. Also, if there was any issue with the addition of
include/linux/fsl_devices.h. Other comments are welcome.
thanks
- kumar
diff -Nru a/arch/ppc/platforms/85xx/Makefile
b/arch/ppc/platforms/85xx/Makefile
--- a/arch/ppc/platforms/85xx/Makefile 2004-12-08 22:22:37 -06:00
+++ b/arch/ppc/platforms/85xx/Makefile 2004-12-08 22:22:37 -06:00
@@ -1,6 +1,7 @@
#
# Makefile for the PowerPC 85xx linux kernel.
#
+obj-$(CONFIG_85xx) += mpc85xx.o
obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads_common.o mpc8540_ads.o
obj-$(CONFIG_MPC8555_CDS) += mpc85xx_cds_common.o
diff -Nru a/arch/ppc/platforms/85xx/mpc8540_ads.c
b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c 2004-12-08 22:22:37
-06:00
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c 2004-12-08 22:22:37
-06:00
@@ -32,6 +32,7 @@
#include <linux/serial_core.h>
#include <linux/initrd.h>
#include <linux/module.h>
+#include <linux/fsl_devices.h>
#include <asm/system.h>
#include <asm/pgtable.h>
@@ -54,6 +55,14 @@
#include <syslib/ppc85xx_common.h>
#include <syslib/ppc85xx_setup.h>
+struct gianfar_platform_data mpc85xx_gianfar1_def = {
+ .flags = GFAR_HAS_PHY_INTR,
+ .interruptPHY = MPC85xx_IRQ_EXT5,
+ .phyid = 0,
+ .phydevice = "fsl-gianfar1",
+ .phyregidx = 1,
+};
+
struct ocp_gfar_data mpc85xx_tsec1_def = {
.interruptTransmit = MPC85xx_IRQ_TSEC1_TX,
.interruptError = MPC85xx_IRQ_TSEC1_ERROR,
@@ -147,6 +156,8 @@
einfo = (struct ocp_gfar_data *) def->additions;
memcpy(einfo->mac_addr, binfo->bi_enet2addr, 6);
}
+
+ memcpy(mpc85xx_gianfar1_def.mac_addr, binfo->bi_enetaddr, 6);
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx.c
b/arch/ppc/platforms/85xx/mpc85xx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/platforms/85xx/mpc85xx.c 2004-12-08 22:22:37 -06:00
@@ -0,0 +1,243 @@
+/*
+ * arch/ppc/platforms/85xx/mpc85xx.c
+ *
+ * MPC85xx Device descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2004 Freescale Semiconductor 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/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/fsl_devices.h>
+#include <asm/mpc85xx.h>
+
+/* These should be defined in platform code */
+extern struct gianfar_platform_data mpc85xx_gianfar1_def;
+
+/* We use offsets for IORESOURCE_MEM since we do not know at compile
time
+ * what CCSRBAR is, platform code should fix this up in
+ * setup_arch
+ *
+ */
+
+static struct platform_device m_dev[] = {
+ [MPC85xx_TSEC1] = {
+ .name = "fsl-gianfar",
+ .id = 1,
+ .flags = GIANFAR_HAS_GIGABIT | GIANFAR_HAS_MULTI_INTR |
GIANFAR_HAS_RMON | GIANFAR_HAS_COALESCE,
+ .num_resources = 4,
+ .dev.platform_data = &mpc85xx_gianfar1_def,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_ENET1_OFFSET,
+ .end = MPC85xx_ENET1_OFFSET +
MPC85xx_ENET1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "tx",
+ .start = MPC85xx_IRQ_TSEC1_TX,
+ .end = MPC85xx_IRQ_TSEC1_TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "rx",
+ .start = MPC85xx_IRQ_TSEC1_RX,
+ .end = MPC85xx_IRQ_TSEC1_RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "error",
+ .start = MPC85xx_IRQ_TSEC1_ERROR,
+ .end = MPC85xx_IRQ_TSEC1_ERROR,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_TSEC2] = {
+ .name = "fsl-gianfar",
+ .id = 2,
+ .flags = GIANFAR_HAS_GIGABIT | GIANFAR_HAS_MULTI_INTR |
GIANFAR_HAS_RMON | GIANFAR_HAS_COALESCE,
+ .num_resources = 4,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_ENET2_OFFSET,
+ .end = MPC85xx_ENET2_OFFSET +
MPC85xx_ENET2_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "tx",
+ .start = MPC85xx_IRQ_TSEC2_TX,
+ .end = MPC85xx_IRQ_TSEC2_TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "rx",
+ .start = MPC85xx_IRQ_TSEC2_RX,
+ .end = MPC85xx_IRQ_TSEC2_RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "error",
+ .start = MPC85xx_IRQ_TSEC2_ERROR,
+ .end = MPC85xx_IRQ_TSEC2_ERROR,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_FEC] = {
+ .name = "fsl-gianfar",
+ .id = 3,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_ENET3_OFFSET,
+ .end = MPC85xx_ENET3_OFFSET +
MPC85xx_ENET3_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+
+ },
+ {
+ .start = MPC85xx_IRQ_TSEC1_TX,
+ .end = MPC85xx_IRQ_TSEC1_TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_IIC1] = {
+ .name = "fsl-i2c",
+ .id = 1,
+ .flags = FSL_I2C_SEPARATE_DFSRR,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_IIC1_OFFSET,
+ .end = MPC85xx_IIC1_OFFSET +
MPC85xx_IIC1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+
+ },
+ {
+ .start = MPC85xx_IRQ_IIC1,
+ .end = MPC85xx_IRQ_IIC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA0] = {
+ .name = "fsl-dma",
+ .id = 0,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA0_OFFSET,
+ .end = MPC85xx_DMA0_OFFSET +
MPC85xx_DMA0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+
+ },
+ {
+ .start = MPC85xx_IRQ_DMA0,
+ .end = MPC85xx_IRQ_DMA0,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA1] = {
+ .name = "fsl-dma",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA1_OFFSET,
+ .end = MPC85xx_DMA1_OFFSET +
MPC85xx_DMA1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+
+ },
+ {
+ .start = MPC85xx_IRQ_DMA1,
+ .end = MPC85xx_IRQ_DMA1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA2] = {
+ .name = "fsl-dma",
+ .id = 2,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA2_OFFSET,
+ .end = MPC85xx_DMA2_OFFSET +
MPC85xx_DMA2_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+
+ },
+ {
+ .start = MPC85xx_IRQ_DMA2,
+ .end = MPC85xx_IRQ_DMA2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA3] = {
+ .name = "fsl-dma",
+ .id = 3,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA3_OFFSET,
+ .end = MPC85xx_DMA3_OFFSET +
MPC85xx_DMA3_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+
+ },
+ {
+ .start = MPC85xx_IRQ_DMA3,
+ .end = MPC85xx_IRQ_DMA3,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+
+};
+
+static int
+mpc85xx_update_paddr(struct device *dev, void *arg)
+{
+ phys_addr_t ccsrbar;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct resource * r;
+
+ /* xxx - this only gets ioresource_mem 0 */
+ if (arg) {
+ ccsrbar = *(phys_addr_t *)arg;
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ r->start += ccsrbar;
+ r->end += ccsrbar;
+ }
+ return 0;
+}
+
+static int __init mach_mpc85xx_init(void)
+{
+ phys_addr_t ccsr = CCSRBAR;
+ platform_device_register(&m_dev[MPC85xx_TSEC1]);
+#if 0
+ platform_device_register(&m_dev[MPC85xx_TSEC2]);
+ platform_device_register(&m_dev[MPC85xx_FEC]);
+#endif
+ platform_device_register(&m_dev[MPC85xx_IIC1]);
+ platform_device_register(&m_dev[MPC85xx_DMA0]);
+ platform_device_register(&m_dev[MPC85xx_DMA1]);
+ platform_device_register(&m_dev[MPC85xx_DMA2]);
+ platform_device_register(&m_dev[MPC85xx_DMA3]);
+
+ bus_for_each_dev(&platform_bus_type, NULL, &ccsr,
mpc85xx_update_paddr);
+ return 0;
+}
+
+subsys_initcall(mach_mpc85xx_init);
+
diff -Nru a/drivers/base/platform.c b/drivers/base/platform.c
--- a/drivers/base/platform.c 2004-12-08 22:22:37 -06:00
+++ b/drivers/base/platform.c 2004-12-08 22:22:37 -06:00
@@ -58,6 +58,42 @@
}
/**
+ * platform_get_resource_byname - get a resource for a device by
name
+ * @dev: platform device
+ * @type: resource type
+ * @name: resource name
+ */
+struct resource *
+platform_get_resource_byname(struct platform_device *dev, unsigned int
type,
+ char * name)
+{
+ int i;
+
+ for (i = 0; i < dev->num_resources; i++) {
+ struct resource *r = &dev->resource[i];
+
+ if ((r->flags & (IORESOURCE_IO|IORESOURCE_MEM|
+ IORESOURCE_IRQ|IORESOURCE_DMA))
+ == type)
+ if (!strcmp(r->name, name))
+ return r;
+ }
+ return NULL;
+}
+
+/**
+ * platform_get_irq - get an IRQ for a device
+ * @dev: platform device
+ * @name: IRQ name
+ */
+int platform_get_irq_byname(struct platform_device *dev, char * name)
+{
+ struct resource *r = platform_get_resource_byname(dev,
IORESOURCE_IRQ, name);
+
+ return r ? r->start : 0;
+}
+
+/**
* platform_add_devices - add a numbers of platform devices
* @devs: array of platform devices to add
* @num: number of platform devices in array
@@ -103,7 +139,8 @@
for (i = 0; i < pdev->num_resources; i++) {
struct resource *p, *r = &pdev->resource[i];
- r->name = pdev->dev.bus_id;
+ if (r->name == NULL)
+ r->name = pdev->dev.bus_id;
p = NULL;
if (r->flags & IORESOURCE_MEM)
@@ -308,3 +345,5 @@
EXPORT_SYMBOL_GPL(platform_device_unregister);
EXPORT_SYMBOL_GPL(platform_get_irq);
EXPORT_SYMBOL_GPL(platform_get_resource);
+EXPORT_SYMBOL_GPL(platform_get_irq_byname);
+EXPORT_SYMBOL_GPL(platform_get_resource_byname);
diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c
--- a/drivers/net/gianfar.c 2004-12-08 22:22:37 -06:00
+++ b/drivers/net/gianfar.c 2004-12-08 22:22:37 -06:00
@@ -85,6 +85,7 @@
#include <linux/skbuff.h>
#include <linux/spinlock.h>
#include <linux/mm.h>
+#include <linux/device.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -93,6 +94,7 @@
#include <linux/version.h>
#include <linux/dma-mapping.h>
#include <linux/crc32.h>
+#include <linux/fsl_devices.h>
#include "gianfar.h"
#include "gianfar_phy.h"
@@ -130,8 +132,12 @@
static void adjust_link(struct net_device *dev);
static void init_registers(struct net_device *dev);
static int init_phy(struct net_device *dev);
+#if 0
static int gfar_probe(struct ocp_device *ocpdev);
static void gfar_remove(struct ocp_device *ocpdev);
+#endif
+static int gfar_probe(struct device *device);
+static int gfar_remove(struct device *device);
void free_skb_resources(struct gfar_private *priv);
static void gfar_set_multi(struct net_device *dev);
static void gfar_set_hash_for_addr(struct net_device *dev, u8 *addr);
@@ -148,6 +154,7 @@
MODULE_DESCRIPTION("Gianfar Ethernet Driver");
MODULE_LICENSE("GPL");
+#if 0
/* Called by the ocp code to initialize device data structures
* required for bringing up the device
* returns 0 on success */
@@ -196,7 +203,7 @@
priv = netdev_priv(dev);
/* Set the info in the priv to the current info */
- priv->einfo = einfo;
+ priv->einfo = pdev;
/* get a pointer to the register memory */
priv->regs = (struct gfar *)
@@ -343,6 +350,223 @@
iounmap((void *) priv->phyregs);
free_netdev(dev);
}
+#endif
+
+static int gfar_probe(struct device *device)
+{
+ u32 tempval;
+ struct platform_device *mdiodev;
+ struct net_device *dev = NULL;
+ struct gfar_private *priv = NULL;
+ struct platform_device *pdev = to_platform_device(device);
+ struct gianfar_platform_data *pdinfo;
+ struct resource *r;
+ int idx;
+ int err = 0;
+ int dev_ethtool_ops = 0;
+
+ pdinfo = (struct gianfar_platform_data *)
pdev->dev.platform_data;
+
+ if (pdinfo == NULL) {
+ printk(KERN_ERR "gfar %d: Missing additional data!\n",
+ pdev->id);
+
+ return -ENODEV;
+ }
+
+ /* get a pointer to the register memory which can
+ * configure the PHYs. If it's different from this set,
+ * get the device which has those regs */
+ if ((pdinfo->phyregidx >= 0) &&
+ (pdinfo->phyregidx != pdev->id)) {
+
+ /* xxx - broken, gregkh tells me device_find has locking
issues */
+ /* only enable the 1st TSEC for now */
+ struct device *d = device_find(pdinfo->phydevice,
&platform_bus_type);
+
+ mdiodev = to_platform_device(d);
+
+ /* If the device which holds the MDIO regs isn't
+ * up, wait for it to come up */
+ if (mdiodev == NULL)
+ return -EAGAIN;
+ } else {
+ mdiodev = pdev;
+ }
+
+ /* Create an ethernet device instance */
+ dev = alloc_etherdev(sizeof (*priv));
+
+ if (dev == NULL)
+ return -ENOMEM;
+
+ priv = netdev_priv(dev);
+
+ /* fill out IRQ fields */
+
+ if (pdev->flags & GFAR_HAS_MULTI_INTR) {
+ priv->interruptTransmit = platform_get_irq_byname(pdev,
"tx");
+ priv->interruptReceive = platform_get_irq_byname(pdev,
"rx");
+ priv->interruptError = platform_get_irq_byname(pdev,
"error");
+ } else {
+ priv->interruptTransmit = platform_get_irq(pdev, 0);
+ }
+
+ /* Set the info in the priv to the current info */
+ priv->einfo = pdev;
+ priv->pdinfo = pdinfo;
+
+ /* get a pointer to the register memory */
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->regs = (struct gfar *)
+ ioremap(r->start, sizeof (struct gfar));
+
+ if (priv->regs == NULL) {
+ err = -ENOMEM;
+ goto regs_fail;
+ }
+
+ /* Set the PHY base address */
+ r = platform_get_resource(mdiodev, IORESOURCE_MEM, 0);
+ priv->phyregs = (struct gfar *)
+ ioremap(r->start, sizeof (struct gfar));
+
+ if (priv->phyregs == NULL) {
+ err = -ENOMEM;
+ goto phy_regs_fail;
+ }
+
+ spin_lock_init(&priv->lock);
+
+ dev_set_drvdata(device, dev);
+
+ /* Stop the DMA engine now, in case it was running before */
+ /* (The firmware could have used it, and left it running). */
+ /* To do this, we write Graceful Receive Stop and Graceful */
+ /* Transmit Stop, and then wait until the corresponding bits */
+ /* in IEVENT indicate the stops have completed. */
+ tempval = gfar_read(&priv->regs->dmactrl);
+ tempval &= ~(DMACTRL_GRS | DMACTRL_GTS);
+ gfar_write(&priv->regs->dmactrl, tempval);
+
+ tempval = gfar_read(&priv->regs->dmactrl);
+ tempval |= (DMACTRL_GRS | DMACTRL_GTS);
+ gfar_write(&priv->regs->dmactrl, tempval);
+
+ while (!(gfar_read(&priv->regs->ievent) & (IEVENT_GRSC |
IEVENT_GTSC)))
+ cpu_relax();
+
+ /* Reset MAC layer */
+ gfar_write(&priv->regs->maccfg1, MACCFG1_SOFT_RESET);
+
+ tempval = (MACCFG1_TX_FLOW | MACCFG1_RX_FLOW);
+ gfar_write(&priv->regs->maccfg1, tempval);
+
+ /* Initialize MACCFG2. */
+ gfar_write(&priv->regs->maccfg2, MACCFG2_INIT_SETTINGS);
+
+ /* Initialize ECNTRL */
+ gfar_write(&priv->regs->ecntrl, ECNTRL_INIT_SETTINGS);
+
+ /* Copy the station address into the dev structure, */
+ memcpy(dev->dev_addr, pdinfo->mac_addr, MAC_ADDR_LEN);
+
+ /* Set the dev->base_addr to the gfar reg region */
+ dev->base_addr = (unsigned long) (priv->regs);
+
+ SET_MODULE_OWNER(dev);
+ SET_NETDEV_DEV(dev, device);
+
+ /* Fill in the dev structure */
+ dev->open = gfar_enet_open;
+ dev->hard_start_xmit = gfar_start_xmit;
+ dev->tx_timeout = gfar_timeout;
+ dev->watchdog_timeo = TX_TIMEOUT;
+#ifdef CONFIG_GFAR_NAPI
+ dev->poll = gfar_poll;
+ dev->weight = GFAR_DEV_WEIGHT;
+#endif
+ dev->stop = gfar_close;
+ dev->get_stats = gfar_get_stats;
+ dev->change_mtu = gfar_change_mtu;
+ dev->mtu = 1500;
+ dev->set_multicast_list = gfar_set_multi;
+
+ /* Index into the array of possible ethtool
+ * ops to catch all 4 possibilities */
+ if((priv->einfo->flags & GFAR_HAS_RMON) == 0)
+ dev_ethtool_ops += 1;
+
+ if((priv->einfo->flags & GFAR_HAS_COALESCE) == 0)
+ dev_ethtool_ops += 2;
+
+ dev->ethtool_ops = gfar_op_array[dev_ethtool_ops];
+
+ priv->rx_buffer_size = DEFAULT_RX_BUFFER_SIZE;
+#ifdef CONFIG_GFAR_BUFSTASH
+ priv->rx_stash_size = STASH_LENGTH;
+#endif
+ priv->tx_ring_size = DEFAULT_TX_RING_SIZE;
+ priv->rx_ring_size = DEFAULT_RX_RING_SIZE;
+
+ priv->txcoalescing = DEFAULT_TX_COALESCE;
+ priv->txcount = DEFAULT_TXCOUNT;
+ priv->txtime = DEFAULT_TXTIME;
+ priv->rxcoalescing = DEFAULT_RX_COALESCE;
+ priv->rxcount = DEFAULT_RXCOUNT;
+ priv->rxtime = DEFAULT_RXTIME;
+
+ err = register_netdev(dev);
+
+ if (err) {
+ printk(KERN_ERR "%s: Cannot register net device,
aborting.\n",
+ dev->name);
+ goto register_fail;
+ }
+
+ /* Print out the device info */
+ printk(KERN_INFO DEVICE_NAME, dev->name);
+ for (idx = 0; idx < 6; idx++)
+ printk("%2.2x%c", dev->dev_addr[idx], idx == 5 ? ' ' :
':');
+ printk("\n");
+
+ /* Even more device info helps when determining which kernel */
+ /* provided which set of benchmarks. Since this is global for
all */
+ /* devices, we only print it once */
+#ifdef CONFIG_GFAR_NAPI
+ printk(KERN_INFO "%s: Running with NAPI enabled\n", dev->name);
+#else
+ printk(KERN_INFO "%s: Running with NAPI disabled\n", dev->name);
+#endif
+ printk(KERN_INFO "%s: %d/%d RX/TX BD ring size\n",
+ dev->name, priv->rx_ring_size, priv->tx_ring_size);
+
+ return 0;
+
+register_fail:
+ iounmap((void *) priv->phyregs);
+phy_regs_fail:
+ iounmap((void *) priv->regs);
+regs_fail:
+ free_netdev(dev);
+ return -ENOMEM;
+ return 0;
+}
+
+static int gfar_remove(struct device *device)
+{
+ struct net_device *dev = dev_get_drvdata(device);
+ struct gfar_private *priv = netdev_priv(dev);
+
+ dev_set_drvdata(device, NULL);
+
+ iounmap((void *) priv->regs);
+ iounmap((void *) priv->phyregs);
+ free_netdev(dev);
+
+ return 0;
+}
+
/* Configure the PHY for dev.
* returns 0 if success. -1 if failure
@@ -381,7 +605,7 @@
ADVERTISED_1000baseT_Full);
mii_info->autoneg = 1;
- mii_info->mii_id = priv->einfo->phyid;
+ mii_info->mii_id = priv->pdinfo->phyid;
mii_info->dev = dev;
@@ -549,15 +773,15 @@
/* Free the IRQs */
if (priv->einfo->flags & GFAR_HAS_MULTI_INTR) {
- free_irq(priv->einfo->interruptError, dev);
- free_irq(priv->einfo->interruptTransmit, dev);
- free_irq(priv->einfo->interruptReceive, dev);
+ free_irq(priv->interruptError, dev);
+ free_irq(priv->interruptTransmit, dev);
+ free_irq(priv->interruptReceive, dev);
} else {
- free_irq(priv->einfo->interruptTransmit, dev);
+ free_irq(priv->interruptTransmit, dev);
}
if (priv->einfo->flags & GFAR_HAS_PHY_INTR) {
- free_irq(priv->einfo->interruptPHY, dev);
+ free_irq(priv->pdinfo->interruptPHY, dev);
} else {
del_timer_sync(&priv->phy_info_timer);
}
@@ -730,38 +954,38 @@
if (priv->einfo->flags & GFAR_HAS_MULTI_INTR) {
/* Install our interrupt handlers for Error,
* Transmit, and Receive */
- if (request_irq(priv->einfo->interruptError, gfar_error,
+ if (request_irq(priv->interruptError, gfar_error,
0, "enet_error", dev) < 0) {
printk(KERN_ERR "%s: Can't get IRQ %d\n",
- dev->name, priv->einfo->interruptError);
+ dev->name, priv->interruptError);
err = -1;
goto err_irq_fail;
}
- if (request_irq(priv->einfo->interruptTransmit,
gfar_transmit,
+ if (request_irq(priv->interruptTransmit, gfar_transmit,
0, "enet_tx", dev) < 0) {
printk(KERN_ERR "%s: Can't get IRQ %d\n",
- dev->name,
priv->einfo->interruptTransmit);
+ dev->name, priv->interruptTransmit);
err = -1;
goto tx_irq_fail;
}
- if (request_irq(priv->einfo->interruptReceive,
gfar_receive,
+ if (request_irq(priv->interruptReceive, gfar_receive,
0, "enet_rx", dev) < 0) {
printk(KERN_ERR "%s: Can't get IRQ %d
(receive0)\n",
- dev->name,
priv->einfo->interruptReceive);
+ dev->name, priv->interruptReceive);
err = -1;
goto rx_irq_fail;
}
} else {
- if (request_irq(priv->einfo->interruptTransmit,
gfar_interrupt,
+ if (request_irq(priv->interruptTransmit, gfar_interrupt,
0, "gfar_interrupt", dev) < 0) {
printk(KERN_ERR "%s: Can't get IRQ %d\n",
- dev->name, priv->einfo->interruptError);
+ dev->name, priv->interruptError);
err = -1;
goto err_irq_fail;
@@ -815,9 +1039,9 @@
return 0;
rx_irq_fail:
- free_irq(priv->einfo->interruptTransmit, dev);
+ free_irq(priv->interruptTransmit, dev);
tx_irq_fail:
- free_irq(priv->einfo->interruptError, dev);
+ free_irq(priv->interruptError, dev);
err_irq_fail:
rx_skb_fail:
free_skb_resources(priv);
@@ -1548,14 +1772,14 @@
/* Grab the PHY interrupt, if necessary/possible */
if (priv->einfo->flags & GFAR_HAS_PHY_INTR) {
- if (request_irq(priv->einfo->interruptPHY,
+ if (request_irq(priv->pdinfo->interruptPHY,
phy_interrupt,
SA_SHIRQ,
"phy_interrupt",
mii_info->dev) < 0) {
printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n",
mii_info->dev->name,
- priv->einfo->interruptPHY);
+ priv->pdinfo->interruptPHY);
} else {
mii_configure_phy_interrupt(priv->mii_info,
MII_INTERRUPT_ENABLED);
@@ -1828,6 +2052,7 @@
return IRQ_HANDLED;
}
+#if 0
/* Structure for a device driver */
static struct ocp_device_id gfar_ids[] = {
{.vendor = OCP_ANY_ID,.function = OCP_FUNC_GFAR},
@@ -1862,3 +2087,26 @@
module_init(gfar_init);
module_exit(gfar_exit);
+#endif
+
+/* Structure for a device driver */
+static struct device_driver gfar_driver = {
+ .name = "fsl-gianfar",
+ .bus = &platform_bus_type,
+ .probe = gfar_probe,
+ .remove = gfar_remove,
+};
+
+static int __init gfar_init(void)
+{
+ return driver_register(&gfar_driver);
+}
+
+static void __exit gfar_exit(void)
+{
+ driver_unregister(&gfar_driver);
+}
+
+module_init(gfar_init);
+module_exit(gfar_exit);
+
diff -Nru a/drivers/net/gianfar.h b/drivers/net/gianfar.h
--- a/drivers/net/gianfar.h 2004-12-08 22:22:37 -06:00
+++ b/drivers/net/gianfar.h 2004-12-08 22:22:37 -06:00
@@ -510,7 +510,11 @@
unsigned int rxclean;
/* Info structure initialized by board setup code */
- struct ocp_gfar_data *einfo;
+ unsigned int interruptTransmit;
+ unsigned int interruptReceive;
+ unsigned int interruptError;
+ struct platform_device *einfo;
+ struct gianfar_platform_data *pdinfo;
struct gfar_mii_info *mii_info;
int oldspeed;
diff -Nru a/include/asm-ppc/mpc85xx.h b/include/asm-ppc/mpc85xx.h
--- a/include/asm-ppc/mpc85xx.h 2004-12-08 22:22:37 -06:00
+++ b/include/asm-ppc/mpc85xx.h 2004-12-08 22:22:37 -06:00
@@ -103,6 +103,14 @@
#define MPC85xx_CPM_SIZE (0x40000)
#define MPC85xx_DMA_OFFSET (0x21000)
#define MPC85xx_DMA_SIZE (0x01000)
+#define MPC85xx_DMA0_OFFSET (0x21100)
+#define MPC85xx_DMA0_SIZE (0x00080)
+#define MPC85xx_DMA1_OFFSET (0x21180)
+#define MPC85xx_DMA1_SIZE (0x00080)
+#define MPC85xx_DMA2_OFFSET (0x21200)
+#define MPC85xx_DMA2_SIZE (0x00080)
+#define MPC85xx_DMA3_OFFSET (0x21280)
+#define MPC85xx_DMA3_SIZE (0x00080)
#define MPC85xx_ENET1_OFFSET (0x24000)
#define MPC85xx_ENET1_SIZE (0x01000)
#define MPC85xx_ENET2_OFFSET (0x25000)
@@ -138,6 +146,17 @@
#else
#define CCSRBAR BOARD_CCSRBAR
#endif
+
+enum mpc85xx_devices {
+ MPC85xx_TSEC1,
+ MPC85xx_TSEC2,
+ MPC85xx_FEC,
+ MPC85xx_IIC1,
+ MPC85xx_DMA0,
+ MPC85xx_DMA1,
+ MPC85xx_DMA2,
+ MPC85xx_DMA3,
+};
#endif /* CONFIG_85xx */
#endif /* __ASM_MPC85xx_H__ */
diff -Nru a/include/linux/device.h b/include/linux/device.h
--- a/include/linux/device.h 2004-12-08 22:22:37 -06:00
+++ b/include/linux/device.h 2004-12-08 22:22:37 -06:00
@@ -370,6 +370,7 @@
struct device dev;
u32 num_resources;
struct resource * resource;
+ u32 flags;
};
#define to_platform_device(x) container_of((x), struct platform_device,
dev)
@@ -382,6 +383,8 @@
extern struct resource *platform_get_resource(struct platform_device *,
unsigned int, unsigned int);
extern int platform_get_irq(struct platform_device *, unsigned int);
+extern struct resource *platform_get_resource_byname(struct
platform_device *, unsigned int, char *);
+extern int platform_get_irq_byname(struct platform_device *, char *);
extern int platform_add_devices(struct platform_device **, int);
extern struct platform_device *platform_device_register_simple(char *,
unsigned int, struct resource *, unsigned int);
diff -Nru a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/include/linux/fsl_devices.h 2004-12-08 22:22:37 -06:00
@@ -0,0 +1,48 @@
+/*
+ * include/linux/fsl_devices.h
+ *
+ * Definitions for any platform device related flags or structures for
+ * Freescale processor devices
+ *
+ * Maintainer: Kumar Gala (kumar.gala@freescale.com)
+ *
+ * Copyright 2004 Freescale Semiconductor, 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.
+ */
+
+#ifdef __KERNEL__
+#ifndef _FSL_DEVICE_H_
+#define _FSL_DEVICE_H_
+
+/* A table of information for supporting the Gianfar Ethernet
Controller
+ * This helps identify which enet controller we are dealing with,
+ * and what type of enet controller it is
+ */
+struct gianfar_platform_data {
+ u32 flags;
+ u32 phyid;
+ uint interruptPHY;
+ uint phyregidx;
+ char * phydevice;
+ unsigned char mac_addr[6];
+};
+
+/* Flags related to gianfar device features */
+#define GIANFAR_HAS_GIGABIT 0x00000001
+#define GIANFAR_HAS_COALESCE 0x00000002
+#define GIANFAR_HAS_RMON 0x00000004
+#define GIANFAR_HAS_MULTI_INTR 0x00000008
+
+/* Flags in gianfar_platform_data */
+#define GIANFAR_PDATA_HAS_PHY_INTR 0x00000001 /* if not set
use a timer */
+
+/* Flags related to I2C device features */
+#define FSL_I2C_SEPARATE_DFSRR 0x00000001
+#define FSL_I2C_CLOCK_5200 0x00000002
+
+#endif /* _FSL_DEVICE_H_ */
+#endif /* __KERNEL__ */
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 4, Issue 13
************************************************
********************************DISCLAIMER**********************************
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.
****************************************************************************
^ permalink raw reply
* PowerPC 7410 hangs at early_init
From: Steve Priest @ 2004-12-09 14:45 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have a Radstone IMP1A with a 7410 processor and 64MB of RAM. This
basically a two chip card with a Marvel Discovery GT64260 handling
everything else. The monitor is PPCBoot version 2.2.0. I am trying to boot
ELDK Linux 2.4.25 as a uImage.
The kernel is successfully loaded and started by PPCBoot. Using some debug
code to control a user LED on the board I have been able to determine that
the kernel gets as far as 'bl early_init' in head.S, at which point it
appears to freeze. It does not execute any code in early_init, nor does it
return. It looks as though the branch is failing.
System.map shows that early_init is located at offset 0xB538. PPCBoot is
loading the kernel at 0x02000000 (32MB). I have tried loading at different
address in case something was getting overwritten without success.
Does anyone have any idea what the problem might be or seen anything
similar? Any suggestions gratefully received.
Thanks,
Steve.
^ permalink raw reply
* PPC4XX DMA polarity bug in linuxppc-2.6.9
From: Colin Wernham @ 2004-12-09 10:13 UTC (permalink / raw)
To: linuxppc-dev
I believe that there is a PPC4xx DMA driver bug in the following kernel,
file and function:
linuxppc-2.6.9,
/arch/ppc/syslib/ppc4xx_dma.c,
ppc4xx_init_dma_channel()
Symptoms are:
DMA does not work as the polarity bits (DMA Req, Ack, EOT) are not set
correctly in the DMA controller using the ppc4xx_init_dma_channel()
function call, but when this is called twice in succession, then it does
work.
Cause is (I believe):
/arch/ppc/syslib/ppc4xx_dma.c:
On line 469 the old polarity bits in p_dma_ch are ORed in when it should
be ORing in the new polarity bits from p_init. p_init is then saved into
p_dma_ch. This means that it only gets correctly programmed when the
function is called twice:
467 /* clear all polarity signals and then "or" in new signal levels */
468 polarity &= ~GET_DMA_POLARITY(dmanr);
469 polarity |= p_dma_ch->polarity;
Fix could be:
469 polarity |= p_init->polarity;
Is there anyone else using the PPC4XX DMA?
Colin Wernham
^ permalink raw reply
* CONFIG_DUMMY_CONSOLE question
From: alebas @ 2004-12-09 9:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Checking console initialization on mpc8272ads board,
I have seen that the CONFIG_DUMMY_CONSOLE config
parameter is allways set in root .config file, regardless
of its value on my arch/ppc/configs/ads8272_defconfig file.
This parameter drives to the VGA dummy console being
compiled and included in the vmlinux binary, and started
as default console for the board (which must be changed
with console boot arg).
Does anyone knows if this parameter is a must in any kernel
2.6 configuration? And why? Can it be removed, as my board
doesn't use VGA at all? How? (I have tried several options)
Thanks,
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox