* Re: [PATCH] ppc32: 8xx pq platform system descriptions
From: Dan Malek @ 2005-08-22 1:28 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <20050821235524.GE6746@dmt.cnet>
On Aug 21, 2005, at 7:55 PM, Marcelo Tosatti wrote:
> - Do you have any plans on actually using device model information by
> drivers (as was done in the mpc8xxx/gianfar) on m8xx? Its not very
> clear
> to me what are the the practical advantages of that?
It may be nice if we can do that. We have to be careful about sharing
CPM drivers between the 8xx and CPM2 (82xx/83xx/85xx). It's tempting,
but I still believe the differences outweigh the similarities. The
overhead
of trying to use common drivers would be quite costly on the 8xx.
> - I don't know whether its possible to retrieve 8xx CPUID information
> (if there is any). Can't find anything in the manual.
We really can't. The PVR only represents the processor core
information,
and for the most part they are all the same. It used to be we could use
the CPM microcode version, but these are now nearly the same. Some
attempts have been made to probe for CPM peripherals that don't exist,
but it seems on some parts the CPM is the same and the signals just
aren't
bonded out of the chip.
For the most part, the person doing the kernel configuration just simply
has to know what part they are using. You have to select the proper
peripherals, and you need the board support for the IO pin routing.
In an embedded environment where resources still need to be
carefully managed, I don't think this is unrealistic.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc32: 8xx pq platform system descriptions
From: Marcelo Tosatti @ 2005-08-21 23:55 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <43062C9D.5060703@ru.mvista.com>
On Fri, Aug 19, 2005 at 11:01:49PM +0400, Vitaly Bordug wrote:
> Added ppc_sys device and system definitions for PowerQUICC I devices.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> --
> Sincerely,
> Vitaly
Vitaly, Kumar,
Have a few questions:
- Do you have any plans on actually using device model information by
drivers (as was done in the mpc8xxx/gianfar) on m8xx? Its not very clear
to me what are the the practical advantages of that?
- I don't know whether its possible to retrieve 8xx CPUID information
(if there is any). Can't find anything in the manual.
^ permalink raw reply
* Re: [PATCH] cpm_uart: Fix dpram allocation and non-console uarts
From: Marcelo Tosatti @ 2005-08-21 21:12 UTC (permalink / raw)
To: Nish Aravamudan
Cc: Andrew Morton, Kumar Gala, linux-kernel, linuxppc-embedded
In-Reply-To: <29495f1d0508172242734e1c99@mail.gmail.com>
Hi,
On Wed, Aug 17, 2005 at 10:42:36PM -0700, Nish Aravamudan wrote:
> On 8/8/05, Kumar Gala <galak@freescale.com> wrote:
> > (A believe Marcelo would like to see this in 2.6.13, but I'll let him
> > fight over that ;)
> >
> > * Makes dpram allocations work
> > * Makes non-console UART work on both 8xx and 82xx
> > * Fixed whitespace in files that were touched
> >
> > Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> > Signed-off-by: Pantelis Antoniou <panto@intracom.gr>
> > Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
> >
> > ---
> > commit 1de80554bcae877dce3b6d878053eb092ef65c72
> > tree aba124824607fea1070e86501ddccc9decce362d
> > parent ad81111fd554c9d3c14c0a50885e076af2f9ac9b
> > author Kumar K. Gala <kumar.gala@freescale.com> Mon, 08 Aug 2005 22:35:39 -0500
> > committer Kumar K. Gala <kumar.gala@freescale.com> Mon, 08 Aug 2005 22:35:39 -0500
>
> <snip>
>
> > diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
> > --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> > +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
>
> <snip>
>
> > @@ -376,9 +396,19 @@ static int cpm_uart_startup(struct uart_
> > pinfo->sccp->scc_sccm |= UART_SCCM_RX;
> > }
> >
> > + if (!(pinfo->flags & FLAG_CONSOLE))
> > + cpm_line_cr_cmd(line,CPM_CR_INIT_TRX);
> > return 0;
> > }
> >
> > +inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
> > +{
> > + unsigned long target_jiffies = jiffies + pinfo->wait_closing;
> > +
> > + while (!time_after(jiffies, target_jiffies))
> > + schedule();
> > +}
>
> Not sure about that call here. Does the state need to be set so that
> you won't be run again immediately? In any case, I think direct
> schedule() callers are discouraged? Do you want to call a yield() or
> schedule_timeout({0,1}) instead maybe?
Yep, schedule_timeout(pinfo->wait_closing) looks much better.
> > /*
> > * Shutdown the uart
> > */
> > @@ -394,6 +424,12 @@ static void cpm_uart_shutdown(struct uar
> >
> > /* If the port is not the console, disable Rx and Tx. */
> > if (!(pinfo->flags & FLAG_CONSOLE)) {
> > + /* Wait for all the BDs marked sent */
> > + while(!cpm_uart_tx_empty(port))
> > + schedule_timeout(2);
>
> <snip>
>
> I think you are using 2 jiffies to guarantee that at least one jiffy
> elapses, which is fine. But, if you do not set the state beforehand,
> schedule_timeout() returns immediately, so you have a busy-wait here.
Right, what about the following untested patch.
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -403,10 +403,9 @@ static int cpm_uart_startup(struct uart_
inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
{
- unsigned long target_jiffies = jiffies + pinfo->wait_closing;
-
- while (!time_after(jiffies, target_jiffies))
- schedule();
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(pinfo->wait_closing);
+ set_current_state(TASK_RUNNING);
}
/*
@@ -425,9 +424,13 @@ static void cpm_uart_shutdown(struct uar
/* If the port is not the console, disable Rx and Tx. */
if (!(pinfo->flags & FLAG_CONSOLE)) {
/* Wait for all the BDs marked sent */
- while(!cpm_uart_tx_empty(port))
+ while(!cpm_uart_tx_empty(port)) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(2);
- if(pinfo->wait_closing)
+ }
+ set_current_state(TASK_RUNNING);
+
+ if (pinfo->wait_closing)
cpm_uart_wait_until_send(pinfo);
/* Stop uarts */
^ permalink raw reply
* Re: [PATCH] ppc32: Big-endian I/O memory accessors.
From: Benjamin Herrenschmidt @ 2005-08-21 21:22 UTC (permalink / raw)
To: Arthur Othieno; +Cc: linuxppc-dev
In-Reply-To: <20050821011649.GA31839@mars>
On Sat, 2005-08-20 at 21:16 -0400, Arthur Othieno wrote:
> I/O memory accessors. Big-endian version. For those busses/devices
> that do export big-endian I/O memory.
>
> Of notable relevance/reference:
>
> http://lwn.net/Articles/132804/
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019798.html
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019752.html
>
> Signed-Off-By: Arthur Othieno <a.othieno@bluewin.ch>
>
No, that's not correct. You need to use the in_be/out_be variants which
provide proper memory barriers.
Ben.
^ permalink raw reply
* Re: Linux Kernel MTD question
From: Wolfgang Denk @ 2005-08-21 20:58 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linuxppc-embedded
In-Reply-To: <20050821080936.DA55167F92@ozlabs.org>
In message <20050821080936.DA55167F92@ozlabs.org> you wrote:
>
> Just as I know, we can have many partitions for our flash if we turn on MTD
> in Kernel. For example:
Right.
> How could I distribute my RootFS into initrd1 and initrd2?
You cannot. The *root* filesystem is always just a single file system.
You can mount additional file systems on top of the directory
hierarchy provided by your root file system, but this is something
completely different.
> In U-Boot command, bootcmd, I set it to "bootm 40000 100000". 40000 is
> Kernel address, and 100000 is RootFS1 address. But where to set RootRS2
> address?
There are several errors in this text.
First, the kernel download address 0x40000 = 256kB is much too low
and can never work.
Second, the "100000" parameter is not a "RootFS1 address". It is the
start address of a ramdisk image. This may or may not be your root
file system, and it is usually NOT the address as seen by the kernel.
And, 100000 = 1 MB is a much too low address and can never work.
And finally: all this has absolutely NOTHING to do with MTD partitions.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Documentation is like sex: when it is good, it is very, very good;
and when it is bad, it is better than nothing. - Dick Brandon
^ permalink raw reply
* Re: segmentaion fault with array[4096]'
From: Marcelo Tosatti @ 2005-08-21 19:28 UTC (permalink / raw)
To: Studencki Pawel; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <291992F9ECD9AB4F995C7E96B9A30DC008E088@nbgh103a.nbg6.siemens.de>
On Fri, Aug 19, 2005 at 09:17:07AM +0200, Studencki Pawel wrote:
> hello,
>
> it is very strange, I found that SIGSEGV is generated in function
> do_page_fault() in arch/ppc/mm/fault.c
>
> ------------------------------------------------------------------
> int do_page_fault(struct pt_regs *regs, unsigned long address,
> unsigned long error_code)
> {
> struct vm_area_struct * vma;
> struct mm_struct *mm = current->mm;
> siginfo_t info;
> int code = SEGV_MAPERR;
> #if defined(CONFIG_4xx) || defined (CONFIG_BOOKE)
> int is_write = error_code & ESR_DST;
> #else
> int is_write = 0;
>
> /*
> * Fortunately the bit assignments in SRR1 for an instruction
> * fault and DSISR for a data fault are mostly the same for the
> * bits we are interested in. But there are some bits which
> * indicate errors in DSISR but can validly be set in SRR1.
> */
> // printk("fault bad_area is_write is NULL %x\n", regs->dsisr);
> if (TRAP(regs) == 0x400)
> error_code &= 0x48200000;
> else
> {
> // printk("fault bad_area is_write err = %x %x\n", error_code,
> TRAP(regs));
> is_write = error_code & 0x02000000;
> }
> #endif /* CONFIG_4xx || CONFIG_BOOKE */
> ---------------------------------------------------------------
>
>
> It is in DSI Exception, so it goes to "else" and sets is_write to value
> error_code & 0x02000000, where error_code is DSISR.
> it is better, when is_write != 0, because if it's NULL, a few lines below
> there
> is an "goto" to bad_area:
>
> if (!is_write)
> {
> goto bad_area;
> }
>
>
> and I get exception.
Sometimes is_write is set and sometimes it is not? Can you please be more
precise?
> At exception error_code is 0x4821, but in User Manual MPC866 in chapter
> 6.1.2.3
> in table 6-7, they write that bits 0-14 in DSISR are NULL. I'm confused and
> I don't know how should I interpret this.
You're looking at the wrong table, thats alignment exception. You should look
at data tlb error exception.
> Where does value 0x4821 come
> from??? most of the time it is 0x82000000...
It probably comes from
if (TRAP(regs) == 0x400)
error_code &= 0x48200000;
No?
I think you're just doing something wrong in your app.
Check what instruction resides where the invalid access is done (in your
application), which vma its trying to access, and you will figure out
what is going on.
^ permalink raw reply
* Re: How to map memory uncached on PPC.
From: Stephen Williams @ 2005-08-21 15:06 UTC (permalink / raw)
To: John W. Linville; +Cc: linuxppc-dev
In-Reply-To: <20050820180825.GG2736@tuxdriver.com>
John W. Linville wrote:
> On Sat, Aug 20, 2005 at 08:59:42AM -0700, Stephen Williams wrote:
>>I did an even simpler experiment: I commented out the pci_map_single,
>>which on a PPC only has the effect of calling invalidate_dcache_range
>>and returning the virt_to_bus of the address. Obviously, the cache
>>is still enabled for the processor, and the image data may get
>>corrupted, but this was a performance test, not a solution.
>
>
> If your purpose is to evaluate performance, doesn't having the cache
> enabled limit the usefulness of your test? For example if your cache
> uses a write-back policy then your test will probably outperform the
> actual uncached accesses. YMMV, I suppose...
No, it shouldn't. The setup is a driver for a PCI device that masters
its output to the buffer in question. What I'm measuring is not the
time to write the buffer (which is being done by the hardware, so
bypasses the cache anyhow) but the time it takes to *prepare the
buffer for the device*. The buffer is not written to or read from
by device or processor during this time, but it is mapped and DMA
pointers are collected. Also, the pci_map_single invalidates the cache
by walking through the entire buffer (many megabytes) with this loop
from invalidate_dcache_range:
1: dcbi 0,r3
addi r3,r3,L1_CACHE_LINE_SIZE
bdnz 1b
sync /* wait for dcbi's to get to ram */
This is what I believe is taking a long time.
Since nothing is touching that buffer during my test, and I'm mostly
dropping that code, I believe my test is valid.
--
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."
^ permalink raw reply
* Linux Kernel MTD question
From: JohnsonCheng @ 2005-08-21 8:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Dear All,
Just as I know, we can have many partitions for our flash if we turn on MTD
in Kernel. For example:
0x00000000-0x00040000: u-boot
0x00040000-0x00100000: kernel
0x00100000-0x00200000: inirid1
0x00200000-0x00400000: initrd2
How could I distribute my RootFS into initrd1 and initrd2?
In U-Boot command, bootcmd, I set it to "bootm 40000 100000". 40000 is
Kernel address, and 100000 is RootFS1 address. But where to set RootRS2
address?
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 4224 bytes --]
^ permalink raw reply
* [PATCH] ppc32: Big-endian I/O memory accessors.
From: Arthur Othieno @ 2005-08-21 1:16 UTC (permalink / raw)
To: linuxppc-dev
I/O memory accessors. Big-endian version. For those busses/devices
that do export big-endian I/O memory.
Of notable relevance/reference:
http://lwn.net/Articles/132804/
http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019798.html
http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019752.html
Signed-Off-By: Arthur Othieno <a.othieno@bluewin.ch>
io.h | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+)
--- a/include/asm-ppc/io.h 2005-08-20 19:24:40.000000000 -0400
+++ b/include/asm-ppc/io.h 2005-08-20 20:18:03.000000000 -0400
@@ -487,11 +487,21 @@
return readw(addr);
}
+static inline unsigned int ioread16be(void __iomem *addr)
+{
+ return __raw_readw(addr);
+}
+
static inline unsigned int ioread32(void __iomem *addr)
{
return readl(addr);
}
+static inline unsigned int ioread32be(void __iomem *addr)
+{
+ return __raw_readl(addr);
+}
+
static inline void iowrite8(u8 val, void __iomem *addr)
{
writeb(val, addr);
@@ -502,11 +512,21 @@
writew(val, addr);
}
+static inline void iowrite16be(u16 val, void __iomem *addr)
+{
+ __raw_writew(val, addr);
+}
+
static inline void iowrite32(u32 val, void __iomem *addr)
{
writel(val, addr);
}
+static inline void iowrite32be(u32 val, void __iomem *addr)
+{
+ __raw_writel(val, addr);
+}
+
static inline void ioread8_rep(void __iomem *addr, void *dst, unsigned long count)
{
_insb(addr, dst, count);
^ permalink raw reply
* Re: How to map memory uncached on PPC.
From: John W. Linville @ 2005-08-20 18:08 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-dev
In-Reply-To: <4307536E.4070800@icarus.com>
On Sat, Aug 20, 2005 at 08:59:42AM -0700, Stephen Williams wrote:
> Benjamin Herrenschmidt wrote:
> >A simple experiment you can do is limit the memory used by the kernel
> >(booting with mem=xxxx) and then use mmap of /dev/mem to map the
> >remaining memory like if it was an IO device, uncached. With that, you
> >get a quick hack solution to validate the performance benefit at least.
>
> I did an even simpler experiment: I commented out the pci_map_single,
> which on a PPC only has the effect of calling invalidate_dcache_range
> and returning the virt_to_bus of the address. Obviously, the cache
> is still enabled for the processor, and the image data may get
> corrupted, but this was a performance test, not a solution.
If your purpose is to evaluate performance, doesn't having the cache
enabled limit the usefulness of your test? For example if your cache
uses a write-back policy then your test will probably outperform the
actual uncached accesses. YMMV, I suppose...
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: How to map memory uncached on PPC.
From: Stephen Williams @ 2005-08-20 15:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1124499963.5197.99.camel@gaston>
Benjamin Herrenschmidt wrote:
> On Fri, 2005-08-19 at 08:17 -0700, Stephen Williams wrote:
>>I did some measurements, at it seems that the vast amount of
>>the time is spent in pci_map_single, which calls only the
>>consistent_sync function, which for FROMDEVICE calls only
>>invalidate_dcache_range. So I'm convinced that invalidating
>>the cache for the output buffer (which is large, in case the
>>image that arrives is large) is taking most of the time. So
>>I want to eliminate it.
> A simple experiment you can do is limit the memory used by the kernel
> (booting with mem=xxxx) and then use mmap of /dev/mem to map the
> remaining memory like if it was an IO device, uncached. With that, you
> get a quick hack solution to validate the performance benefit at least.
I did an even simpler experiment: I commented out the pci_map_single,
which on a PPC only has the effect of calling invalidate_dcache_range
and returning the virt_to_bus of the address. Obviously, the cache
is still enabled for the processor, and the image data may get
corrupted, but this was a performance test, not a solution.
Your "test" is a not implausible solution, although it has for me
some administrative problems.
--
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."
^ permalink raw reply
* [PATCH] ppc32: fix Bamboo and Luan build warnings
From: Eugene Surovegin @ 2005-08-20 7:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Fix STD_UART_OP definitions in Bamboo and Luan board ports which
were causing "initialization makes pointer from integer without a
cast" warnings.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
diff --git a/arch/ppc/platforms/4xx/bamboo.h b/arch/ppc/platforms/4xx/bamboo.h
--- a/arch/ppc/platforms/4xx/bamboo.h
+++ b/arch/ppc/platforms/4xx/bamboo.h
@@ -88,7 +88,7 @@
#define STD_UART_OP(num) \
{ 0, BASE_BAUD, 0, UART##num##_INT, \
(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST), \
- iomem_base: UART##num##_IO_BASE, \
+ iomem_base: (void*)UART##num##_IO_BASE, \
io_type: SERIAL_IO_MEM},
#define SERIAL_PORT_DFNS \
diff --git a/arch/ppc/platforms/4xx/luan.h b/arch/ppc/platforms/4xx/luan.h
--- a/arch/ppc/platforms/4xx/luan.h
+++ b/arch/ppc/platforms/4xx/luan.h
@@ -55,7 +55,7 @@
#define STD_UART_OP(num) \
{ 0, BASE_BAUD, 0, UART##num##_INT, \
(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST), \
- iomem_base: UART##num##_IO_BASE, \
+ iomem_base: (void*)UART##num##_IO_BASE, \
io_type: SERIAL_IO_MEM},
#define SERIAL_PORT_DFNS \
^ permalink raw reply
* [PATCH] ppc32: fix EMAC Tx channel assignments for NPe405H
From: Eugene Surovegin @ 2005-08-20 2:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Fix PowerPC NPe405H EMAC Tx channel assignments. EMAC unit in this
chip uses common for 4xx "two Tx / one Rx" configuration.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
diff --git a/arch/ppc/platforms/4xx/ibmnp405h.c b/arch/ppc/platforms/4xx/ibmnp405h.c
--- a/arch/ppc/platforms/4xx/ibmnp405h.c
+++ b/arch/ppc/platforms/4xx/ibmnp405h.c
@@ -34,7 +34,7 @@ static struct ocp_func_emac_data ibmnp40
.zmii_mux = 1, /* ZMII input of this EMAC */
.mal_idx = 0, /* MAL device index */
.mal_rx_chan = 1, /* MAL rx channel number */
- .mal_tx_chan = 1, /* MAL tx channel number */
+ .mal_tx_chan = 2, /* MAL tx channel number */
.wol_irq = 41, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx = -1, /* No TAH */
@@ -46,7 +46,7 @@ static struct ocp_func_emac_data ibmnp40
.zmii_mux = 2, /* ZMII input of this EMAC */
.mal_idx = 0, /* MAL device index */
.mal_rx_chan = 2, /* MAL rx channel number */
- .mal_tx_chan = 2, /* MAL tx channel number */
+ .mal_tx_chan = 4, /* MAL tx channel number */
.wol_irq = 41, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx = -1, /* No TAH */
@@ -58,7 +58,7 @@ static struct ocp_func_emac_data ibmnp40
.zmii_mux = 3, /* ZMII input of this EMAC */
.mal_idx = 0, /* MAL device index */
.mal_rx_chan = 3, /* MAL rx channel number */
- .mal_tx_chan = 3, /* MAL tx channel number */
+ .mal_tx_chan = 6, /* MAL tx channel number */
.wol_irq = 41, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx = -1, /* No TAH */
^ permalink raw reply
* Re: How to map memory uncached on PPC.
From: Benjamin Herrenschmidt @ 2005-08-20 1:06 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-dev
In-Reply-To: <4305F7FE.7040709@icarus.com>
On Fri, 2005-08-19 at 08:17 -0700, Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> My setup is Linux PPC kernel 2.4.30 on an embedded PPC405BPr.
> The board has some image processing devices including compressors.
> I'm working with high image rates so performance is a issue.
>
> The drivers for the pci based compressor chips support readv
> and use map_user_kiobuf and pci_map_single to map the output
> buffers for the read. (The devices do scatter DMA.) This is
> too slow, though. More time is spent mapping then compressing!
>
> I did some measurements, at it seems that the vast amount of
> the time is spent in pci_map_single, which calls only the
> consistent_sync function, which for FROMDEVICE calls only
> invalidate_dcache_range. So I'm convinced that invalidating
> the cache for the output buffer (which is large, in case the
> image that arrives is large) is taking most of the time. So
> I want to eliminate it.
>
> And the way I want to do that is to have a heap of memory in
> the user-mode process mapped uncached. The hope is that I can
> pass that through the readv to the driver, which sets up the
> DMA. Then I can skip the pci_map_single (and the thus the
> invalidate_dcache_range) thus saving lots of time.
>
> Plan-B would be to have a driver allocate the heap of memory,
> but I really need the mapping into user mode to be uncached,
> as the processor does some final touch up (header et al) before
> sending it to the next device.
A simple experiment you can do is limit the memory used by the kernel
(booting with mem=xxxx) and then use mmap of /dev/mem to map the
remaining memory like if it was an IO device, uncached. With that, you
get a quick hack solution to validate the performance benefit at least.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc32: 8xx pq platform system descriptions
From: Kumar Gala @ 2005-08-19 20:14 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <43062C9D.5060703@ru.mvista.com>
+/* access ports */
+#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) |
(_v))
+#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~
(_v))
+
+#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) |
(_v))
+#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~
(_v))
+
Needs to go.
+#define MPC8xx_INT_FEC1 SIU_LEVEL1
+#define MPC8xx_INT_FEC2 SIU_LEVEL3
+
+#define MPC8xx_INT_SCC1 (CPM_IRQ_OFFSET + CPMVEC_SCC1)
+#define MPC8xx_INT_SCC2 (CPM_IRQ_OFFSET + CPMVEC_SCC2)
+#define MPC8xx_INT_SCC3 (CPM_IRQ_OFFSET + CPMVEC_SCC3)
+#define MPC8xx_INT_SCC4 (CPM_IRQ_OFFSET + CPMVEC_SCC4)
+#define MPC8xx_INT_SMC1 (CPM_IRQ_OFFSET + CPMVEC_SMC1)
+#define MPC8xx_INT_SMC2 (CPM_IRQ_OFFSET + CPMVEC_SMC2)
Marcelo, we should look at what effect moving CPMVEC_* out of
commproc.h into irq.h and cleaning things up has on the world.
- kumar
On Aug 19, 2005, at 2:01 PM, Vitaly Bordug wrote:
> Added ppc_sys device and system definitions for PowerQUICC I devices.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> --
> Sincerely,
> Vitaly
>
> <8xx_plats.diff>
> <ATT292304.txt>
>
^ permalink raw reply
* Re: How to build more than 16M ramdisk for u-boot
From: Grant Likely @ 2005-08-19 20:06 UTC (permalink / raw)
To: ???, linuxppc-embedded
In-Reply-To: <001401c5a494$ffd659c0$1a0e000a@RoberHsu>
On Fri, Aug 19, 2005 at 04:07:04PM +0800, ??? wrote:
> Hi Grant:
>
> I'm already try it.But it still fail.Why i used so large ramdisk, is
> because net-snmp 5.x.x
> are too big, snmpd + snmptrapd almost 10M byte.
I think you're missunderstanding me.
"/sbin/mke2fs -F m0 ramdisk" means:
create ext2 filesystem on file 'm0' of size 'ramdisk'
"/sbin/mke2fs -F -m0 ramdisk" means:
create ext2 filesystem on file 'ramdisk' with 0% reserved
It looks like your missing a dash (-) for the 'm' option
g.
^ permalink raw reply
* SIGFPE on 8245
From: Andy G. @ 2005-08-19 19:40 UTC (permalink / raw)
To: linuxppc-embedded
I'm working with a rather large multi-threaded application that after
a several hour run will often produce a floating point exception
(specifically a divide by zero exception). I've manged to catch the
signal and use some home grown code to examine the current state of
the running thread as well as all of the others, but sadly this debug
information never provides any valuable information. It appears as
though the crash is happening in the pthread library when trying to
execute a floating point store instruction (0x8114 listed below).
00008108 <__pthread_timedsuspend_new>:
8108: 7d 80 00 26 mfcr r12
810c: 94 21 fc 90 stwu r1,-880(r1)
8110: 7c 08 02 a6 mflr r0 =
=20
8114: d9 c1 02 e0 stfd f14,736(r1) <--- SIGFPE happens here =
=20
After looking over the 32-bit PPC Programming Env Manual it seems to
me that the floating point operations that result in +/- infinity will
disable the FPU and write the FPECR with the cause. Next time a
floating point instruction is attempted we will get an exception since
the FPU is disabled and then we will throw the exception.
This information unfortunately tells me that I have to start digging
through the source code to find the programming error, but I'm hoping
I'm wrong about this. Any advice or tips?
Thanks in advance,
-andy
^ permalink raw reply
* [PATCH] ppc32: 8xx pq platform system descriptions
From: Vitaly Bordug @ 2005-08-19 19:01 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Kumar Gala, linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 146 bytes --]
Added ppc_sys device and system definitions for PowerQUICC I devices.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: 8xx_plats.diff --]
[-- Type: text/x-patch, Size: 8911 bytes --]
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -34,7 +34,8 @@ ifeq ($(CONFIG_40x),y)
obj-$(CONFIG_PCI) += indirect_pci.o pci_auto.o ppc405_pci.o
endif
endif
-obj-$(CONFIG_8xx) += m8xx_setup.o ppc8xx_pic.o $(wdt-mpc8xx-y)
+obj-$(CONFIG_8xx) += m8xx_setup.o ppc8xx_pic.o $(wdt-mpc8xx-y) \
+ ppc_sys.o mpc8xx_devices.o mpc8xx_sys.o
ifeq ($(CONFIG_8xx),y)
obj-$(CONFIG_PCI) += qspan_pci.o i8259.o
endif
diff --git a/arch/ppc/syslib/mpc8xx_devices.c b/arch/ppc/syslib/mpc8xx_devices.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/syslib/mpc8xx_devices.c
@@ -0,0 +1,231 @@
+/*
+ * arch/ppc/syslib/mpc8xx_devices.c
+ *
+ * MPC8xx Device descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 MontaVista Software, Inc. by Vitaly Bordug<vbordug@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; 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/serial_8250.h>
+#include <linux/mii.h>
+#include <asm/commproc.h>
+#include <asm/mpc8xx.h>
+#include <asm/irq.h>
+#include <asm/ppc_sys.h>
+
+/* access ports */
+#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) | (_v))
+#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~(_v))
+
+#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) | (_v))
+#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~(_v))
+
+/* We use offsets for IORESOURCE_MEM to do not set dependences at compile time.
+ * They will get fixed up by mach_mpc8xx_fixup
+ */
+
+struct platform_device ppc_sys_platform_devices[] = {
+ [MPC8xx_CPM_FEC1] = {
+ .name = "fsl-cpm-fec",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .name = "regs",
+ .start = 0xe00,
+ .end = 0xe88,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "interrupt",
+ .start = MPC8xx_INT_FEC1,
+ .end = MPC8xx_INT_FEC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC8xx_CPM_FEC2] = {
+ .name = "fsl-cpm-fec",
+ .id = 2,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .name = "regs",
+ .start = 0x1e00,
+ .end = 0x1e88,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "interrupt",
+ .start = MPC8xx_INT_FEC2,
+ .end = MPC8xx_INT_FEC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC8xx_CPM_SCC1] = {
+ .name = "fsl-cpm-scc",
+ .id = 1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "regs",
+ .start = 0xa00,
+ .end = 0xa18,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "pram",
+ .start = 0x3c00,
+ .end = 0x3c80,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "interrupt",
+ .start = MPC8xx_INT_SCC1,
+ .end = MPC8xx_INT_SCC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC8xx_CPM_SCC2] = {
+ .name = "fsl-cpm-scc",
+ .id = 2,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "regs",
+ .start = 0xa20,
+ .end = 0xa38,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "pram",
+ .start = 0x3d00,
+ .end = 0x3d80,
+ .flags = IORESOURCE_MEM,
+ },
+
+ {
+ .name = "interrupt",
+ .start = MPC8xx_INT_SCC2,
+ .end = MPC8xx_INT_SCC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC8xx_CPM_SCC3] = {
+ .name = "fsl-cpm-scc",
+ .id = 3,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "regs",
+ .start = 0xa40,
+ .end = 0xa58,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "pram",
+ .start = 0x3e00,
+ .end = 0x3e80,
+ .flags = IORESOURCE_MEM,
+ },
+
+ {
+ .name = "interrupt",
+ .start = MPC8xx_INT_SCC3,
+ .end = MPC8xx_INT_SCC3,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC8xx_CPM_SCC4] = {
+ .name = "fsl-cpm-scc",
+ .id = 4,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "regs",
+ .start = 0xa60,
+ .end = 0xa78,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "pram",
+ .start = 0x3f00,
+ .end = 0x3f80,
+ .flags = IORESOURCE_MEM,
+ },
+
+ {
+ .name = "interrupt",
+ .start = MPC8xx_INT_SCC4,
+ .end = MPC8xx_INT_SCC4,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC8xx_CPM_SMC1] = {
+ .name = "fsl-cpm-smc",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .name = "regs",
+ .start = 0xa82,
+ .end = 0xa91,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "interrupt",
+ .start = MPC8xx_INT_SMC1,
+ .end = MPC8xx_INT_SMC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC8xx_CPM_SMC2] = {
+ .name = "fsl-cpm-smc",
+ .id = 2,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .name = "regs",
+ .start = 0xa92,
+ .end = 0xaa1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "interrupt",
+ .start = MPC8xx_INT_SMC2,
+ .end = MPC8xx_INT_SMC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+};
+
+static int __init mach_mpc8xx_fixup(struct platform_device *pdev)
+{
+ ppc_sys_fixup_mem_resource (pdev, IMAP_ADDR);
+ return 0;
+}
+
+static int __init mach_mpc8xx_init(void)
+{
+ ppc_sys_device_fixup = mach_mpc8xx_fixup;
+ return 0;
+}
+
+postcore_initcall(mach_mpc8xx_init);
diff --git a/arch/ppc/syslib/mpc8xx_sys.c b/arch/ppc/syslib/mpc8xx_sys.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/syslib/mpc8xx_sys.c
@@ -0,0 +1,61 @@
+/*
+ * arch/ppc/platforms/mpc8xx_sys.c
+ *
+ * MPC8xx System descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 MontaVista Software, Inc. by Vitaly Bordug <vbordug@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; 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 <asm/ppc_sys.h>
+
+struct ppc_sys_spec *cur_ppc_sys_spec;
+struct ppc_sys_spec ppc_sys_specs[] = {
+ {
+ .ppc_sys_name = "MPC86X",
+ .mask = 0xFFFFFFFF,
+ .value = 0x00000000,
+ .num_devices = 2,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC8xx_CPM_FEC1,
+ MPC8xx_CPM_SCC1,
+ MPC8xx_CPM_SCC2,
+ MPC8xx_CPM_SCC3,
+ MPC8xx_CPM_SCC4,
+ MPC8xx_CPM_SMC1,
+ MPC8xx_CPM_SMC2,
+ },
+ },
+ {
+ .ppc_sys_name = "MPC885",
+ .mask = 0xFFFFFFFF,
+ .value = 0x00000000,
+ .num_devices = 3,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC8xx_CPM_FEC1,
+ MPC8xx_CPM_FEC2,
+ MPC8xx_CPM_SCC1,
+ MPC8xx_CPM_SCC2,
+ MPC8xx_CPM_SCC3,
+ MPC8xx_CPM_SCC4,
+ MPC8xx_CPM_SMC1,
+ MPC8xx_CPM_SMC2,
+ },
+ },
+ { /* 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
@@ -133,6 +133,16 @@ irq_canonicalize(int irq)
#define SIU_IRQ7 (14)
#define SIU_LEVEL7 (15)
+#define MPC8xx_INT_FEC1 SIU_LEVEL1
+#define MPC8xx_INT_FEC2 SIU_LEVEL3
+
+#define MPC8xx_INT_SCC1 (CPM_IRQ_OFFSET + CPMVEC_SCC1)
+#define MPC8xx_INT_SCC2 (CPM_IRQ_OFFSET + CPMVEC_SCC2)
+#define MPC8xx_INT_SCC3 (CPM_IRQ_OFFSET + CPMVEC_SCC3)
+#define MPC8xx_INT_SCC4 (CPM_IRQ_OFFSET + CPMVEC_SCC4)
+#define MPC8xx_INT_SMC1 (CPM_IRQ_OFFSET + CPMVEC_SMC1)
+#define MPC8xx_INT_SMC2 (CPM_IRQ_OFFSET + CPMVEC_SMC2)
+
/* The internal interrupts we can configure as we see fit.
* My personal preference is CPM at level 2, which puts it above the
* MBX PCI/ISA/IDE interrupts.
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -101,6 +101,22 @@ extern unsigned char __res[];
struct pt_regs;
+enum ppc_sys_devices {
+ MPC8xx_CPM_FEC1,
+ MPC8xx_CPM_FEC2,
+ MPC8xx_CPM_I2C,
+ MPC8xx_CPM_SCC1,
+ MPC8xx_CPM_SCC2,
+ MPC8xx_CPM_SCC3,
+ MPC8xx_CPM_SCC4,
+ MPC8xx_CPM_SPI,
+ MPC8xx_CPM_MCC1,
+ MPC8xx_CPM_MCC2,
+ MPC8xx_CPM_SMC1,
+ MPC8xx_CPM_SMC2,
+ MPC8xx_CPM_USB,
+};
+
#endif /* !__ASSEMBLY__ */
#endif /* CONFIG_8xx */
#endif /* __CONFIG_8xx_DEFS */
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
@@ -25,6 +25,8 @@
#include <asm/mpc83xx.h>
#elif defined(CONFIG_85xx)
#include <asm/mpc85xx.h>
+#elif defined(CONFIG_8xx)
+#include <asm/mpc8xx.h>
#elif defined(CONFIG_PPC_MPC52xx)
#include <asm/mpc52xx.h>
#elif defined(CONFIG_MPC10X_BRIDGE)
^ permalink raw reply
* NO_CACHE and mmaped pages
From: Stephen Williams @ 2005-08-19 18:44 UTC (permalink / raw)
To: linuxppc-embedded
I think the answer is "Yes", but I want to get a second opinion.
I need memory that is mapped into user space (so that I can manage
it as a BIG heap) but is not cached by the CPU, a PPC405GPr running
kernel 2.4.30something.
A possible solution is to in my driver support mmap and implement the
nopage function. The pages that I create in the nopage will be allocated
by the consistent_alloc function, which returns pages marked as NO_CACHE,
and so should be uncached.
The question is, "Is this NO_CACHE status/flag preserved when it is
mapped into the user address space? So far as I can see browsing the
do_no_page function in memory.c, that bit is indeed preserved in the
mapping. Am I right?
Alternatively, is there a way to change a region of memory no
unpaged, a la mlock for locking pages? I would rather not keep a
table of page pointers for 256Meg of memory just so I can do a
consistent_free later:-(
--
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."
^ permalink raw reply
* Re: 8272ADS and Linux 2.6.12
From: Matthew McClintock @ 2005-08-19 16:42 UTC (permalink / raw)
To: SIP COP 009; +Cc: linuxppc-embedded
In-Reply-To: <5a4792c005071910184f41c699@mail.gmail.com>
On Tue, 2005-07-19 at 10:18 -0700, SIP COP 009 wrote:
> Thanks all for the replies and help. I have the 2.6 Kernel running
> now. Here are few of the things that i did to make it happen:
>
> 1: make ads8272_defconfig
> 2: edit .config to add the follow:
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_SERIAL_CPM=y
> CONFIG_SERIAL_CPM_CONSOLE=y
> CONFIG_SERIAL_CPM_SCC1=y
> CONFIG_SERIAL_CPM_SCC2=y
Are you sure it should not be SCC1 and SCC4? Can you verify SCC2 works
for you?
-Matthew
^ permalink raw reply
* How to map memory uncached on PPC
From: Stephen Williams @ 2005-08-19 16:18 UTC (permalink / raw)
To: linuxppc-embedded
My setup is Linux PPC kernel 2.4.30 on an embedded PPC405GPr.
The board has some image processing devices including compressors.
I'm working with high image rates so performance is an issue.
The drivers for the pci based compressor chips support readv
and use map_user_kiobuf and pci_map_single to map the output
buffers for the read. (The devices do scatter DMA.) This is
too slow, though. More time is spent mapping then compressing!
I did some measurements, at it seems that the vast amount of
the time is spent in pci_map_single, which calls only the
consistent_sync function, which for FROMDEVICE calls only
invalidate_dcache_range. So I'm convinced that invalidating
the cache for the output buffer (which is large, in case the
image that arrives is large) is taking most of the time. So
I want to eliminate it.
And the way I want to do that is to have a heap of memory in
the user-mode process mapped uncached. The hope is that I can
pass that through the readv to the driver, which sets up the
DMA. Then I can skip the pci_map_single (and the thus the
invalidate_dcache_range) thus saving lots of time.
Plan-B would be to have a driver allocate the heap of memory,
but I really need the mapping into user mode to be uncached,
as the processor does some final touch up (header et al) before
sending it to the next device.
--
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."
^ permalink raw reply
* How to map memory uncached on PPC.
From: Stephen Williams @ 2005-08-19 15:17 UTC (permalink / raw)
To: linuxppc-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
My setup is Linux PPC kernel 2.4.30 on an embedded PPC405BPr.
The board has some image processing devices including compressors.
I'm working with high image rates so performance is a issue.
The drivers for the pci based compressor chips support readv
and use map_user_kiobuf and pci_map_single to map the output
buffers for the read. (The devices do scatter DMA.) This is
too slow, though. More time is spent mapping then compressing!
I did some measurements, at it seems that the vast amount of
the time is spent in pci_map_single, which calls only the
consistent_sync function, which for FROMDEVICE calls only
invalidate_dcache_range. So I'm convinced that invalidating
the cache for the output buffer (which is large, in case the
image that arrives is large) is taking most of the time. So
I want to eliminate it.
And the way I want to do that is to have a heap of memory in
the user-mode process mapped uncached. The hope is that I can
pass that through the readv to the driver, which sets up the
DMA. Then I can skip the pci_map_single (and the thus the
invalidate_dcache_range) thus saving lots of time.
Plan-B would be to have a driver allocate the heap of memory,
but I really need the mapping into user mode to be uncached,
as the processor does some final touch up (header et al) before
sending it to the next device.
- --
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.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDBff9rPt1Sc2b3ikRApayAKDboAm10TN8kN3XLtNOFvoYYC/xNwCgx3Nw
ZyHhUzk3xC8/EMBxLD8odtk=
=QrII
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC][PATCH] [1/2] 8xx platform definitions
From: Vitaly Bordug @ 2005-08-19 15:12 UTC (permalink / raw)
To: Dan Malek; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <6c1a48b29ad7e3d4c7f830f14ee7333d@embeddededge.com>
Dan Malek wrote:
>
> On Aug 19, 2005, at 8:44 AM, Vitaly Bordug wrote:
>
>> +#define MPC8xx_INT_FEC1 SIU_LEVEL1
>> +#define MPC8xx_INT_FEC2 SIU_LEVEL3
>> +
>> +#define MPC8xx_INT_SCC1 (CPM_IRQ_OFFSET + CPMVEC_SCC1)
>> +#define MPC8xx_INT_SCC2 (CPM_IRQ_OFFSET + CPMVEC_SCC2)
>> +#define MPC8xx_INT_SCC3 (CPM_IRQ_OFFSET + CPMVEC_SCC3)
>> +#define MPC8xx_INT_SCC4 (CPM_IRQ_OFFSET + CPMVEC_SCC4)
>> +#define MPC8xx_INT_SMC1 (CPM_IRQ_OFFSET + CPMVEC_SMC1)
>> +#define MPC8xx_INT_SMC2 (CPM_IRQ_OFFSET + CPMVEC_SMC2)
>> +
>> +/* Offset from IMMAP base address */
>> +#define MPC8xx_SCC1_OFFSET (0xa00)
>> +#define MPC8xx_SCC1_SIZE (0x18)
>> +#define MPC8xx_SCC2_OFFSET (0xa20)
>> +#define MPC8xx_SCC2_SIZE (0x18)
>> +#define MPC8xx_SCC3_OFFSET (0xa40)
>> +#define MPC8xx_SCC3_SIZE (0x18)
>> +#define MPC8xx_SCC4_OFFSET (0xa60)
>> +#define MPC8xx_SCC4_SIZE (0x18)
>> +#define MPC8xx_SMC1_OFFSET (0xa82)
>> +#define MPC8xx_SMC1_SIZE (0x0f)
>> +#define MPC8xx_SMC2_OFFSET (0xa92)
>> +#define MPC8xx_SMC2_SIZE (0x0d)
>> +#define MPC8xx_FEC1_OFFSET (0xe00)
>> +#define MPC8xx_FEC1_SIZE (0x88)
>> +#define MPC8xx_FEC2_OFFSET (0x1e00)
>> +#define MPC8xx_FEC2_SIZE (0x88)
>> +
>> +#define MPC8xx_DPARAM_SCC1_OFFSET (0x3C00)
>> +#define MPC8xx_DPARAM_SCC1_SIZE (0x80)
>> +#define MPC8xx_DPARAM_SCC2_OFFSET (0x3D00)
>> +#define MPC8xx_DPARAM_SCC2_SIZE (0x80)
>> +#define MPC8xx_DPARAM_SCC3_OFFSET (0x3E00)
>> +#define MPC8xx_DPARAM_SCC3_SIZE (0x80)
>> +#define MPC8xx_DPARAM_SCC4_OFFSET (0x3F00)
>> +#define MPC8xx_DPARAM_SCC4_SIZE (0x80)
>> +#define MPC8xx_DPARAM_SMC1_OFFSET (0x3E80)
>> +#define MPC8xx_DPARAM_SMC1_SIZE (0x40)
>> +#define MPC8xx_DPARAM_SMC2_OFFSET (0x3F80)
>> +#define MPC8xx_DPARAM_SMC2_SIZE (0x40)
>
>
> All of these #defines should already be in a header file somewhere,
> and if they aren't, should be in the generic CPM header file.
> Please clean this up.
>
> Thanks.
>
> -- Dan
>
>
I am going to move interrupts to the generic CPM header file, others I
guess may be cleanup'ed, with replace respective defines in the source
by pure numbers (as was done previously for PQ2 platform stuff).
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [RFC][PATCH] [1/2] 8xx platform definitions
From: Dan Malek @ 2005-08-19 15:06 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Schaefer-Hutter, Peter, Kumar Gala, linuxppc-embedded list
In-Reply-To: <4305D42A.2080803@ru.mvista.com>
On Aug 19, 2005, at 8:44 AM, Vitaly Bordug wrote:
> +#define MPC8xx_INT_FEC1 SIU_LEVEL1
> +#define MPC8xx_INT_FEC2 SIU_LEVEL3
> +
> +#define MPC8xx_INT_SCC1 (CPM_IRQ_OFFSET + CPMVEC_SCC1)
> +#define MPC8xx_INT_SCC2 (CPM_IRQ_OFFSET + CPMVEC_SCC2)
> +#define MPC8xx_INT_SCC3 (CPM_IRQ_OFFSET + CPMVEC_SCC3)
> +#define MPC8xx_INT_SCC4 (CPM_IRQ_OFFSET + CPMVEC_SCC4)
> +#define MPC8xx_INT_SMC1 (CPM_IRQ_OFFSET + CPMVEC_SMC1)
> +#define MPC8xx_INT_SMC2 (CPM_IRQ_OFFSET + CPMVEC_SMC2)
> +
> +/* Offset from IMMAP base address */
> +#define MPC8xx_SCC1_OFFSET (0xa00)
> +#define MPC8xx_SCC1_SIZE (0x18)
> +#define MPC8xx_SCC2_OFFSET (0xa20)
> +#define MPC8xx_SCC2_SIZE (0x18)
> +#define MPC8xx_SCC3_OFFSET (0xa40)
> +#define MPC8xx_SCC3_SIZE (0x18)
> +#define MPC8xx_SCC4_OFFSET (0xa60)
> +#define MPC8xx_SCC4_SIZE (0x18)
> +#define MPC8xx_SMC1_OFFSET (0xa82)
> +#define MPC8xx_SMC1_SIZE (0x0f)
> +#define MPC8xx_SMC2_OFFSET (0xa92)
> +#define MPC8xx_SMC2_SIZE (0x0d)
> +#define MPC8xx_FEC1_OFFSET (0xe00)
> +#define MPC8xx_FEC1_SIZE (0x88)
> +#define MPC8xx_FEC2_OFFSET (0x1e00)
> +#define MPC8xx_FEC2_SIZE (0x88)
> +
> +#define MPC8xx_DPARAM_SCC1_OFFSET (0x3C00)
> +#define MPC8xx_DPARAM_SCC1_SIZE (0x80)
> +#define MPC8xx_DPARAM_SCC2_OFFSET (0x3D00)
> +#define MPC8xx_DPARAM_SCC2_SIZE (0x80)
> +#define MPC8xx_DPARAM_SCC3_OFFSET (0x3E00)
> +#define MPC8xx_DPARAM_SCC3_SIZE (0x80)
> +#define MPC8xx_DPARAM_SCC4_OFFSET (0x3F00)
> +#define MPC8xx_DPARAM_SCC4_SIZE (0x80)
> +#define MPC8xx_DPARAM_SMC1_OFFSET (0x3E80)
> +#define MPC8xx_DPARAM_SMC1_SIZE (0x40)
> +#define MPC8xx_DPARAM_SMC2_OFFSET (0x3F80)
> +#define MPC8xx_DPARAM_SMC2_SIZE (0x40)
All of these #defines should already be in a header file somewhere,
and if they aren't, should be in the generic CPM header file.
Please clean this up.
Thanks.
-- Dan
^ permalink raw reply
* [RFC][PATCH] board-specific platform setup for mpc8272
From: Vitaly Bordug @ 2005-08-19 14:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: Pantelis Antoniou, linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
This is platform setup for MPC8272ADS to use it with fs_enet driver.
Assumes that [PATCH] ppc32: Add ppc_sys descriptions for PowerQUICC II
devices is applied. This is not in the final state (since fs_enet will
be modified a bit),but it could be useful if someone does want to test
fs_enet on the likewise board.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: mpc8272_platform_bsp.patch --]
[-- Type: text/x-patch, Size: 12224 bytes --]
diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
--- a/arch/ppc/platforms/Makefile
+++ b/arch/ppc/platforms/Makefile
@@ -19,6 +19,8 @@ ifeq ($(CONFIG_PPC_PMAC),y)
obj-$(CONFIG_NVRAM) += pmac_nvram.o
obj-$(CONFIG_CPU_FREQ_PMAC) += pmac_cpufreq.o
endif
+
+obj-$(CONFIG_ADS8272) += mpc8272ads_setup.o
obj-$(CONFIG_PMAC_BACKLIGHT) += pmac_backlight.o
obj-$(CONFIG_PREP_RESIDUAL) += residual.o
obj-$(CONFIG_ADIR) += adir_setup.o adir_pic.o adir_pci.o
diff --git a/arch/ppc/platforms/mpc8272ads_setup.c b/arch/ppc/platforms/mpc8272ads_setup.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/mpc8272ads_setup.c
@@ -0,0 +1,237 @@
+/*
+ * arch/ppc/platforms/82xx/pq2ads_pd.c
+ *
+ * MPC82xx Board-specific PlatformDevice descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * 2005 (c) MontaVista Software, Inc.
+ * Vitaly Bordug <vbordug@ru.mvista.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 <linux/fs_enet_pd.h>
+
+#include <asm/io.h>
+#include <asm/mpc8260.h>
+#include <asm/cpm2.h>
+#include <asm/immap_cpm2.h>
+#include <asm/irq.h>
+#include <asm/ppc_sys.h>
+#include <asm/ppcboot.h>
+
+#include "pq2ads_pd.h"
+
+static struct fs_mii_bus_info mii_bus_info = {
+ .method = fsmii_bitbang,
+ .id = 0,
+ .i.bitbang = {
+ .mdio_port = fsiop_portc,
+ .mdio_bit = 18,
+ .mdc_port = fsiop_portc,
+ .mdc_bit = 19,
+ .delay = 1,
+ },
+};
+
+static struct fs_platform_info mpc82xx_fcc1_pdata = {
+ .fs_no = fsid_fcc1,
+ .cp_page = CPM_CR_FCC1_PAGE,
+ .cp_block = CPM_CR_FCC1_SBLOCK,
+ .clk_trx = (PC_F1RXCLK | PC_F1TXCLK),
+ .clk_route = CMX1_CLK_ROUTE,
+ .clk_mask = CMX1_CLK_MASK,
+
+
+ .phy_addr = 0,
+#ifdef PHY_INTERRUPT
+ .phy_irq = PHY_INTERRUPT,
+#endif
+ .mem_offset = FCC1_MEM_OFFSET,
+ .bus_info = &mii_bus_info,
+ .rx_ring = 32,
+ .tx_ring = 32,
+ .rx_copybreak = 240,
+ .use_napi = 0,
+ .napi_weight = 17,
+};
+
+static struct fs_platform_info mpc82xx_fcc2_pdata = {
+ .fs_no = fsid_fcc2,
+ .cp_page = CPM_CR_FCC2_PAGE,
+ .cp_block = CPM_CR_FCC2_SBLOCK,
+ .clk_trx = (PC_F2RXCLK | PC_F2TXCLK),
+ .clk_route = CMX2_CLK_ROUTE,
+ .clk_mask = CMX2_CLK_MASK,
+
+ .phy_addr = 3,
+#ifdef PHY_INTERRUPT
+ .phy_irq = PHY_INTERRUPT,
+#endif
+
+ .mem_offset = FCC2_MEM_OFFSET,
+ .bus_info = &mii_bus_info,
+ .rx_ring = 32,
+ .tx_ring = 32,
+ .rx_copybreak = 240,
+ .use_napi = 0,
+ .napi_weight = 17,
+};
+
+/* Initialize the I/O pins for the FCC Ethernet. */
+static void init_fcc_ioports(void)
+{
+ struct immap *immap;
+ struct io_port *io;
+ u32 tempval;
+
+ immap = cpm2_immr;
+
+ io = &immap->im_ioport;
+ /* FCC1 pins are on port A/C. FCC2/3 are port B/C. */
+ /* Configure port A and C pins for FCC1 Ethernet. */
+ tempval = in_be32(&io->iop_pdira);
+ tempval &= ~PA1_DIRA0;
+ tempval |= PA1_DIRA1;
+ out_be32(&io->iop_pdira, tempval);
+
+ tempval = in_be32(&io->iop_psora);
+ tempval &= ~PA1_PSORA0;
+ tempval |= PA1_PSORA1;
+ out_be32(&io->iop_psora, tempval);
+
+ tempval = in_be32(&io->iop_ppara);
+ tempval |= (PA1_DIRA0 | PA1_DIRA1);
+ out_be32(&io->iop_ppara, tempval);
+
+ tempval = in_be32(&io->iop_pdirb);
+ tempval &= ~PB2_DIRB0;
+ tempval |= PB2_DIRB1;
+ out_be32(&io->iop_pdirb, tempval);
+
+ tempval = in_be32(&io->iop_psorb);
+ tempval &= ~PB2_PSORB0;
+ tempval |= PB2_PSORB1;
+ out_be32(&io->iop_psorb, tempval);
+
+ tempval = in_be32(&io->iop_pparb);
+ tempval |= (PB2_DIRB0 | PB2_DIRB1);
+ out_be32(&io->iop_pparb, tempval);
+
+ /* Port C has clocks...... */
+ tempval = in_be32(&io->iop_psorc);
+ tempval &= ~(CLK_TRX);
+ out_be32(&io->iop_psorc, tempval);
+
+ tempval = in_be32(&io->iop_pdirc);
+ tempval &= ~(CLK_TRX);
+ out_be32(&io->iop_pdirc, tempval);
+
+ tempval = in_be32(&io->iop_pparc);
+ tempval |= (CLK_TRX);
+ out_be32(&io->iop_pparc, tempval);
+
+ /* ....and the MII serial clock/data. */
+ io->iop_pdatc |= (PC_MDIO | PC_MDCK);
+ io->iop_podrc &= ~(PC_MDIO | PC_MDCK);
+ io->iop_pdirc |= (PC_MDIO | PC_MDCK);
+ io->iop_pparc &= ~(PC_MDIO | PC_MDCK);
+
+ /* Configure Serial Interface clock routing.
+ * First, clear all FCC bits to zero,
+ * then set the ones we want.
+ */
+ immap->im_cpmux.cmx_fcr &= ~(CPMUX_CLK_MASK);
+ immap->im_cpmux.cmx_fcr |= CPMUX_CLK_ROUTE;
+}
+
+
+static void __init mpc8272ads_fixup_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ bd_t* bi = (void*)__res;
+ cpm2_map_t* immr = (cpm2_map_t *)CPM_MAP_ADDR;
+ int fs_no = fsid_fcc1+pdev->id-1;
+
+ /*all-in-one for now*/
+ init_fcc_ioports();
+
+ mpc82xx_fcc1_pdata.dpram_offset = mpc82xx_fcc2_pdata.dpram_offset = (u32)immr->im_dprambase;
+ mpc82xx_fcc1_pdata.fcc_regs_c = mpc82xx_fcc2_pdata.fcc_regs_c = (u32)immr->im_fcc_c;
+
+ /* At last wi fill the platform_data pointers with respective data */
+ switch(fs_no) {
+ case fsid_fcc1:
+ memcpy(&mpc82xx_fcc1_pdata.macaddr,bi->bi_enetaddr,6);
+ pdev->dev.platform_data = &mpc82xx_fcc1_pdata;
+ break;
+ case fsid_fcc2:
+ memcpy(&mpc82xx_fcc2_pdata.macaddr,bi->bi_enetaddr,6);
+ mpc82xx_fcc2_pdata.macaddr[5] ^= 1;
+ pdev->dev.platform_data = &mpc82xx_fcc2_pdata;
+ break;
+ }
+}
+
+static int __init mpc8272ads_platform_notify(struct device *dev)
+{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {"fsl-cpm-fcc", mpc8272ads_fixup_enet_pdata},
+ };
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+ dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}
+
+int __init mpc8272ads_init(void)
+{
+ cpm2_map_t* immr = (cpm2_map_t *)CPM_MAP_ADDR;
+
+ printk(KERN_NOTICE "mpc8272ads: Init\n");
+
+ platform_notify = mpc8272ads_platform_notify;
+
+ identify_ppc_sys_by_name_and_id(BOARD_NAME,cpm2_immr->im_memctl.memc_immr);
+
+ identify_ppc_sys_by_name(BOARD_NAME);
+
+ /*Remove stuff does not utilized platform way*/
+ ppc_sys_device_remove(MPC82xx_CPM_SCC1);
+ ppc_sys_device_remove(MPC82xx_CPM_SCC2);
+ ppc_sys_device_remove(MPC82xx_CPM_SCC3);
+ ppc_sys_device_remove(MPC82xx_CPM_SCC4);
+ ppc_sys_device_remove(MPC82xx_CPM_SMC1);
+ ppc_sys_device_remove(MPC82xx_CPM_SMC2);
+
+ return 0;
+}
+
+arch_initcall(mpc8272ads_init);
diff --git a/arch/ppc/platforms/pq2ads.h b/arch/ppc/platforms/pq2ads.h
--- a/arch/ppc/platforms/pq2ads.h
+++ b/arch/ppc/platforms/pq2ads.h
@@ -13,6 +13,10 @@
#include <asm/ppcboot.h>
+#if defined(CONFIG_ADS8272)
+#define BOARD_NAME "8272"
+#endif
+
/* Memory map is configured by the PROM startup.
* We just map a few things we need. The CSR is actually 4 byte-wide
* registers that can be accessed as 8-, 16-, or 32-bit values.
diff --git a/arch/ppc/platforms/pq2ads_pd.h b/arch/ppc/platforms/pq2ads_pd.h
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/pq2ads_pd.h
@@ -0,0 +1,135 @@
+#ifndef __PQ2ADS_PD_H
+#define __PQ2ADS_PD_H
+/*
+ * arch/ppc/platforms/82xx/pq2ads_pd.h
+ *
+ * Some defines for MPC82xx board-specific PlatformDevice descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * 2005 (c) MontaVista Software, Inc.
+ * Vitaly Bordug <vbordug@ru.mvista.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.
+ */
+
+/* FCC1 Clock Source Configuration. These can be redefined in the board specific file.
+ Can only choose from CLK9-12 */
+
+#define F1_RXCLK 11
+#define F1_TXCLK 10
+
+/* FCC2 Clock Source Configuration. These can be redefined in the board specific file.
+ Can only choose from CLK13-16 */
+#define F2_RXCLK 15
+#define F2_TXCLK 16
+
+/* FCC3 Clock Source Configuration. These can be redefined in the board specific file.
+ Can only choose from CLK13-16 */
+#define F3_RXCLK 15
+#define F3_TXCLK 16
+
+/* MDIO and MDCK settings. These can be redefined in the board specific file.*/
+#define PC_MDIO 0x00002000U
+#define PC_MDCK 0x00001000U
+
+/* Automatically generates register configurations */
+#define PC_CLK(x) ((uint)(1<<(x-1))) /* FCC CLK I/O ports */
+
+#define CMXFCR_RF1CS(x) ((uint)((x-5)<<27)) /* FCC1 Receive Clock Source */
+#define CMXFCR_TF1CS(x) ((uint)((x-5)<<24)) /* FCC1 Transmit Clock Source */
+#define CMXFCR_RF2CS(x) ((uint)((x-9)<<19)) /* FCC2 Receive Clock Source */
+#define CMXFCR_TF2CS(x) ((uint)((x-9)<<16)) /* FCC2 Transmit Clock Source */
+#define CMXFCR_RF3CS(x) ((uint)((x-9)<<11)) /* FCC3 Receive Clock Source */
+#define CMXFCR_TF3CS(x) ((uint)((x-9)<<8)) /* FCC3 Transmit Clock Source */
+
+#define PC_F1RXCLK PC_CLK(F1_RXCLK)
+#define PC_F1TXCLK PC_CLK(F1_TXCLK)
+#define CMX1_CLK_ROUTE (CMXFCR_RF1CS(F1_RXCLK) | CMXFCR_TF1CS(F1_TXCLK))
+#define CMX1_CLK_MASK ((uint)0xff000000)
+
+#define PC_F2RXCLK PC_CLK(F2_RXCLK)
+#define PC_F2TXCLK PC_CLK(F2_TXCLK)
+#define CMX2_CLK_ROUTE (CMXFCR_RF2CS(F2_RXCLK) | CMXFCR_TF2CS(F2_TXCLK))
+#define CMX2_CLK_MASK ((uint)0x00ff0000)
+
+#define PC_F3RXCLK PC_CLK(F3_RXCLK)
+#define PC_F3TXCLK PC_CLK(F3_TXCLK)
+#define CMX3_CLK_ROUTE (CMXFCR_RF3CS(F3_RXCLK) | CMXFCR_TF3CS(F3_TXCLK))
+#define CMX3_CLK_MASK ((uint)0x0000ff00)
+
+/* Some board-specific defines here... Temporary I hope -vb*/
+#ifdef CONFIG_ADS8272
+#define CPMUX_CLK_MASK (CMX1_CLK_MASK | CMX2_CLK_MASK)
+#define CPMUX_CLK_ROUTE (CMX1_CLK_ROUTE | CMX2_CLK_ROUTE)
+#else
+#error You need to define cpmux setup for your board
+#endif
+
+#ifdef CONFIG_ADS8272
+#define CLK_TRX (F1_TXCLK | F1_TXCLK | F2_TXCLK | F2_RXCLK)
+#else
+#error You need to define clock source for your board
+#endif
+
+
+/* I/O Pin assignment for FCC1. I don't yet know the best way to do this,
+ * but there is little variation among the choices.
+ */
+#define PA1_COL 0x00000001U
+#define PA1_CRS 0x00000002U
+#define PA1_TXER 0x00000004U
+#define PA1_TXEN 0x00000008U
+#define PA1_RXDV 0x00000010U
+#define PA1_RXER 0x00000020U
+#define PA1_TXDAT 0x00003c00U
+#define PA1_RXDAT 0x0003c000U
+#define PA1_PSORA0 (PA1_RXDAT | PA1_TXDAT)
+#define PA1_PSORA1 (PA1_COL | PA1_CRS | PA1_TXER | PA1_TXEN | \
+ PA1_RXDV | PA1_RXER)
+#define PA1_DIRA0 (PA1_RXDAT | PA1_CRS | PA1_COL | PA1_RXER | PA1_RXDV)
+#define PA1_DIRA1 (PA1_TXDAT | PA1_TXEN | PA1_TXER)
+
+
+/* I/O Pin assignment for FCC2. I don't yet know the best way to do this,
+ * but there is little variation among the choices.
+ */
+#define PB2_TXER 0x00000001U
+#define PB2_RXDV 0x00000002U
+#define PB2_TXEN 0x00000004U
+#define PB2_RXER 0x00000008U
+#define PB2_COL 0x00000010U
+#define PB2_CRS 0x00000020U
+#define PB2_TXDAT 0x000003c0U
+#define PB2_RXDAT 0x00003c00U
+#define PB2_PSORB0 (PB2_RXDAT | PB2_TXDAT | PB2_CRS | PB2_COL | \
+ PB2_RXER | PB2_RXDV | PB2_TXER)
+#define PB2_PSORB1 (PB2_TXEN)
+#define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | PB2_RXDV)
+#define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER)
+
+
+/* I/O Pin assignment for FCC3. I don't yet know the best way to do this,
+ * but there is little variation among the choices.
+ */
+#define PB3_RXDV 0x00004000U
+#define PB3_RXER 0x00008000U
+#define PB3_TXER 0x00010000U
+#define PB3_TXEN 0x00020000U
+#define PB3_COL 0x00040000U
+#define PB3_CRS 0x00080000U
+#define PB3_TXDAT 0x0f000000U
+#define PB3_RXDAT 0x00f00000U
+#define PB3_PSORB0 (PB3_RXDAT | PB3_TXDAT | PB3_CRS | PB3_COL | \
+ PB3_RXER | PB3_RXDV | PB3_TXER | PB3_TXEN)
+#define PB3_PSORB1 0
+#define PB3_DIRB0 (PB3_RXDAT | PB3_CRS | PB3_COL | PB3_RXER | PB3_RXDV)
+#define PB3_DIRB1 (PB3_TXDAT | PB3_TXEN | PB3_TXER)
+
+#define FCC_MEM_OFFSET(x) (CPM_FCC_SPECIAL_BASE + (x*128))
+#define FCC1_MEM_OFFSET FCC_MEM_OFFSET(0)
+#define FCC2_MEM_OFFSET FCC_MEM_OFFSET(1)
+
+#endif
^ 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