* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-15 15:01 UTC (permalink / raw)
To: Jason McMullan; +Cc: Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <1118846034.7564.113.camel@jmcmullan.timesys>
On Jun 15, 2005, at 9:33 AM, Jason McMullan wrote:
> On Wed, 2005-06-15 at 09:25 -0500, Kumar Gala wrote:
>> Yes, I removed the fcc_regs_c since its not always true. Please don't
>> rename the file to cpm2_. I think I'm going to end up renaming them
>> to
>> pq2_ since that is the most appropriate name. I'd say we are about
>> 80%
>
> PQ2_? But all these devices are on PQ3 also!
Sure and they are in the mpc85xx_* files. Maybe I'm missing some
concern people have here. It dont see what the issue is. This is just
like how TSEC/gianfar show up in both mpc85xx_* and mpc83xx_*. These
files are intended to represent the devices found on a product family
(PQ2, PQ3, PQ2 Pro, etc.). There is going to be overlap.
Also, its not 100% true that all of the devices on a PQ2 exist in PQ3.
For example (and this isn't a great one) the security block on
8248/8272 is different than the security block on PQ3 devices.
- kumar
^ permalink raw reply
* 2.4.26 and MPC885 context switching time
From: Schaefer-Hutter, Peter @ 2005-06-15 14:55 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
i'm evaluating IPC on the MPC885ADS and discovered
that the context switching times seem to be quite=20
disappointing (up to 1ms). As we need to do a lot=20
of IPC later on, i'm interested bringing the time=20
down.
Therefore i wonder, if there are any known problems=20
with the MMU on 8xx and 2.4.2x which might explain=20
that?=20
Or is this the expected context switching time for=20
CPU @ 100 MHz (RAM @ 50 MHz)? Suggestions for a=20
benchmark program?
Thanks!
Peter
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Jason McMullan @ 2005-06-15 14:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <2731d19a2e3b9413db32be59726a4c82@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
On Wed, 2005-06-15 at 09:25 -0500, Kumar Gala wrote:
> Yes, I removed the fcc_regs_c since its not always true. Please don't
> rename the file to cpm2_. I think I'm going to end up renaming them to
> pq2_ since that is the most appropriate name. I'd say we are about 80%
PQ2_? But all these devices are on PQ3 also!
--
Jason McMullan <jason.mcmullan@gmail.com>
"Sure, send me the latest Knoppix DVD as an attachment..."
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Jason McMullan @ 2005-06-15 14:24 UTC (permalink / raw)
To: Allen Curtis; +Cc: linuxppc-embedded
In-Reply-To: <c2628642aad8b8107d0e9db84535ea0c@onz.com>
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
My personal opinions:
* Use macro-offsets into a cpm2_map_t struct
* Put fcc_c regs back in
* dpram[PROFF_*] should be in the resources list
* cpm2_* is a better name than MPC82xx_* or MPC85xx_*
* Keep CPM2_DMA, etc, as these *should* be showing up in
/proc/iomem, since, IIRC, the platform layer does
reserve them upon registration. (And I *do* have a DMA
layer then uses CPM2_DMA as a driver-ish thing)
--
Jason McMullan <jason.mcmullan@gmail.com>
"Sure, send me the latest Knoppix DVD as an attachment..."
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-15 14:30 UTC (permalink / raw)
To: Allen Curtis; +Cc: linuxppc-embedded
In-Reply-To: <c2628642aad8b8107d0e9db84535ea0c@onz.com>
On Jun 14, 2005, at 11:41 PM, Allen Curtis wrote:
>>>> I've also included our version of this patch for commentary. Did you
>>>> see a
>>>> need for the following to actually be devices? (DMA, CPM, SI1,
> SIC2).
>>>>
>>> The good thing about them actually being devices is that you can find
>>> them and the IO resources had already been remapped. You don't need a
>>> device driver for them but they are resources used by other device
>>> drivers.
>>
>> Not sure I follow. The IO resources are not mapped by anything until
>> some piece of code does an explicit ioremap(). How do you plan on
>> finding them? I've got now issue adding them, I just want to
>> understand how you see us using them. A simple code example might be
>> helpful.
Allen, you haven't addressed my question.
- kumar
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-15 14:29 UTC (permalink / raw)
To: Allen Curtis; +Cc: linuxppc-embedded
In-Reply-To: <c2628642aad8b8107d0e9db84535ea0c@onz.com>
>> I'm trying to stay away from basing things on the structure. Since
>> the offsets are truly fixed I see not reason to try to make sure that
>> the immap structure is always correct for all cases. Hopefully this
>> will end up removing the need to ifdef the immap structure as we go
>> forward.
>>
>
> I am not sure I understand the purpose of each access method. How is
> the immap structure used vs. the platform resources list? Going half
> way without a clear distinction of purpose will just confuse the
> matter. (my opinion)
Agreed, I guess what I mean is going forward drivers should contain
their own structure defn.
>> pq2_* instead of mpc82xx_ (8240/1/5 is not handled here) or cpm2_
>> (85xx has cpm2).
>
> I used the name CPM2 because that is how all the files are now renamed.
> Based on the #ifdef in your patch, you can see that 82xx and 83xx use
> the same device definitions. Lets change the name.
Sure but... I'll change the file names to pq2_ which is what makes the
most sense at the end of they.
- kumar
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-15 14:25 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <42AFDEFE.2040508@ru.mvista.com>
On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote:
> Kumar,
> I assume this as a IMMR enumerating you promised to help with. Is it in
> the final state? And what was the reason of fcc_regs_c removal?
> I'm also going to change the files name to cpm2_.. .
Yes, I removed the fcc_regs_c since its not always true. Please don't
rename the file to cpm2_. I think I'm going to end up renaming them to
pq2_ since that is the most appropriate name. I'd say we are about 80%
the way to a final patch.
- kumar
^ permalink raw reply
* Re: preemptive and low-latency patches for denx's 2.4.25
From: Jaap-Jan Boor @ 2005-06-15 13:56 UTC (permalink / raw)
To: Samuel Osorio Calvo; +Cc: linuxppc-embedded
In-Reply-To: <s2b0475d.030@scms1.sc.signaal.nl>
I have a patched 2.4.25 kernel with changes from the Denx kernel, the
lck1 patchset (O(1) scheduler, preempt and lowlatency patches), linux
trace toolkit patches (sort of handcrafted) and proprietary board
specific patches.
It's probably incompatible with anything else. I can however make a
patch against 2.4.25 vanilla for you.
Jaap-Jan
On 15-jun-2005, at 15:20, Samuel Osorio Calvo wrote:
> Hi all,
>
> Do any of you know where to find these patches for kernel 2.4.25
> coming with ELDK's v.3.1.1?
> I've seen the RTAI patch for it but nothing about preemptive or low-
> latency.. Will patches from "standard" distribution's kernels be
> compatible?? If so, would you, please, provide a link.....;-)
>
> Thanks a lot,
>
> Samuel.
>
> Unclassified.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
____
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum jjboor at aimsys dot nl
^ permalink raw reply
* Re: Anyone got drivers/mtd/maps/pm828.c?
From: Alex Zeffertt @ 2005-06-15 13:54 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <42B02AAD.6050805@anagramm.de>
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
Hi Clemens,
Thanks for your help. I've done it now (see attached). The
partitioning is specific to our application but it is easily modified.
I noticed a buggette in the mtd code while doing this. If you build
everything as a module then the sub-module loading doesn't work
properly. For example in gen_probe.c it says
#ifdef CONFIG_MTD_CFI_INTELEXT
case 0x0001:
case 0x0003:
return cfi_cmdset_0001(map, primary);
#endif
where it should really say
#if defined(CONFIG_MTD_CFI_INTELEXT) ||
defined(CONFIG_MTD_CFI_INTELEXT_MODULE)
case 0x0001:
case 0x0003:
return cfi_cmdset_0001(map, primary);
#endif
There are several problems like this. In the end I gave up and just
built everything except the actual mapping driver as kernel resident.
Alex
On Wed, 15 Jun 2005 15:18:37 +0200
Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hi, Alex!
>
> Hmm, I don't know the PM828 much in detail, but have you
> tried the "generic" physmap driver which is in the kernel?
> Just give it the base address and the size, and it should
> probe the cfi and you are done (well, it was working fine
> for me on my PM854).
> Of course, you need to make sure, that your hardware / memory
> mapping is initialized properly (which happens usually in the
> boot loader). If it's not, let me know and I can give you
> some code to mess around with the registers in a kernel module.
>
> Best greets,
>
> 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
>
>
> Alex Zeffertt wrote:
> > Hi there,
> >
> > I need to get flash partitions working on my PM828 development
> > board. Has anybody already written a pm828.c? If so I'd appreciate
> > a look at it.
> >
> > TIA,
> >
> > Alex
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
[-- Attachment #2: pm828-icu.c.gz --]
[-- Type: application/x-gzip, Size: 2480 bytes --]
^ permalink raw reply
* Re: MPC885 interruptions : OK
From: scarayol @ 2005-06-15 13:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I found the solution for my problem : i have to configure theSIU Interrupt
Edge/Level Register (SIEL)like that :
((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel |= 0x00020000; // for IRQ7
The SIMASK register was right.
Sophie.
> Hi all,
>
> I wrote a module driver to manage interruptions. I have an
> interruption on MPC885 IRQ7 activated by a push button that provides a
> negative pulse of 200 ns width.
> When the device is open, i call request_irq() to install the interrupt
> handler:
>
> int ret = request_irq(SIU_IRQ7, fpgadriver_irq_save_handler,
> SA_INTERRUPT, FPGA_ID, NULL);
>
> void fpgadriver_irq_save_handler(int irq, void *dev_id, struct pt_regs
> *regs)
> {
> fpga_it_source=FPGA_IRQ_SAVE;
> printk( "fpgadriver: fpgadriver_irq_save_handler for device \n");
> /* Prepare a task */
> PREPARE_TQUEUE(&fpgadriver_bh_task, fpgadriver_bh_handler, dev_id);
> /* Add a task to the immediate bottom half and mark it for schedule
> */ queue_task(&fpgadriver_bh_task, &tq_immediate);
> mark_bh(IMMEDIATE_BH);
> }
>
> my read() is like that :
>
> static ssize_t fpgadriver_read(struct file *file, char *buf, size_t
> count, loff_t *ppos)
> {
> //mise a jour de l'indicateur d'etat d'endormissement
> wakeups++;
> interruptible_sleep_on(&readq);
> buf[0]=fpga_it_source;
> printk("fpgadriver_read \n");
> return 0;
> }
>
> I have the wake_up_interruptible(&reaq) in fpgadriver_bh_handler(). My
> problem is that fpgadriver_irq_save_handler() is never called as if
> there is no interruption.
> Is there something else to modify to validate the interruption ? Is
> SIU_IRQ7 the right value for my interruption ? What have i to check ?
>
> Thanks for your reply.
>
> Sophie CARAYOL
^ permalink raw reply
* preemptive and low-latency patches for denx's 2.4.25
From: Samuel Osorio Calvo @ 2005-06-15 13:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Do any of you know where to find these patches for kernel 2.4.25 coming =
with ELDK's v.3.1.1?=20
I've seen the RTAI patch for it but nothing about preemptive or low-latency=
.. Will patches from "standard" distribution's kernels be compatible?? If =
so, would you, please, provide a link.....;-)
Thanks a lot,
Samuel.
Unclassified.
^ permalink raw reply
* Re: Anyone got drivers/mtd/maps/pm828.c?
From: Clemens Koller @ 2005-06-15 13:18 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20050614104749.387910e0.ajz@cambridgebroadband.com>
Hi, Alex!
Hmm, I don't know the PM828 much in detail, but have you
tried the "generic" physmap driver which is in the kernel?
Just give it the base address and the size, and it should
probe the cfi and you are done (well, it was working fine
for me on my PM854).
Of course, you need to make sure, that your hardware / memory
mapping is initialized properly (which happens usually in the
boot loader). If it's not, let me know and I can give you
some code to mess around with the registers in a kernel module.
Best greets,
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
Alex Zeffertt wrote:
> Hi there,
>
> I need to get flash partitions working on my PM828 development board.
> Has anybody already written a pm828.c? If so I'd appreciate a look at
> it.
>
> TIA,
>
> Alex
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: multicast disabled on 8260_io/fcc_enet.c
From: Samuel Osorio Calvo @ 2005-06-15 13:14 UTC (permalink / raw)
To: ajz; +Cc: linuxppc-embedded
Currently I have multicast working just be moving the return statement. It =
seems to work but I guess I did not face yet the problems that caused the =
code to be commented.
Let's say it works in an unreliable way....
Samuel.
Unclassified.
>>> Alex Zeffertt <ajz@cambridgebroadband.com> 06/14/05 10:31AM >>>
On Mon, 13 Jun 2005 18:14:06 +0200
"Samuel Osorio Calvo" <samuel.osorio@nl.thalesgroup.com> wrote:
> Hi all!
>=20
> I was playing with a mpc8260 board and the latest ELDK version, 3.1.1
> (linux 2.4.25) and face a strange behaviour:
>=20
> I was trying to make multicast work and everything seemed to be ok
> (/proc/net/igmp, /proc/net/dev_mcast), making a local ping to
> 224.0.0.1 returns localhost as part of the group, etc....BUT it was
> not possible to contact the board to the group it had joined from the
> network. I was digging into the kernel drivers and found a strange
> return statement just in teh start of the funciton set_multicast_list
> (arround line 1471 of the file mentioned in the subject of the mail).
> I moved the return to the end of the function and everything worked
> perfectly.
>=20
> My question is wether the return statement was moved at the starting
> of the function due to some bug of the set_multicast_list code or it
> was just a typo???
>=20
According to
http://ozlabs.org/pipermail/linuxppc-embedded/2005-May/018529.html=
=20
it would seem that multicast is not correctly implemented and has been
effectively commented out. This also stops promisc mode working. I
have removed the return in my source tree and promisc mode now works
fine. I can't say whether multicast works. Maybe you could just give it
a try and see what happens....
Alex
^ permalink raw reply
* Re: How to change SDRAM from HYNIX to AMIC
From: Mark Chambers @ 2005-06-15 12:52 UTC (permalink / raw)
To: Rober Hsu, linuxppc-embedded
In-Reply-To: <1118830434.4813.10.camel@orange.opnet.com.tw>
> Hi:
>
> I used HY57641620 * 2 at my MPC852T, the ram size is 16M, Now i want
> to change to AMIC A43L3616-6 * 2 32M.
>
> I modify my ppboot's as follow, but i don't know how to modfiy my
> sdram_table, anybody know what's the meaning of sdram_table?
>
The sdram_table is used to load the UPM, which drives the signals to SDRAM
on a clock by clock basis. This is not simple, and getting it wrong can
cause
intermittent problems that are very hard to diagnose. On the other hand,
the
changes required are probably minimal, but you'll need someone who knows
what they're doing to review the spec sheets for the new SDRAM and the UPM
table and make sure timing requirements are met.
Freescale has tools for free download that help with configuring the UPMs.
Mark Chambers
^ permalink raw reply
* Re: change the SDRAM address
From: Mark Chambers @ 2005-06-15 12:43 UTC (permalink / raw)
To: Jason Chen, linuxppc-embedded
In-Reply-To: <200506150531.j5F5VMPK006235@ms.usish.com>
> hi,all,
> I am a newer.I worked on a platform based on MPC8248.
> The 64M SDRAM use CS2,and it's base address is
0x00000000,BR2=0x00000041,OR2=fc002cd0.
> It's just a simple issue,I want to change the base address of the SDRAM
from 0x00000000 to 0x03000000,I thought change the BR2 register to
0x03000041 was ok,but the real thing is that you can read/write the area of
0x03000000 to 0x03ffffff,but the area above the 0x04000000 can not be
written and all be read as 0x0.
> I want to know am I right to change the base address just by change the
BR2?
> Is there some other should be change? Or it may connect with a hardware
change?
>
That base address just won't work right for 64MB. The target address AND'd
with
the mask in the upper part of the OR must equal the BR. Typically a 2^n
sized
area must be placed on a 2^n boundary (00xx xxxx, 04xx xxxx, and so on in
your
case)
Mark Chambers
^ permalink raw reply
* Réf. : Re: MPC885 interruptions : help !
From: scarayol @ 2005-06-15 11:36 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
Thank you,
but on the MPC885 IRQ7 is the only one function for this pin. On the other
hand, we have a problem in the kernel that calibrate the delay loop because
it found 2.17 BogoMIPS (instead of 50 or 80 BogoMIPS).
Could it explain the problem for the interruption ? (even if the
application work fine).
Sophie CARAYOL
Pins on the 8xx are highly configurable. I recommend that you check
that the pin has not been configured for another function. For example
on the 862 the SIU_IRQ7 pin doubles as the MII tx clock.
Alex
On Wed, 15 Jun 2005 10:35:41 +0200
scarayol@assystembrime.com wrote:
> Hi all,
>
> I wrote a module driver to manage interruptions. I have an
> interruption on MPC885 IRQ7 activated by a push button that provides a
> negative pulse of 200 ns width.
> When the device is open, i call request_irq() to install the interrupt
> handler:
>
> int ret = request_irq(SIU_IRQ7, fpgadriver_irq_save_handler,
> SA_INTERRUPT, FPGA_ID, NULL);
>
> void fpgadriver_irq_save_handler(int irq, void *dev_id, struct pt_regs
> *regs)
> {
> fpga_it_source=FPGA_IRQ_SAVE;
> printk( "fpgadriver: fpgadriver_irq_save_handler for device \n");
> /* Prepare a task */
> PREPARE_TQUEUE(&fpgadriver_bh_task, fpgadriver_bh_handler, dev_id);
> /* Add a task to the immediate bottom half and mark it for schedule
> */ queue_task(&fpgadriver_bh_task, &tq_immediate);
> mark_bh(IMMEDIATE_BH);
> }
>
> my read() is like that :
>
> static ssize_t fpgadriver_read(struct file *file, char *buf, size_t
> count, loff_t *ppos)
> {
> //mise a jour de l'indicateur d'etat d'endormissement
> wakeups++;
> interruptible_sleep_on(&readq);
> buf[0]=fpga_it_source;
> printk("fpgadriver_read \n");
> return 0;
> }
>
> I have the wake_up_interruptible(&reaq) in fpgadriver_bh_handler(). My
> problem is that fpgadriver_irq_save_handler() is never called as if
> there is no interruption.
> Is there something else to modify to validate the interruption ? Is
> SIU_IRQ7 the right value for my interruption ? What have i to check ?
>
> Thanks for your reply.
>
> Sophie CARAYOL
>
>
^ permalink raw reply
* How to change SDRAM from HYNIX to AMIC
From: Rober Hsu @ 2005-06-15 10:13 UTC (permalink / raw)
To: linuxppc-embedded
Hi:
I used HY57641620 * 2 at my MPC852T, the ram size is 16M, Now i want
to change to AMIC A43L3616-6 * 2 32M.
I modify my ppboot's as follow, but i don't know how to modfiy my
sdram_table, anybody know what's the meaning of sdram_table?
PS:I system hold at ## Starting linux kernel at 0x00580000 ...
Boot Loader v1.0.0 (Jun 15 2005 - 15:38:51)
CPU: MPC852T (0x08010004) at 100.00 MHz: 4 kB I-Cache 4 kB D-Cache FEC
presentDRAM: 32 MB
Not load linux now? (enter anykey):
Kernel file size :3d7832(hex)
Loading kernel ... ...
## Starting linux kernel at 0x00580000 ...
#include <ppcboot.h>
#include "mpc8xx.h"
/*
------------------------------------------------------------------------- */
static long int dram_size (long int, long int *, long int);
/*
------------------------------------------------------------------------- */
#define _NOT_USED_ 0xFFFFFFFF
const uint sdram_table[] =
{
/* Single Read. (offset 0x0-0x4 in UPM RAM) */
/* Precharge and MRS(offset 0x5-0x7 in UPM RAM) */
0x1F07FC04, 0xEEAEFC04, 0x11ADFC04, 0xEFBBBC00,
0x1FF77C47, 0x1FF77C35, 0xEFEABC34, 0x1FB57C35,
/* Burst Read. (offset 0x8-0xf in UPM RAM) */
0x1F07FC04, 0xEEAEFC04, 0x10ADFC04, 0xF0AFFC00,
0xF0AFFC00, 0xF1AFFC00, 0xEFBBBC00, 0x1FF77C47,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Single Write. (offset 0x18-0x1F in UPM RAM) */
0x1F27FC04, 0xEEAEBC00, 0x01B93C04, 0x1FF77C47,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Burst Write. (offset 20-2F in UPM RAM) */
0x1F07FC04, 0xEEAEBC00, 0x10AD7C00, 0xF0AFFC00,
0xF0AFFC00, 0xE1BBBC04, 0x1FF77C47, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Refresh timer expired (offset 30-3B in UPM RAM) */
0x1FF5FC84, 0xFFFFFC04, 0xFFFFFC04, 0xFFFFFC04,
0xFFFFFC84, 0xFFFFFC07, 0xffffffff, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Exception. (offset 3c-3f in UPM RAM) */
0x7FFFFC07, _NOT_USED_, _NOT_USED_, _NOT_USED_
};
/*
------------------------------------------------------------------------- */
/*
* Check Board Identity:
*
* Test TQ ID string (TQM8xx...)
* If present, check for "L" type (no second DRAM bank),
* otherwise "L" type is assumed as default.
*
* Return 1 for "L" type, 0 else.
*/
int checkboard (void)
{
return 0;
}
/*
------------------------------------------------------------------------- */
long int initdram(int board_type)
{
volatile immap_t *immap = (immap_t *)CFG_IMMR;
volatile memctl8xx_t *memctl = &immap->im_memctl;
upmconfig(UPMA, (uint *)sdram_table, sizeof(sdram_table)/sizeof(uint));
memctl->memc_mptpr = 0x0400;
/*
* Configure the refresh (mostly). This needs to be
* based upon processor clock speed and optimized to provide
* the highest level of performance. For multiple banks,
* this time has to be divided by the number of banks.
* Although it is not clear anywhere, it appears the
* refresh steps through the chip selects for this UPM
* on each refresh cycle.
* We have to be careful changing
* UPM registers after we ask it to run these commands.
*/
memctl->memc_mamr = 0xD0904114;
memctl->memc_mar = 0x00000088;
udelay(200);
memctl->memc_mcr = 0x80004105; /* precharge */
udelay(200);
memctl->memc_mamr = 0xD0904114;
memctl->memc_mcr = 0x80004830; /* refresh */
udelay(200);
memctl->memc_mamr = 0xD0904114;
memctl->memc_mcr = 0x80004106;
udelay(200);
memctl->memc_or2 = 0xFE000A00;
memctl->memc_br2 = 0x00000081;
return (32 * 1024 *1024);
} /* end of initdram */
^ permalink raw reply
* Re: MPC885 interruptions : help !
From: Alex Zeffertt @ 2005-06-15 10:26 UTC (permalink / raw)
To: scarayol; +Cc: linuxppc-embedded
In-Reply-To: <OF5286B922.38B1A4B5-ONC1257020.002FEFD0@brime.fr>
Pins on the 8xx are highly configurable. I recommend that you check
that the pin has not been configured for another function. For example
on the 862 the SIU_IRQ7 pin doubles as the MII tx clock.
Alex
On Wed, 15 Jun 2005 10:35:41 +0200
scarayol@assystembrime.com wrote:
> Hi all,
>
> I wrote a module driver to manage interruptions. I have an
> interruption on MPC885 IRQ7 activated by a push button that provides a
> negative pulse of 200 ns width.
> When the device is open, i call request_irq() to install the interrupt
> handler:
>
> int ret = request_irq(SIU_IRQ7, fpgadriver_irq_save_handler,
> SA_INTERRUPT, FPGA_ID, NULL);
>
> void fpgadriver_irq_save_handler(int irq, void *dev_id, struct pt_regs
> *regs)
> {
> fpga_it_source=FPGA_IRQ_SAVE;
> printk( "fpgadriver: fpgadriver_irq_save_handler for device \n");
> /* Prepare a task */
> PREPARE_TQUEUE(&fpgadriver_bh_task, fpgadriver_bh_handler, dev_id);
> /* Add a task to the immediate bottom half and mark it for schedule
> */ queue_task(&fpgadriver_bh_task, &tq_immediate);
> mark_bh(IMMEDIATE_BH);
> }
>
> my read() is like that :
>
> static ssize_t fpgadriver_read(struct file *file, char *buf, size_t
> count, loff_t *ppos)
> {
> //mise a jour de l'indicateur d'etat d'endormissement
> wakeups++;
> interruptible_sleep_on(&readq);
> buf[0]=fpga_it_source;
> printk("fpgadriver_read \n");
> return 0;
> }
>
> I have the wake_up_interruptible(&reaq) in fpgadriver_bh_handler(). My
> problem is that fpgadriver_irq_save_handler() is never called as if
> there is no interruption.
> Is there something else to modify to validate the interruption ? Is
> SIU_IRQ7 the right value for my interruption ? What have i to check ?
>
> Thanks for your reply.
>
> Sophie CARAYOL
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* MPC885 interruptions : help !
From: scarayol @ 2005-06-15 8:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I wrote a module driver to manage interruptions. I have an interruption on
MPC885 IRQ7 activated by a push button that provides a negative pulse of
200 ns width.
When the device is open, i call request_irq() to install the interrupt
handler:
int ret = request_irq(SIU_IRQ7, fpgadriver_irq_save_handler, SA_INTERRUPT,
FPGA_ID, NULL);
void fpgadriver_irq_save_handler(int irq, void *dev_id, struct pt_regs
*regs)
{
fpga_it_source=FPGA_IRQ_SAVE;
printk( "fpgadriver: fpgadriver_irq_save_handler for device \n");
/* Prepare a task */
PREPARE_TQUEUE(&fpgadriver_bh_task, fpgadriver_bh_handler, dev_id);
/* Add a task to the immediate bottom half and mark it for schedule */
queue_task(&fpgadriver_bh_task, &tq_immediate);
mark_bh(IMMEDIATE_BH);
}
my read() is like that :
static ssize_t fpgadriver_read(struct file *file, char *buf, size_t count,
loff_t *ppos)
{
//mise a jour de l'indicateur d'etat d'endormissement
wakeups++;
interruptible_sleep_on(&readq);
buf[0]=fpga_it_source;
printk("fpgadriver_read \n");
return 0;
}
I have the wake_up_interruptible(&reaq) in fpgadriver_bh_handler(). My
problem is that fpgadriver_irq_save_handler() is never called as if there
is no interruption.
Is there something else to modify to validate the interruption ? Is
SIU_IRQ7 the right value for my interruption ? What have i to check ?
Thanks for your reply.
Sophie CARAYOL
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Vitaly Bordug @ 2005-06-15 7:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0506142231040.2447@nylon.am.freescale.net>
Kumar,
I assume this as a IMMR enumerating you promised to help with. Is it in
the final state? And what was the reason of fcc_regs_c removal?
I'm also going to change the files name to cpm2_.. .
Allen,
I'll provide a patch containing these platform stuff together with
platform-specific device structures which is utilized in the fs_enet
driver. As now it's clear that fcc_mem dpram offset should be passed
over platform_info, these structures at least regarding fs_enet probably
will not change.
--
Sincerely, Vitaly
^ permalink raw reply
* change the SDRAM address
From: Jason Chen @ 2005-06-15 5:35 UTC (permalink / raw)
To: linuxppc-embedded
aGksYWxsLA0KSSBhbSBhIG5ld2VyLkkgd29ya2VkIG9uIGEgcGxhdGZvcm0gYmFzZWQgb24gTVBD
ODI0OC4NClRoZSA2NE0gU0RSQU0gdXNlIENTMixhbmQgaXQncyBiYXNlIGFkZHJlc3MgaXMgMHgw
MDAwMDAwMCxCUjI9MHgwMDAwMDA0MSxPUjI9ZmMwMDJjZDAuDQpJdCdzIGp1c3QgYSBzaW1wbGUg
aXNzdWUsSSB3YW50IHRvIGNoYW5nZSB0aGUgYmFzZSBhZGRyZXNzIG9mIHRoZSBTRFJBTSBmcm9t
IDB4MDAwMDAwMDAgdG8gMHgwMzAwMDAwMCxJIHRob3VnaHQgY2hhbmdlIHRoZSBCUjIgcmVnaXN0
ZXIgdG8gMHgwMzAwMDA0MSB3YXMgb2ssYnV0IHRoZSByZWFsIHRoaW5nIGlzIHRoYXQgeW91IGNh
biByZWFkL3dyaXRlIHRoZSBhcmVhIG9mIDB4MDMwMDAwMDAgdG8gMHgwM2ZmZmZmZixidXQgdGhl
IGFyZWEgYWJvdmUgdGhlIDB4MDQwMDAwMDAgY2FuIG5vdCBiZSB3cml0dGVuIGFuZCBhbGwgYmUg
cmVhZCBhcyAweDAuDQpJIHdhbnQgdG8ga25vdyBhbSBJIHJpZ2h0IHRvIGNoYW5nZSB0aGUgYmFz
ZSBhZGRyZXNzIGp1c3QgYnkgY2hhbmdlIHRoZSBCUjI/DQpJcyB0aGVyZSBzb21lIG90aGVyIHNo
b3VsZCBiZSBjaGFuZ2U/IE9yIGl0IG1heSBjb25uZWN0IHdpdGggYSBoYXJkd2FyZSBjaGFuZ2U/
DQoNClRoYW5rcw0KDQpKYXNvbg0KDQoJDQoNCqGhoaGhoaGhoaGhoQ0KDQqhoaGhoaGhoaGhoaGh
oaGhDQqhoaGhoaGhoaGhoaGhoaGhDQqhoaGhoaGhoaGhoaGhoaGhoaGhoQ0K
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Allen Curtis @ 2005-06-15 4:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <a38c1fefe53947c6b80ec3d6b4ffd09e@freescale.com>
>>> I've also included our version of this patch for commentary. Did you
>>> see a
>>> need for the following to actually be devices? (DMA, CPM, SI1, SIC2).
>>>
>> The good thing about them actually being devices is that you can find
>> them and the IO resources had already been remapped. You don't need a
>> device driver for them but they are resources used by other device
>> drivers.
>
> Not sure I follow. The IO resources are not mapped by anything until
> some piece of code does an explicit ioremap(). How do you plan on
> finding them? I've got now issue adding them, I just want to
> understand how you see us using them. A simple code example might be
> helpful.
>
See below...
>>> I can provide feedback on all the issues I had with you patch, but
>>> would
>>> prefer to start with ours (let me know).
>>>
>> Comments:
>> 1. You removed the other PRAM definition from this FCC definition,
>> this
>> is good.
>>
>> 2. I am torn about using numeric IMMR offsets vs. the structure member
>> approach. The good thing is that you can create all the devices in a
>> single table even if they overlay depending on processor. The question
>> is, will the IMMAP structure become obsolete? If not, then you will
>> still need the conditional compiles in immap_cpm2.h.
>
> I'm trying to stay away from basing things on the structure. Since
> the offsets are truly fixed I see not reason to try to make sure that
> the immap structure is always correct for all cases. Hopefully this
> will end up removing the need to ifdef the immap structure as we go
> forward.
>
I am not sure I understand the purpose of each access method. How is
the immap structure used vs. the platform resources list? Going half
way without a clear distinction of purpose will just confuse the
matter. (my opinion)
>> 3. Naming convention, are all these devices just in the MPC82xx
>> family?
>> If the CPM is a general FSL co-processor, used across many processor
>> families, then I like the CPM2 naming convention.
>
> The key there is the driver name not the enum name. If you look the
> driver name field matches 85xx. These files might be better of called
> pq2_* instead of mpc82xx_ (8240/1/5 is not handled here) or cpm2_
> (85xx has cpm2).
>
I used the name CPM2 because that is how all the files are now renamed.
Based on the #ifdef in your patch, you can see that 82xx and 83xx use
the same device definitions. Lets change the name.
>> 4. What about PCI?
>
> What about it, none of the busses have specific drivers at this point
> so they haven't been added.
>
>> 5. This patch does not address the platform specific device
>> structures.
>> How do you want to handle these?
>
> I want to do that as a second pass every we close on this. Since the
> platform specific device structs are going to be based on what is
> needed for the drivers.
>
That is true but a good example is the FCC definition. You removed one
IORESOURCE from the sample you provided earlier because it changed
based on processor. (8260 vs 8272) It would have been beneficial to see
this in your patch as an example.
-- Allen
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-15 4:13 UTC (permalink / raw)
To: Allen Curtis; +Cc: linuxppc-embedded
In-Reply-To: <42eb0bacadb197b42502ac1828450843@onz.com>
On Jun 14, 2005, at 10:57 PM, Allen Curtis wrote:
>> I've also included our version of this patch for commentary. Did you
>> see a
>> need for the following to actually be devices? (DMA, CPM, SI1, SIC2).
>>
> The good thing about them actually being devices is that you can find
> them and the IO resources had already been remapped. You don't need a
> device driver for them but they are resources used by other device
> drivers.
Not sure I follow. The IO resources are not mapped by anything until
some piece of code does an explicit ioremap(). How do you plan on
finding them? I've got now issue adding them, I just want to
understand how you see us using them. A simple code example might be
helpful.
>> I can provide feedback on all the issues I had with you patch, but
>> would
>> prefer to start with ours (let me know).
>>
> Comments:
> 1. You removed the other PRAM definition from this FCC definition, this
> is good.
>
> 2. I am torn about using numeric IMMR offsets vs. the structure member
> approach. The good thing is that you can create all the devices in a
> single table even if they overlay depending on processor. The question
> is, will the IMMAP structure become obsolete? If not, then you will
> still need the conditional compiles in immap_cpm2.h.
I'm trying to stay away from basing things on the structure. Since the
offsets are truly fixed I see not reason to try to make sure that the
immap structure is always correct for all cases. Hopefully this will
end up removing the need to ifdef the immap structure as we go forward.
> 3. Naming convention, are all these devices just in the MPC82xx family?
> If the CPM is a general FSL co-processor, used across many processor
> families, then I like the CPM2 naming convention.
The key there is the driver name not the enum name. If you look the
driver name field matches 85xx. These files might be better of called
pq2_* instead of mpc82xx_ (8240/1/5 is not handled here) or cpm2_ (85xx
has cpm2).
> 4. What about PCI?
What about it, none of the busses have specific drivers at this point
so they haven't been added.
> 5. This patch does not address the platform specific device structures.
> How do you want to handle these?
I want to do that as a second pass every we close on this. Since the
platform specific device structs are going to be based on what is
needed for the drivers.
- kumar
^ permalink raw reply
* [PATCH] ppc32: remove some unnecessary includes of prom.h
From: Kumar Gala @ 2005-06-15 4:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Fight the Good Fight: Limit prom.h header creep.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 4d829d08c1ae5ca5322435c71ffc45bc77917522
tree 0eeda2c7a188898bc484e3bb123e32e51e16cd4f
parent e970cbc91ac4e86f613e64c44010bcf76f6a2acc
author Kumar K. Gala <kumar.gala@freescale.com> Wed, 15 Jun 2005 00:41:23 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Wed, 15 Jun 2005 00:41:23 -0500
arch/ppc/platforms/83xx/mpc834x_sys.c | 1 -
arch/ppc/platforms/85xx/mpc8540_ads.c | 1 -
arch/ppc/platforms/85xx/mpc8560_ads.c | 1 -
arch/ppc/platforms/85xx/mpc85xx_ads_common.c | 1 -
arch/ppc/platforms/85xx/mpc85xx_cds_common.c | 1 -
arch/ppc/platforms/85xx/sbc8560.c | 1 -
arch/ppc/platforms/85xx/sbc85xx.c | 1 -
arch/ppc/platforms/85xx/stx_gp3.c | 1 -
arch/ppc/syslib/open_pic.c | 1 -
arch/ppc/syslib/open_pic2.c | 1 -
arch/ppc/syslib/ppc83xx_setup.c | 1 -
arch/ppc/syslib/ppc85xx_setup.c | 3 ++-
12 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -41,7 +41,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
#include <asm/ipic.h>
#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
diff --git a/arch/ppc/platforms/85xx/mpc8540_ads.c b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c
@@ -41,7 +41,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
#include <asm/open_pic.h>
#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
diff --git a/arch/ppc/platforms/85xx/mpc8560_ads.c b/arch/ppc/platforms/85xx/mpc8560_ads.c
--- a/arch/ppc/platforms/85xx/mpc8560_ads.c
+++ b/arch/ppc/platforms/85xx/mpc8560_ads.c
@@ -41,7 +41,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
#include <asm/open_pic.h>
#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
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
@@ -36,7 +36,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
#include <asm/open_pic.h>
#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
diff --git a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
@@ -42,7 +42,6 @@
#include <asm/todc.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
#include <asm/open_pic.h>
#include <asm/i8259.h>
#include <asm/bootinfo.h>
diff --git a/arch/ppc/platforms/85xx/sbc8560.c b/arch/ppc/platforms/85xx/sbc8560.c
--- a/arch/ppc/platforms/85xx/sbc8560.c
+++ b/arch/ppc/platforms/85xx/sbc8560.c
@@ -41,7 +41,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
#include <asm/open_pic.h>
#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
diff --git a/arch/ppc/platforms/85xx/sbc85xx.c b/arch/ppc/platforms/85xx/sbc85xx.c
--- a/arch/ppc/platforms/85xx/sbc85xx.c
+++ b/arch/ppc/platforms/85xx/sbc85xx.c
@@ -35,7 +35,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
#include <asm/open_pic.h>
#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
diff --git a/arch/ppc/platforms/85xx/stx_gp3.c b/arch/ppc/platforms/85xx/stx_gp3.c
--- a/arch/ppc/platforms/85xx/stx_gp3.c
+++ b/arch/ppc/platforms/85xx/stx_gp3.c
@@ -46,7 +46,6 @@
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
#include <asm/open_pic.h>
#include <asm/bootinfo.h>
#include <asm/pci-bridge.h>
diff --git a/arch/ppc/syslib/open_pic.c b/arch/ppc/syslib/open_pic.c
--- a/arch/ppc/syslib/open_pic.c
+++ b/arch/ppc/syslib/open_pic.c
@@ -21,7 +21,6 @@
#include <asm/signal.h>
#include <asm/io.h>
#include <asm/irq.h>
-#include <asm/prom.h>
#include <asm/sections.h>
#include <asm/open_pic.h>
#include <asm/i8259.h>
diff --git a/arch/ppc/syslib/open_pic2.c b/arch/ppc/syslib/open_pic2.c
--- a/arch/ppc/syslib/open_pic2.c
+++ b/arch/ppc/syslib/open_pic2.c
@@ -25,7 +25,6 @@
#include <asm/signal.h>
#include <asm/io.h>
#include <asm/irq.h>
-#include <asm/prom.h>
#include <asm/sections.h>
#include <asm/open_pic.h>
#include <asm/i8259.h>
diff --git a/arch/ppc/syslib/ppc83xx_setup.c b/arch/ppc/syslib/ppc83xx_setup.c
--- a/arch/ppc/syslib/ppc83xx_setup.c
+++ b/arch/ppc/syslib/ppc83xx_setup.c
@@ -23,7 +23,6 @@
#include <linux/serial_core.h>
#include <linux/serial_8250.h>
-#include <asm/prom.h>
#include <asm/time.h>
#include <asm/mpc83xx.h>
#include <asm/mmu.h>
diff --git a/arch/ppc/syslib/ppc85xx_setup.c b/arch/ppc/syslib/ppc85xx_setup.c
--- a/arch/ppc/syslib/ppc85xx_setup.c
+++ b/arch/ppc/syslib/ppc85xx_setup.c
@@ -23,7 +23,6 @@
#include <linux/serial_core.h>
#include <linux/serial_8250.h>
-#include <asm/prom.h>
#include <asm/time.h>
#include <asm/mpc85xx.h>
#include <asm/immap_85xx.h>
@@ -32,6 +31,8 @@
#include <asm/kgdb.h>
#include <syslib/ppc85xx_setup.h>
+
+extern void abort(void);
/* Return the amount of memory */
unsigned long __init
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Allen Curtis @ 2005-06-15 3:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0506142231040.2447@nylon.am.freescale.net>
> I've also included our version of this patch for commentary. Did you
> see a
> need for the following to actually be devices? (DMA, CPM, SI1, SIC2).
>
The good thing about them actually being devices is that you can find
them and the IO resources had already been remapped. You don't need a
device driver for them but they are resources used by other device
drivers.
> I can provide feedback on all the issues I had with you patch, but
> would
> prefer to start with ours (let me know).
>
Comments:
1. You removed the other PRAM definition from this FCC definition, this
is good.
2. I am torn about using numeric IMMR offsets vs. the structure member
approach. The good thing is that you can create all the devices in a
single table even if they overlay depending on processor. The question
is, will the IMMAP structure become obsolete? If not, then you will
still need the conditional compiles in immap_cpm2.h.
3. Naming convention, are all these devices just in the MPC82xx family?
If the CPM is a general FSL co-processor, used across many processor
families, then I like the CPM2 naming convention.
4. What about PCI?
5. This patch does not address the platform specific device structures.
How do you want to handle these?
Thanks for the patch, this helps.
> - kumar
>
>
> diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
> --- a/arch/ppc/syslib/Makefile
> +++ b/arch/ppc/syslib/Makefile
> @@ -80,7 +80,8 @@ obj-$(CONFIG_SANDPOINT) += i8259.o pci_
> obj-$(CONFIG_SBC82xx) += todc_time.o
> obj-$(CONFIG_SPRUCE) += cpc700_pic.o indirect_pci.o pci_auto.o \
> todc_time.o
> -obj-$(CONFIG_8260) += m8260_setup.o
> +obj-$(CONFIG_8260) += m8260_setup.o mpc82xx_devices.o mpc82xx_sys.o \
> + ppc_sys.o
> obj-$(CONFIG_PCI_8260) += m82xx_pci.o indirect_pci.o pci_auto.o
> obj-$(CONFIG_8260_PCI9) += m8260_pci_erratum9.o
> obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
> diff --git a/arch/ppc/syslib/mpc82xx_devices.c
> b/arch/ppc/syslib/mpc82xx_devices.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/ppc/syslib/mpc82xx_devices.c
> @@ -0,0 +1,389 @@
> +/*
> + * arch/ppc/syslib/mpc82xx_devices.c
> + *
> + * MPC82xx Device descriptions
> + *
> + * Maintainer: Kumar Gala <kumar.gala@freescale.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> License
> + * version 2. This program is licensed "as is" without any warranty
> of any
> + * kind, whether express or implied.
> + */
> +
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/ioport.h>
> +#include <asm/cpm2.h>
> +#include <asm/irq.h>
> +#include <asm/ppc_sys.h>
> +
> +struct platform_device ppc_sys_platform_devices[] = {
> + [MPC82xx_CPM_FCC1] = {
> + .name = "fsl-cpm-fcc",
> + .id = 1,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "fcc_regs",
> + .start = 0x11300,
> + .end = 0x1131f,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "fcc_pram",
> + .start = 0x8400,
> + .end = 0x84ff,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_FCC1,
> + .end = SIU_INT_FCC1,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_FCC2] = {
> + .name = "fsl-cpm-fcc",
> + .id = 2,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "fcc_regs",
> + .start = 0x11320,
> + .end = 0x1133f,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "fcc_pram",
> + .start = 0x8500,
> + .end = 0x85ff,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_FCC2,
> + .end = SIU_INT_FCC2,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_FCC3] = {
> + .name = "fsl-cpm-fcc",
> + .id = 3,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "fcc_regs",
> + .start = 0x11340,
> + .end = 0x1135f,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "fcc_pram",
> + .start = 0x8600,
> + .end = 0x86ff,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_FCC3,
> + .end = SIU_INT_FCC3,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_I2C] = {
> + .name = "fsl-cpm-i2c",
> + .id = 1,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "i2c_mem",
> + .start = 0x11860,
> + .end = 0x118BF,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "i2c_pram",
> + .start = 0x8afc,
> + .end = 0x8afd,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_I2C,
> + .end = SIU_INT_I2C,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_SCC1] = {
> + .name = "fsl-cpm-scc",
> + .id = 1,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "scc_mem",
> + .start = 0x11A00,
> + .end = 0x11A1F,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "scc_pram",
> + .start = 0x8000,
> + .end = 0x80ff,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_SCC1,
> + .end = SIU_INT_SCC1,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_SCC2] = {
> + .name = "fsl-cpm-scc",
> + .id = 2,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "scc_mem",
> + .start = 0x11A20,
> + .end = 0x11A3F,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "scc_pram",
> + .start = 0x8100,
> + .end = 0x81ff,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_SCC2,
> + .end = SIU_INT_SCC2,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_SCC3] = {
> + .name = "fsl-cpm-scc",
> + .id = 3,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "scc_mem",
> + .start = 0x11A40,
> + .end = 0x11A5F,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "scc_pram",
> + .start = 0x8200,
> + .end = 0x82ff,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_SCC3,
> + .end = SIU_INT_SCC3,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_SCC4] = {
> + .name = "fsl-cpm-scc",
> + .id = 4,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "scc_mem",
> + .start = 0x11A60,
> + .end = 0x11A7F,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "scc_pram",
> + .start = 0x8300,
> + .end = 0x83ff,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_SCC4,
> + .end = SIU_INT_SCC4,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_SPI] = {
> + .name = "fsl-cpm-spi",
> + .id = 1,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "spi_mem",
> + .start = 0x11AA0,
> + .end = 0x11AFF,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "spi_pram",
> + .start = 0x89fc,
> + .end = 0x89fd,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_SPI,
> + .end = SIU_INT_SPI,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_MCC1] = {
> + .name = "fsl-cpm-mcc",
> + .id = 1,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "mcc_mem",
> + .start = 0x11B30,
> + .end = 0x11B3F,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "mcc_pram",
> + .start = 0x8700,
> + .end = 0x877f,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_MCC1,
> + .end = SIU_INT_MCC1,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_MCC2] = {
> + .name = "fsl-cpm-mcc",
> + .id = 2,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "mcc_mem",
> + .start = 0x11B50,
> + .end = 0x11B5F,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "mcc_pram",
> + .start = 0x8800,
> + .end = 0x887f,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_MCC2,
> + .end = SIU_INT_MCC2,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_SMC1] = {
> + .name = "fsl-cpm-smc",
> + .id = 1,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "smc_mem",
> + .start = 0x11A80,
> + .end = 0x11A8F,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "smc_pram",
> + .start = 0x87fc,
> + .end = 0x87fd,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_SMC1,
> + .end = SIU_INT_SMC1,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_SMC2] = {
> + .name = "fsl-cpm-smc",
> + .id = 2,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "smc_mem",
> + .start = 0x11A90,
> + .end = 0x11A9F,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "smc_pram",
> + .start = 0x88fc,
> + .end = 0x88fd,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_SMC2,
> + .end = SIU_INT_SMC2,
> + .flags = IORESOURCE_IRQ,
> + },
> + },
> + },
> + [MPC82xx_CPM_USB] = {
> + .name = "fsl-cpm-usb",
> + .id = 1,
> + .num_resources = 3,
> + .resource = (struct resource[]) {
> + {
> + .name = "usb_mem",
> + .start = 0x11b60,
> + .end = 0x11b78,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "usb_pram",
> + .start = 0x8b00,
> + .end = 0x8bff,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = SIU_INT_USB,
> + .end = SIU_INT_USB,
> + .flags = IORESOURCE_IRQ,
> + },
> +
> + },
> + },
> + [MPC82xx_SEC1] = {
> + .name = "fsl-sec",
> + .id = 1,
> + .num_resources = 1,
> + .resource = (struct resource[]) {
> + {
> + .name = "sec_mem",
> + .start = 0x40000,
> + .end = 0x52fff,
> + .flags = IORESOURCE_MEM,
> + },
> + },
> + },
> +};
> +
> +static int __init mach_mpc82xx_fixup(struct platform_device *pdev)
> +{
> + ppc_sys_fixup_mem_resource(pdev, CPM_MAP_ADDR);
> + return 0;
> +}
> +
> +static int __init mach_mpc82xx_init(void)
> +{
> + if (ppc_md.progress)
> + ppc_md.progress("mach_mpc82xx_init:enter", 0);
> + ppc_sys_device_fixup = mach_mpc82xx_fixup;
> + return 0;
> +}
> +
> +postcore_initcall(mach_mpc82xx_init);
> diff --git a/arch/ppc/syslib/mpc82xx_sys.c
> b/arch/ppc/syslib/mpc82xx_sys.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/ppc/syslib/mpc82xx_sys.c
> @@ -0,0 +1,200 @@
> +/*
> + * arch/ppc/syslib/mpc82xx_devices.c
> + *
> + * MPC82xx System descriptions
> + *
> + * Maintainer: Kumar Gala <kumar.gala@freescale.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> License
> + * version 2. This program is licensed "as is" without any warranty
> of any
> + * kind, whether express or implied.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/device.h>
> +
> +#include <asm/ppc_sys.h>
> +
> +struct ppc_sys_spec *cur_ppc_sys_spec;
> +struct ppc_sys_spec ppc_sys_specs[] = {
> + /* below is a list of the 8260 family of processors */
> + {
> + .ppc_sys_name = "8250",
> + .mask = 0x0000ff00,
> + .value = 0x00000000,
> + .num_devices = 12,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> + MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> + MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + }
> + },
> + {
> + .ppc_sys_name = "8255",
> + .mask = 0x0000ff00,
> + .value = 0x00000000,
> + .num_devices = 11,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> + MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SCC4,
> + MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2,
> + MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + }
> + },
> + {
> + .ppc_sys_name = "8260",
> + .mask = 0x0000ff00,
> + .value = 0x00000000,
> + .num_devices = 12,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> + MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> + MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + }
> + },
> + {
> + .ppc_sys_name = "8264",
> + .mask = 0x0000ff00,
> + .value = 0x00000000,
> + .num_devices = 12,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> + MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> + MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + }
> + },
> + {
> + .ppc_sys_name = "8265",
> + .mask = 0x0000ff00,
> + .value = 0x00000000,
> + .num_devices = 12,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> + MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> + MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + }
> + },
> + {
> + .ppc_sys_name = "8266",
> + .mask = 0x0000ff00,
> + .value = 0x00000000,
> + .num_devices = 12,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> + MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> + MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + }
> + },
> + /* below is a list of the 8272 family of processors */
> + {
> + .ppc_sys_name = "8247",
> + .mask = 0x000fe000,
> + .value = 0x0000c000,
> + .num_devices = 10,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> + MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + MPC82xx_CPM_USB,
> + },
> + },
> + {
> + .ppc_sys_name = "8248",
> + .mask = 0x000fe000,
> + .value = 0x0000c000,
> + .num_devices = 11,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> + MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + MPC82xx_CPM_USB, MPC82xx_SEC1,
> + },
> + },
> + {
> + .ppc_sys_name = "8271",
> + .mask = 0x000fe000,
> + .value = 0x0000c000,
> + .num_devices = 10,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> + MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + MPC82xx_CPM_USB,
> + },
> + },
> + {
> + .ppc_sys_name = "8272",
> + .mask = 0x000fe000,
> + .value = 0x0000c000,
> + .num_devices = 11,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> + MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + MPC82xx_CPM_USB, MPC82xx_SEC1,
> + },
> + },
> + /* below is a list of the 8280 family of processors */
> + {
> + .ppc_sys_name = "8270",
> + .mask = 0x0000ff00,
> + .value = 0x00000a00,
> + .num_devices = 12,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> + MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> + MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + },
> + },
> + {
> + .ppc_sys_name = "8275",
> + .mask = 0x0000ff00,
> + .value = 0x00000a00,
> + .num_devices = 12,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> + MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> + MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> + },
> + },
> + {
> + .ppc_sys_name = "8280",
> + .mask = 0x0000ff00,
> + .value = 0x00000a00,
> + .num_devices = 13,
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> + MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> + MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_MCC2,
> + MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI,
> + MPC82xx_CPM_I2C,
> + },
> + },
> + {
> + /* default match */
> + .ppc_sys_name = "",
> + .mask = 0x00000000,
> + .value = 0x00000000,
> + },
> +};
> diff --git a/include/asm-ppc/irq.h b/include/asm-ppc/irq.h
> --- a/include/asm-ppc/irq.h
> +++ b/include/asm-ppc/irq.h
> @@ -331,6 +331,7 @@ static __inline__ int irq_canonicalize(i
> #define SIU_INT_IDMA3 ((uint)0x08 + CPM_IRQ_OFFSET)
> #define SIU_INT_IDMA4 ((uint)0x09 + CPM_IRQ_OFFSET)
> #define SIU_INT_SDMA ((uint)0x0a + CPM_IRQ_OFFSET)
> +#define SIU_INT_USB ((uint)0x0b + CPM_IRQ_OFFSET)
> #define SIU_INT_TIMER1 ((uint)0x0c + CPM_IRQ_OFFSET)
> #define SIU_INT_TIMER2 ((uint)0x0d + CPM_IRQ_OFFSET)
> #define SIU_INT_TIMER3 ((uint)0x0e + CPM_IRQ_OFFSET)
> diff --git a/include/asm-ppc/mpc8260.h b/include/asm-ppc/mpc8260.h
> --- a/include/asm-ppc/mpc8260.h
> +++ b/include/asm-ppc/mpc8260.h
> @@ -34,8 +34,7 @@
>
> #ifdef CONFIG_TQM8260
> #include <platforms/tqm8260.h>
> -#endif
> -
> +#endif
> #if defined(CONFIG_PQ2ADS) || defined (CONFIG_PQ2FADS)
> #include <platforms/pq2ads.h>
> #endif
> @@ -66,6 +65,24 @@
> #ifndef IO_VIRT_ADDR
> #define IO_VIRT_ADDR IO_PHYS_ADDR
> #endif
> +
> +enum ppc_sys_devices {
> + MPC82xx_CPM_FCC1,
> + MPC82xx_CPM_FCC2,
> + MPC82xx_CPM_FCC3,
> + MPC82xx_CPM_I2C,
> + MPC82xx_CPM_SCC1,
> + MPC82xx_CPM_SCC2,
> + MPC82xx_CPM_SCC3,
> + MPC82xx_CPM_SCC4,
> + MPC82xx_CPM_SPI,
> + MPC82xx_CPM_MCC1,
> + MPC82xx_CPM_MCC2,
> + MPC82xx_CPM_SMC1,
> + MPC82xx_CPM_SMC2,
> + MPC82xx_CPM_USB,
> + MPC82xx_SEC1,
> +};
>
> #ifndef __ASSEMBLY__
> /* The "residual" data board information structure the boot loader
> diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
> --- a/include/asm-ppc/ppc_sys.h
> +++ b/include/asm-ppc/ppc_sys.h
> @@ -21,7 +21,9 @@
> #include <linux/device.h>
> #include <linux/types.h>
>
> -#if defined(CONFIG_83xx)
> +#if defined(CONFIG_8260)
> +#include <asm/mpc8260.h>
> +#elif defined(CONFIG_83xx)
> #include <asm/mpc83xx.h>
> #elif defined(CONFIG_85xx)
> #include <asm/mpc85xx.h>
>
^ 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