* Re: pci_enable_device fails on MPC8541
From: Kumar Gala @ 2005-08-08 20:34 UTC (permalink / raw)
To: Bizhan Gholikhamseh \((bgholikh\)); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA91127964158494EB@xmb-sjc-212.amer.cisco.com>
Bizhan,
A few questions:
1. what kernel version are you using on these boards:
2. can you do an lspci -v on the boards
- kumar
On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote:
> Hi All,
> I am using two evaluation board from freescale, 8540ADS and
> MPC8541. The
> same PCI driver is being compiled and loaded on both platforms. The
> same
> PCI driver (developed by me) for DSP board compiled and loaded on both
> platforms.
>
> When I type: "insmod C6415.ko" on 8541 board, I get the following
> error:
> "PCI: Device 0000:02:01.0 not available because of resource
> collisions"
> This messages is because of the execution of the generic PCI Linux
> command:
> "pci_enable_device(pdev)"
> The same API has no problem on 8540ADS.
>
>
>> From UBOOT I can see my device is on bus 3:
>>
> => pci 3
> Scanning PCI devices on bus 3
> BusDev FUN VendorID DeviceID Device Class Sub-Class
> ----------------------------------------------------------------------
> --
> --------------------
> 03.01.00 0x104c 0xa106 .........
>
> Any idea why the insmod fails on one board and not on the other one?
>
> Many thanks in advance,
> Bizhan
>
> <ATT2118305.txt>
>
^ permalink raw reply
* Re: The kernel halt after "transferring control to linux(0x000000)..." on HD860(MPC860SR) board kernel 2.4.25, and 2.6.12
From: Manish Joshi @ 2005-08-08 20:27 UTC (permalink / raw)
To: Wolfgang Denk, FCG WANG Baohua; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <20050805091633.8EF0E352633@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]
Hope you are connecting with right port speed.
Wolfgang Denk <wd@denx.de> wrote:In message you wrote:
>
> I meet a problem when porting kernel 2.4.25,and 2.6.12 to a HD860
> board: Whatever your config, or whatever you patch, set ppcboot
> enviroment,
> whether use ramdisk or nfs, the kernel all display a message then
> halt.
How do you define "halt"? There is no "halt" instruction in the CPU,
so it must be doing "something".
> The log_buf in Memory display that the kernel has problem at :
>
> 1. /init/main.c calibrate_delay() ;
> 2. /init/main.c do_initcalls() do while dead loop!!
> 3. /init/do_mounts.c mount_root()
Locate the problems and fix them.
> Does it need any patches? thanks!
> The kernel 2.4.25 is from ELDK 3.1.1, 2.6.12.3 is from kernel.org
this kernel works fine on many, many other boards. It's extremely
likely that the problems are caused by your port only.
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
A person who is more than casually interested in computers should be
well schooled in machine language, since it is a fundamental part of
a computer. -- Donald Knuth
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
---------------------------------
Start your day with Yahoo! - make it your home page
[-- Attachment #2: Type: text/html, Size: 1911 bytes --]
^ permalink raw reply
* pci_enable_device fails on MPC8541
From: Bizhan Gholikhamseh (bgholikh) @ 2005-08-08 18:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
Hi All,
I am using two evaluation board from freescale, 8540ADS and MPC8541. The
same PCI driver is being compiled and loaded on both platforms. The same
PCI driver (developed by me) for DSP board compiled and loaded on both
platforms.
When I type: "insmod C6415.ko" on 8541 board, I get the following error:
"PCI: Device 0000:02:01.0 not available because of resource collisions"
This messages is because of the execution of the generic PCI Linux
command:
"pci_enable_device(pdev)"
The same API has no problem on 8540ADS.
>From UBOOT I can see my device is on bus 3:
=> pci 3
Scanning PCI devices on bus 3
BusDev FUN VendorID DeviceID Device Class Sub-Class
------------------------------------------------------------------------
--------------------
03.01.00 0x104c 0xa106 .........
Any idea why the insmod fails on one board and not on the other one?
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 3657 bytes --]
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Joel Schopp @ 2005-08-08 17:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17136.13558.773102.465379@cargo.ozlabs.ibm.com>
> I don't see the merge as changing the actual code that gets executed
> on any given platform very much, except in one respect: we are going
> to standardize on a flattened device tree as the way that information
> about the platform gets passed from the boot loader to the kernel.
>
> Comments? Flames? :)
There are several userspace applications that parse the non-flat device
tree in /proc/device-tree on pSeries. While I like the idea of the
flattened device tree I think we need to consider how many apps we are
going to break with it.
^ permalink raw reply
* Re: [PATCH] ppc32: Fix MPC834x USB memory map offsets
From: Kumar Gala @ 2005-08-08 17:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Jiang Bo-r61859, linux-kernel list,
linuxppc-embedded list
In-Reply-To: <Pine.LNX.4.61.0508040858290.13245@nylon.am.freescale.net>
Linus,
If this can go into 2.6.13 that would be good since is a fairly
trivial bug and fix.
- kumar
On Aug 4, 2005, at 8:59 AM, Gala Kumar K.-galak wrote:
> The memory mappings for MPC8349 USB MPH and DR modules were reversed.
>
> Signed-off-by: Li Yang <LeoLi@freescale.com>
> Signed-off-by: Jiang Bo <Tanya.jiang@freescale.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
>
> ---
> commit a2227df6ac23000dff7d95411ae5bd8022437ad3
> tree d22a59e837eb881b1292f70e51df561802b279df
> parent 51904043565cdfb348f58ce99377427c5ffe25fd
> author Kumar K. Gala <kumar.gala@freescale.com> Thu, 04 Aug 2005
> 08:57:58 -0500
> committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 04 Aug 2005
> 08:57:58 -0500
>
> arch/ppc/syslib/mpc83xx_devices.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/ppc/syslib/mpc83xx_devices.c
> b/arch/ppc/syslib/mpc83xx_devices.c
> --- a/arch/ppc/syslib/mpc83xx_devices.c
> +++ b/arch/ppc/syslib/mpc83xx_devices.c
> @@ -191,8 +191,8 @@ struct platform_device ppc_sys_platform_
> .num_resources = 2,
> .resource = (struct resource[]) {
> {
> - .start = 0x22000,
> - .end = 0x22fff,
> + .start = 0x23000,
> + .end = 0x23fff,
> .flags = IORESOURCE_MEM,
> },
> {
> @@ -208,8 +208,8 @@ struct platform_device ppc_sys_platform_
> .num_resources = 2,
> .resource = (struct resource[]) {
> {
> - .start = 0x23000,
> - .end = 0x23fff,
> + .start = 0x22000,
> + .end = 0x22fff,
> .flags = IORESOURCE_MEM,
> },
> {
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [PATCH] cpm_uart_core.c GCC4.x compilation fix
From: Kumar Gala @ 2005-08-08 16:59 UTC (permalink / raw)
To: Schaefer-Hutter, Peter; +Cc: linuxppc-embedded list
In-Reply-To: <8E342283C2100540AAC5D10309705477749C5F@rcexc.racoms.loc>
Peter,
Patch looks good. Can't believe we lost the '=' in the
initialization. Will queue this up with a few other CPM_UART related
patches.
- kumar
On Aug 8, 2005, at 8:57 AM, Schaefer-Hutter, Peter wrote:
> cpm_uart_core.c: needs some love to compile with GCC4.0.1.
>
> Signed-off-by: Peter Schaefer-Hutter
> <peter.schaefer-hutter@tfk-racoms.com>
>
> --- a/drivers/serial/cpm_uart/cpm_uart_core.c 2005-08-08
> 15:49:16.725292392 +0200
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c 2005-08-08
> 15:33:47.691526992 +0200
> @@ -1134,14 +1134,14 @@
> return 0;
> }
>
> -extern struct uart_driver cpm_reg;
> +static struct uart_driver cpm_reg;
> static struct console cpm_scc_uart_console = {
> - .name "ttyCPM",
> - .write cpm_uart_console_write,
> - .device uart_console_device,
> - .setup cpm_uart_console_setup,
> - .flags CON_PRINTBUFFER,
> - .index -1,
> + .name = "ttyCPM",
> + .write = cpm_uart_console_write,
> + .device = uart_console_device,
> + .setup = cpm_uart_console_setup,
> + .flags = CON_PRINTBUFFER,
> + .index = -1,
> .data = &cpm_reg,
> };
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Reducing glibc with mklibs.sh
From: Orlov, Leonid @ 2005-08-08 16:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
Hi,
Does anyone has an example of successful use of either libopt or
mklib.sh in redhat environmet?
I am having hard time to make it work.
I created a myLib library with 3 1 statement function and a main that
use only 2 of the myLib functions.
I am trying to have either tool to detect that only 2 out of 3 functions
are used and reduce myLib correspondingly. So far I have hard time to
have it work.
BTW does mklib dependent on Debian environment. I am using redhat
I am also wondering if Lineo released LIPO for public use.
I called them trying to get a commercial version, they excluded LIPO
from their offerings.
Thanks for your help.
Leonid Orlov
[-- Attachment #2: Type: text/html, Size: 1813 bytes --]
^ permalink raw reply
* RE: MPC885ADS and 2.6.13-rc5 - nogo ?
From: Schaefer-Hutter, Peter @ 2005-08-08 14:34 UTC (permalink / raw)
To: linuxppc-embedded list
Replying to myself: My MPC855ADS-Board has=20
-> U-Boot 1.1.2 (Jun 27 2005 - 11:50:05)
-> CPU: MPC885ZPnn at 120 MHz: 8 kB I-Cache 8 kB D-Cache FEC present
-> Board: MPC885ADS rev NR
-> DRAM: (8 MB SDRAM) 8 MB
... and 8 MB Flash.
AFAIK there were boards with only 2 MB RAM. Which boards do you guys
have?
Best regards,
Peter
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
Schaefer-Hutter, Peter
Sent: Monday, August 08, 2005 11:38 AM
To: linuxppc-embedded list
Subject: RE: MPC885ADS and 2.6.13-rc5 - nogo ?
Hello!
> From: aris@cathedrallabs.org [mailto:aris@cathedrallabs.org]=20
> Sent: Friday, August 05, 2005 6:26 PM
>
> > Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:348
> > Call trace:
> > [c0005b10] dump_stack+0x18/0x28
> > [c0003c60] check_bug_trap+0x84/0xac
> > [c0003de8] ProgramCheckException+0x160/0x1a0
> > [c0003260] ret_from_except_full+0x0/0x4c
> > [c01a9f84] dma_alloc_init+0x44/0xa0
> > [c01a66a4] do_initcalls+0x54/0xfc
> > [c0002260] init+0x2c/0xf4
> > [c000533c] kernel_thread+0x44/0x60
> > NET: Registered protocol family 16
> > JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
> > Serial: CPM driver $Revision: 0.01 $
> > ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART
> > ttyCPM1 at MMIO 0xff000a90 (irq =3D 19) is a CPM UART
> just out of curiosity, try changing CONSISTENT_START to 0xe0000000
Well, then the error in dma_alloc_init goes away.
However, i'm still not able to run 2.6.x on the MPC885ADS.
I'm now using 2.6.13-rc6 with the latest cpm-uart-fixes=20
applied. I made the defconfig, set CONSISTENT_START to 0xe0000000
an got:
Linux version 2.6.13-rc6 (root@rcf02) (gcc version 3.3.2) #5 Mon Aug 8
11:22:18 CEST 2005
Built 1 zonelists
Kernel command line: console=3DttyCPM0,38400n8 root=3D/dev/nfs
nfsroot=3D/home/test/nfs rw
ip=3D192.168.1.10:192.168.1.1:192.168.1.1:255.255.255.0::eth0:off
PID hash table entries: 64 (order: 6, 1024 bytes)
Decrementer Frequency =3D 450000000/60
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 6244k available (1432k kernel code, 332k data, 72k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART
ttyCPM1 at MMIO 0xff000a90 (irq =3D 19) is a CPM UART
io scheduler noop registered
PPP generic driver version 2.4.2
PPP Deflate Compression module registere
Looks like the console does not start (maybe still UART-issues)...=20
As some people on this list reported success on MPC885ADS - can somebody
please hit me with the cluebat ?
Best regards,=20
Peter
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] cpm_uart_core.c GCC4.x compilation fix
From: Schaefer-Hutter, Peter @ 2005-08-08 13:57 UTC (permalink / raw)
To: linuxppc-embedded list
cpm_uart_core.c: needs some love to compile with GCC4.0.1.
Signed-off-by: Peter Schaefer-Hutter
<peter.schaefer-hutter@tfk-racoms.com>
--- a/drivers/serial/cpm_uart/cpm_uart_core.c 2005-08-08
15:49:16.725292392 +0200
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c 2005-08-08
15:33:47.691526992 +0200
@@ -1134,14 +1134,14 @@
return 0;
}
-extern struct uart_driver cpm_reg;
+static struct uart_driver cpm_reg;
static struct console cpm_scc_uart_console =3D {
- .name "ttyCPM",
- .write cpm_uart_console_write,
- .device uart_console_device,
- .setup cpm_uart_console_setup,
- .flags CON_PRINTBUFFER,
- .index -1,
+ .name =3D "ttyCPM",
+ .write =3D cpm_uart_console_write,
+ .device =3D uart_console_device,
+ .setup =3D cpm_uart_console_setup,
+ .flags =3D CON_PRINTBUFFER,
+ .index =3D -1,
.data =3D &cpm_reg,
};
=20
^ permalink raw reply
* [Newbie] Question on m8260_gorom
From: Srivatsan CR @ 2005-08-08 13:18 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 15518 bytes --]
Dear all,
1) I am using a LinuxPPC kernel version 2.4.18 and on a MPC8280
processor.
2) I am assuming that the Linux memory map for PowerPC looks like the
following:
END_OF_RAM|---------------|
| |
| |
| |
| |
| |
| |
0x800000|---------------|
|Linux-PPC |
|Kernel |
| |
0x0 |---------------|
Even at the run-time the kernel code resides in the Ram from address 0x0
till 8MB. In m8260_gorom the start_addr variable is initialized to 0x0 but
Kernel is not booting. Actually we are trying to boot the Linux Kernel from
its RAM copy at the time of exception.
3) An Kernel stack overflow was generated . So that the control enters
m8260_gorom. On entering m8260_gorom it executes till RFI after that the
control gets inside my_console_write. This happens even before we execute
the mtlr r4 and blr opcodes. So something else is creating the exception
which is making the code to dump exception on the console. (Not sure what it
is?)
4) Questions are :
a) Is it possible to start from Ram copy of the Linux kernel
Image at an exception generated restart
mechanism ?
B) Has anyone encountered a situation like the one described
above and can anyone tell us what is the cause
of the exception. (It's always printing "Bad kernel page
access")
Thanks for all your time.
With Best Regards,
C.R.Srivatsan
-----Original Message-----
From: linuxppc-embedded-request@ozlabs.org
[mailto:linuxppc-embedded-request@ozlabs.org]
Sent: Monday, August 08, 2005 7:19 AM
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 12, Issue 25
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. Re: [PATCH] 8xx: add cpm_get_cpmp() (Dan Malek)
2. Re: [PATCH] 8xx: add cpm_get_cpmp() (Dan Malek)
3. Re: [PATCH] 8xx: add cpm_get_cpmp() (Marcelo Tosatti)
4. A configure error for samba3 on ppc (JohnsonCheng)
5. Re: [PATCH] 8xx: add cpm_get_cpmp() (Dan Malek)
6. Re: [PATCH] 8xx: add cpm_get_cpmp()
(Aristeu Sergio Rozanski Filho)
7. Re: [PATCH] 8xx: add cpm_get_cpmp() (Marcelo Tosatti)
8. Re: [PATCH] 8xx: add cpm_get_cpmp() (Dan Malek)
9. Re: [PATCH] 8xx: add cpm_get_cpmp() (Eugene Surovegin)
10. Re: Volunteers to test i2c-algo-8xx on v2.6? (Debora Liu)
----------------------------------------------------------------------
Message: 1
Date: Sat, 6 Aug 2005 22:40:37 -0400
From: Dan Malek <dan@embeddededge.com>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <e5caa80a2cd721a4f6ee3c74ead906b2@embeddededge.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Aug 6, 2005, at 7:27 PM, Marcelo Tosatti wrote:
> It already is exported, declared as
>
> commproc.h:extern cpm8xx_t *cpmp; /* Pointer to
> comm processor */
>
>
> and many drivers use the pointer directly.
We shouldn't be doing this. All drivers should ioremap() any peripheral
spaces they use and not make any assumptions someone else has done that
already. We've been making such changes in the 82xx/83xx/85xx CPM2 drivers.
If it isn't convenient to find the #defines for the ioremap(), we should
change that. When I originally wrote all of this code, it was long ago when
we didn't have some of the abstractions and it seemed any shortcuts for
performance were desired :-)
> arch/ppc/8260_io/ drivers also use the same convention.
If there are any drivers in here, they either aren't used or on their way
out. The only things that should remain are common support functions.
Thanks.
-- Dan
------------------------------
Message: 2
Date: Sat, 6 Aug 2005 23:36:16 -0400
From: Dan Malek <dan@embeddededge.com>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <d74e24bbf82e4cedd3358465343d28ae@embeddededge.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Aug 6, 2005, at 7:42 PM, Aristeu Sergio Rozanski Filho wrote:
> but not with EXPORT_SYMBOL(). I noticed this while compiling i2c stuff
> as module. also, I think it's better add a function to do this instead
> doing EXPORT_SYMBOL() in a variable.
Right. We should just ioremap() :-)
Thanks.
-- Dan
------------------------------
Message: 3
Date: Sun, 7 Aug 2005 01:31:10 -0300
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Dan Malek <dan@embeddededge.com>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <20050807043110.GA6316@dmt.cnet>
Content-Type: text/plain; charset=us-ascii
On Sat, Aug 06, 2005 at 10:40:37PM -0400, Dan Malek wrote:
>
> On Aug 6, 2005, at 7:27 PM, Marcelo Tosatti wrote:
>
> >It already is exported, declared as
> >
> >commproc.h:extern cpm8xx_t *cpmp; /* Pointer to
> >comm processor */
> >
> >
> >and many drivers use the pointer directly.
>
> We shouldn't be doing this. All drivers should ioremap() any
> peripheral spaces they use and not make any assumptions someone else
> has done that already. We've been making such changes in the
> 82xx/83xx/85xx CPM2 drivers. If it isn't convenient to find the
> #defines for the ioremap(), we should change that. When I originally
> wrote all of this code, it was long ago when we didn't have some of
> the abstractions and it seemed any shortcuts for performance were
> desired :-)
OK makes sense (yep it was even discussed already).
Aris, sounds like you should proceed with cpm_get_cpmp() and change all
other drivers using it also.
>
>
> >arch/ppc/8260_io/ drivers also use the same convention.
>
> If there are any drivers in here, they either aren't used or on their
> way out. The only things that should remain are common support
> functions.
OK!
------------------------------
Message: 4
Date: Sun, 7 Aug 2005 17:15:55 +0800
From: "JohnsonCheng" <johnsoncheng@qnap.com.tw>
Subject: A configure error for samba3 on ppc
To: <linuxppc-embedded@ozlabs.org>
Message-ID: <20050807091603.CE57667F29@ozlabs.org>
Content-Type: text/plain; charset="us-ascii"
When I configure samba3.0.10 on ppc as following command:
CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib
./configure -host=powerpc-linux
I got a configure error message as following:
Configure: error: cannot run test program while cross compiling
See 'config.log' for more details
I think this is a samba configure bug, do anybody know how to pass it?
Thanks,
Johnson Cheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050807/95f23597/
attachment-0001.htm
------------------------------
Message: 5
Date: Sun, 7 Aug 2005 11:39:52 -0400
From: Dan Malek <dan@embeddededge.com>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <09b0792f426f1d5883cf5d437723f075@embeddededge.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Aug 7, 2005, at 12:31 AM, Marcelo Tosatti wrote:
> Aris, sounds like you should proceed with cpm_get_cpmp() and change
> all other drivers using it also.
It depends how you define the semantics of this function call.
Can you call it any (and all of the) time you need it, or does it actually
perform an ioremap() and you only want to call it once?
I guess implemented properly it doesn't matter. On the first call it should
do the ioremap() and on subsequent calls it just returns the mapping. This
is one of those common functions that should be in commproc.c.
Thanks.
-- Dan
------------------------------
Message: 6
Date: Sun, 7 Aug 2005 12:44:32 -0300
From: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Dan Malek <dan@embeddededge.com>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <20050807154432.GE5210@cathedrallabs.org>
Content-Type: text/plain; charset=us-ascii
> It depends how you define the semantics of this function call.
> Can you call it any (and all of the) time you need it, or does it
> actually perform an ioremap() and you only want to call it once?
what about don't cache it and call ioremap() from driver? (I guess
ioremap() already check if an area is already mapped, no?)
--
Aristeu
------------------------------
Message: 7
Date: Sun, 7 Aug 2005 12:57:31 -0300
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <20050807155731.GA2715@dmt.cnet>
Content-Type: text/plain; charset=us-ascii
On Sun, Aug 07, 2005 at 12:44:32PM -0300, Aristeu Sergio Rozanski Filho
wrote:
> > It depends how you define the semantics of this function call.
> > Can you call it any (and all of the) time you need it, or does it
> > actually perform an ioremap() and you only want to call it once?
> what about don't cache it and call ioremap() from driver? (I guess
> ioremap() already check if an area is already mapped, no?)
Yep, ioremap() should be doing virtual address caching already, no?
------------------------------
Message: 8
Date: Sun, 7 Aug 2005 13:25:34 -0400
From: Dan Malek <dan@embeddededge.com>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <2fcd8a329246b2f2c303e515dd0cb7bf@embeddededge.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Aug 7, 2005, at 11:44 AM, Aristeu Sergio Rozanski Filho wrote:
> what about don't cache it and call ioremap() from driver? (I guess
> ioremap() already check if an area is already mapped, no?)
Either way. I'm actually leaning toward these "pointer helper"
functions. :-) Something like get_cpmp(), or get_immr(), that will hide the
details of the mapping, so you don't have to include and know which #defines
to use as part of an ioremap() call.
It seems to be more clear to me, and I'm thinking about making the same
changes to the CPM2 drivers. It also allows a performance versus compact
code trade off, declaring these as inline functions or as real functions.
Thanks.
-- Dan
------------------------------
Message: 9
Date: Sun, 7 Aug 2005 12:18:29 -0700
From: Eugene Surovegin <ebs@ebshome.net>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <20050807191829.GA5375@gate.ebshome.net>
Content-Type: text/plain; charset=us-ascii
On Sun, Aug 07, 2005 at 12:57:31PM -0300, Marcelo Tosatti wrote:
> On Sun, Aug 07, 2005 at 12:44:32PM -0300, Aristeu Sergio Rozanski Filho
wrote:
> > > It depends how you define the semantics of this function call.
> > > Can you call it any (and all of the) time you need it, or does it
> > > actually perform an ioremap() and you only want to call it once?
> > what about don't cache it and call ioremap() from driver? (I guess
> > ioremap() already check if an area is already mapped, no?)
>
> Yep, ioremap() should be doing virtual address caching already, no?
In general, ioremap() doesn't do any caching currently. Some subarchs do
some limited caching, e.g. if BATs (classic PPC) or CAMs (e500) are
available and were used previously for ioremap() mappings.
Some time ago I made a trivial ioremap cache patch (useful on 4xx, which
doesn't have BATs nor CAMs), although it wass really a hack and it was never
merged :).
--
Eugene
------------------------------
Message: 10
Date: Mon, 8 Aug 2005 09:53:32 +0800
From: "Debora Liu" <deboralh@fel.com.cn>
Subject: Re: Volunteers to test i2c-algo-8xx on v2.6?
To: "Marcelo Tosatti" <marcelo.tosatti@cyclades.com>
Cc: Linuxppc-embedded <Linuxppc-embedded@ozlabs.org>
Message-ID: <20050808014920.0373467F1E@ozlabs.org>
Hello, Marcelo Tosatti
In message <2005-08-07 08:34:52 marcelo.tosatti@cyclades.com> you wrote:
>
>Does anyone volunteer to test this 8xx i2c driver?
>
>
I don't have kernel v2.6, but I have test my board with eldk-3.1.1
linux-2.4.25
when my board kernel booting, I found one problem.
eldk-3.1.1 linux-2.4.25 kernel include i2c, i2c-algo-8xx, pcf8563 driver.
If one pcf8563 chip on my board, there are't problem.
But if my board don't have pcf8563 chip, kernel stop as blow:
Linux version 2.4.25 (liu@bighead) (gcc version 3.3.3 (DENX ELDK 3.1.1
3.3.3-9))
#4 Îå 7ÔÂ 29 12:19:14 CST 2005
m8xx_setup.c:Reserved 0x10000 memory at 0xc0190000
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nftla1
ip=192.168.0.207:192.168.0.82:::sc855t:eth
0:off
Decrementer Frequency = 300000000/60
Warning: real time clock seems stuck!
Calibrating delay loop... 79.66 BogoMIPS
========= HZ=100 loops_per_jiffy=398336
Memory: 30752k available (1144k kernel code, 356k data, 56k init, 0k
highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
WDT_8xx: SWT not enabled by firmware, SYPCR=0xffffff88
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
i2c-algo-8xx.o: i2c mpc8xx algorithm module version 2.6.1 (20010830)
i2c-rpx.o: i2c MPC8xx module version 2.6.1 (20010830)
i2c-proc.o version 2.6.1 (20010830)
CPM UART driver version 0.04
ttyS0 at 0x0280 is on SMC1 using BRG1
ttyS1 at 0x0380 is on SMC2 using BRG2
pty: 256 Unix98 ptys configured
PCF8563 Real-Time Clock Driver $Revision: 1.3 $ wd@denx.de
I modify i2c-algo-8xx.c cpm_iic_write(), then no problem,
my board defined by CONFIG_SVM8xx
#ifdef CONFIG_SVM8xx
while(!(i2c->i2c_i2cer & 0x12))
if (time_after(jiffies, tmo)) {
tmo = 0;
break;
}
#else
while(!(i2c->i2c_i2cer & 0x12 || time_after(jiffies, tmo)));
/* Bus
#endif
= = = = = = = = = = = = = = = = = = = =
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Debora Liu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡deboralh@fel.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-08
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 12, Issue 25
*************************************************
[-- Attachment #2: Type: text/html, Size: 28003 bytes --]
^ permalink raw reply
* Re: Volunteers to test i2c-algo-8xx on v2.6?
From: Aristeu Sergio Rozanski Filho @ 2005-08-08 13:05 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <JPEALJAFNGDDLOPNDIEEKEALDFAA.joakim.tjernlund@lumentis.se>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Hi,
> I have done this for cpm_iic_read, cpm_iic_write and cpm_iic_try_address.
> Also note the the addition of "| 0x01" to i2c->i2c_i2com.
the updated patch is attached, thanks Joakim.
seems Debora need this too for 2.4 version. Debora, could you please
generate a diff against latest Wolfgang's development tree and submit to
him?
Thanks
--
Aristeu
[-- Attachment #2: i2c_algo_8xx-port_to_2_6.patch --]
[-- Type: text/plain, Size: 17657 bytes --]
8xx: port i2c-algo_8xx to 2.6
Based on Tom Rini's and Joakim Tjernlund's work
Signed-off-by: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
Index: 2.6-8xx/drivers/i2c/algos/i2c-algo-8xx.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ 2.6-8xx/drivers/i2c/algos/i2c-algo-8xx.c 2005-08-08 09:55:30.000000000 -0300
@@ -0,0 +1,617 @@
+/*
+ * i2c-algo-8xx.c i2x driver algorithms for MPC8XX CPM
+ * Copyright (c) 1999 Dan Malek (dmalek@jlc.net).
+ *
+ 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.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * moved into proper i2c interface; separated out platform specific
+ * parts into i2c-rpx.c
+ * Brad Parker (brad@heeltoe.com)
+ */
+
+// XXX todo
+// timeout sleep?
+
+/* $Id: i2c-algo-8xx.c,v 1.7 2002/08/03 22:48:18 ac9410 Exp $ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/version.h>
+#include <linux/init.h>
+#include <asm/uaccess.h>
+#include <linux/ioport.h>
+#include <linux/errno.h>
+#include <linux/sched.h>
+
+#include <asm/mpc8xx.h>
+#include <asm/commproc.h>
+
+#include <linux/i2c.h>
+#include <linux/i2c-algo-8xx.h>
+
+#define CPM_MAX_READ 513
+/* Try uncomment this if you have an older CPU(earlier than rev D4) */
+/* #define I2C_CHIP_ERRATA */
+
+static char *module_name = "i2c_algo_8xx";
+#define DEBUGP(level, x, y...) do { \
+ if (cpm_debug >= level) \
+ printk(KERN_DEBUG "%s: " x, \
+ module_name, ## y); \
+ } while(0)
+
+static wait_queue_head_t iic_wait;
+static ushort r_tbase, r_rbase;
+
+int cpm_scan = 0;
+int cpm_debug = 0;
+
+static void
+cpm_iic_interrupt(void *dev_id, struct pt_regs *regs)
+{
+ volatile i2c8xx_t *i2c = (i2c8xx_t *)dev_id;
+
+ DEBUGP(2, "cpm_iic_interrupt(dev_id=%p)\n", dev_id);
+
+#ifdef I2C_CHIP_ERRATA
+ /* Chip errata, clear enable.
+ * This seems to not be needed on rev D4 or newer CPUs.
+ * Someone with an older CPU needs to verify this.
+ */
+ i2c->i2c_i2mod &= ~1;
+#endif
+
+ /* Clear interrupt.
+ */
+ i2c->i2c_i2cer = 0xff;
+
+ /* Get 'me going again.
+ */
+ wake_up_interruptible(&iic_wait);
+}
+
+static void
+cpm_iic_init(struct i2c_algo_8xx_data *cpm_adap)
+{
+ volatile iic_t *iip = cpm_adap->iip;
+ volatile i2c8xx_t *i2c = cpm_adap->i2c;
+ unsigned char brg;
+ bd_t *bd = (bd_t *)__res;
+
+ DEBUGP(1, "cpm_iic_init() - iip=%p\n", iip);
+
+ /* Initialize the parameter ram.
+ * We need to make sure many things are initialized to zero,
+ * especially in the case of a microcode patch.
+ */
+ iip->iic_rstate = 0;
+ iip->iic_rdp = 0;
+ iip->iic_rbptr = 0;
+ iip->iic_rbc = 0;
+ iip->iic_rxtmp = 0;
+ iip->iic_tstate = 0;
+ iip->iic_tdp = 0;
+ iip->iic_tbptr = 0;
+ iip->iic_tbc = 0;
+ iip->iic_txtmp = 0;
+
+ /* Set up the IIC parameters in the parameter ram.
+ */
+ iip->iic_tbase = r_tbase = cpm_adap->dp_addr;
+ iip->iic_rbase = r_rbase = cpm_adap->dp_addr + sizeof(cbd_t) * 2;
+
+ iip->iic_tfcr = SMC_EB;
+ iip->iic_rfcr = SMC_EB;
+
+ /* Set maximum receive size.
+ */
+ iip->iic_mrblr = CPM_MAX_READ;
+
+ /* Initialize Tx/Rx parameters.
+ */
+ if (cpm_adap->reloc == 0) {
+ volatile cpm8xx_t *cp = cpm_adap->cp;
+
+ cp->cp_cpcr =
+ mk_cr_cmd(CPM_CR_CH_I2C, CPM_CR_INIT_TRX) | CPM_CR_FLG;
+ while (cp->cp_cpcr & CPM_CR_FLG);
+ } else {
+ iip->iic_rbptr = iip->iic_rbase;
+ iip->iic_tbptr = iip->iic_tbase;
+ iip->iic_rstate = 0;
+ iip->iic_tstate = 0;
+ }
+
+ /* Select an arbitrary address. Just make sure it is unique.
+ */
+ i2c->i2c_i2add = 0xfe;
+
+ /* Make clock run at 60 KHz.
+ */
+ brg = (unsigned char) (bd->bi_intfreq/(32*2*60000) -3);
+ i2c->i2c_i2brg = brg;
+
+ i2c->i2c_i2mod = 0x00;
+ i2c->i2c_i2com = 0x01; /* Master mode */
+
+ /* Disable interrupts.
+ */
+ i2c->i2c_i2cmr = 0;
+ i2c->i2c_i2cer = 0xff;
+
+ init_waitqueue_head(&iic_wait);
+
+ /* Install interrupt handler.
+ */
+ DEBUGP(1, "Install ISR for IRQ %d\n", CPMVEC_I2C);
+ cpm_install_handler(CPMVEC_I2C, cpm_iic_interrupt, (void *)i2c);
+}
+
+
+static int
+cpm_iic_shutdown(struct i2c_algo_8xx_data *cpm_adap)
+{
+ volatile i2c8xx_t *i2c = cpm_adap->i2c;
+
+ /* Shut down IIC.
+ */
+ i2c->i2c_i2mod &= ~1;
+ i2c->i2c_i2cmr = 0;
+ i2c->i2c_i2cer = 0xff;
+
+ return 0;
+}
+
+static void
+cpm_reset_iic_params(volatile iic_t *iip)
+{
+ iip->iic_tbase = r_tbase;
+ iip->iic_rbase = r_rbase;
+
+ iip->iic_tfcr = SMC_EB;
+ iip->iic_rfcr = SMC_EB;
+
+ iip->iic_mrblr = CPM_MAX_READ;
+
+ iip->iic_rstate = 0;
+ iip->iic_rdp = 0;
+ iip->iic_rbptr = iip->iic_rbase;
+ iip->iic_rbc = 0;
+ iip->iic_rxtmp = 0;
+ iip->iic_tstate = 0;
+ iip->iic_tdp = 0;
+ iip->iic_tbptr = iip->iic_tbase;
+ iip->iic_tbc = 0;
+ iip->iic_txtmp = 0;
+}
+
+#define BD_SC_NAK ((ushort)0x0004) /* NAK - did not respond */
+#define BD_SC_OV ((ushort)0x0002) /* OV - receive overrun */
+#define CPM_CR_CLOSE_RXBD ((ushort)0x0007)
+
+static void force_close(struct i2c_algo_8xx_data *cpm)
+{
+ volatile i2c8xx_t *i2c = cpm->i2c;
+ if (cpm->reloc == 0) { /* micro code disabled */
+ volatile cpm8xx_t *cp = cpm->cp;
+
+ DEBUGP(1, "force_close()\n");
+ cp->cp_cpcr =
+ mk_cr_cmd(CPM_CR_CH_I2C, CPM_CR_CLOSE_RXBD) |
+ CPM_CR_FLG;
+
+ while (cp->cp_cpcr & CPM_CR_FLG);
+ }
+ i2c->i2c_i2cmr = 0x00; /* Disable all interrupts */
+ i2c->i2c_i2cer = 0xff;
+}
+
+
+/* Read from IIC...
+ * abyte = address byte, with r/w flag already set
+ */
+static int
+cpm_iic_read(struct i2c_algo_8xx_data *cpm, u_char abyte, char *buf, int count)
+{
+ volatile iic_t *iip = cpm->iip;
+ volatile i2c8xx_t *i2c = cpm->i2c;
+ volatile cpm8xx_t *cp = cpm->cp;
+ volatile cbd_t *tbdf, *rbdf;
+ u_char *tb;
+ unsigned long flags, tmo;
+
+ if (count >= CPM_MAX_READ)
+ return -EINVAL;
+
+ /* check for and use a microcode relocation patch */
+ if (cpm->reloc)
+ cpm_reset_iic_params(iip);
+
+ tbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_tbase];
+ rbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_rbase];
+
+ /* To read, we need an empty buffer of the proper length.
+ * All that is used is the first byte for address, the remainder
+ * is just used for timing (and doesn't really have to exist).
+ */
+ tb = cpm->temp;
+ tb = (u_char *)(((uint)tb + 15) & ~15);
+ tb[0] = abyte; /* Device address byte w/rw flag */
+
+ flush_dcache_range((unsigned long) tb, (unsigned long) (tb + 1));
+
+ DEBUGP(1, "cpm_iic_read(abyte=0x%x)\n", abyte);
+
+ tbdf->cbd_bufaddr = __pa(tb);
+ tbdf->cbd_datlen = count + 1;
+ tbdf->cbd_sc =
+ BD_SC_READY | BD_SC_LAST |
+ BD_SC_WRAP | BD_IIC_START;
+
+ iip->iic_mrblr = count + 1; /* prevent excessive read, +1
+ is needed otherwise will the
+ RXB interrupt come too early */
+
+ /* flush will invalidate too. */
+ flush_dcache_range((unsigned long) buf, (unsigned long) (buf+count));
+
+ rbdf->cbd_datlen = 0;
+ rbdf->cbd_bufaddr = __pa(buf);
+
+ rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP| BD_SC_INTRPT;
+
+ /* Chip bug, set enable here */
+ local_irq_save(flags);
+ i2c->i2c_i2cmr = 0x13; /* Enable some interupts */
+ i2c->i2c_i2cer = 0xff;
+ i2c->i2c_i2mod |= 1; /* Enable */
+ /*
+ * Begin transmission and force master.
+ * Some errors(CL) clears the M/S bit
+ */
+ i2c->i2c_i2com |= 0x80 | 0x01;
+
+ /* Wait for IIC transfer */
+ tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ);
+ local_irq_restore(flags);
+
+ if (signal_pending(current) || !tmo){
+ force_close(cpm);
+ DEBUGP(1, "IIC read: timeout!\n");
+ return -EIO;
+ }
+#ifdef I2C_CHIP_ERRATA
+ /* Chip errata, clear enable. This is not needed on rev D4 CPUs.
+ Disabling I2C too early may cause too short stop condition */
+ udelay(4);
+ i2c->i2c_i2mod &= ~1;
+#endif
+
+ DEBUGP(1, "tx sc %04x, rx sc %04x\n", tbdf->cbd_sc, rbdf->cbd_sc);
+
+ if (tbdf->cbd_sc & BD_SC_READY) {
+ printk(KERN_INFO "IIC read; complete but tbuf ready\n");
+ force_close(cpm);
+ printk(KERN_INFO "tx sc %04x, rx sc %04x\n",
+ tbdf->cbd_sc, rbdf->cbd_sc);
+ }
+
+ if (tbdf->cbd_sc & BD_SC_NAK) {
+ DEBUGP(1, "IIC read; no ack\n");
+ return -EREMOTEIO;
+ }
+
+ if (rbdf->cbd_sc & BD_SC_EMPTY) {
+ /* force_close(cpm); */
+ DEBUGP(1, "IIC read; complete but rbuf empty\n");
+ DEBUGP(1, "tx sc %04x, rx sc %04x\n", tbdf->cbd_sc, rbdf->cbd_sc);
+ return -EREMOTEIO;
+ }
+
+ if (rbdf->cbd_sc & BD_SC_OV) {
+ DEBUGP(1, "IIC read; Overrun\n");
+ return -EREMOTEIO;;
+ }
+
+ DEBUGP(1, "read %d bytes\n", rbdf->cbd_datlen);
+
+ if (rbdf->cbd_datlen < count) {
+ DEBUGP(1, "IIC read; short, wanted %d got %d\n", count,
+ rbdf->cbd_datlen);
+ return 0;
+ }
+
+ return count;
+}
+
+/* Write to IIC...
+ * addr = address byte, with r/w flag already set
+ */
+static int
+cpm_iic_write(struct i2c_algo_8xx_data *cpm, u_char abyte, char *buf,int count)
+{
+ volatile iic_t *iip = cpm->iip;
+ volatile i2c8xx_t *i2c = cpm->i2c;
+ volatile cpm8xx_t *cp = cpm->cp;
+ volatile cbd_t *tbdf;
+ u_char *tb;
+ unsigned long flags, tmo;
+
+ /* check for and use a microcode relocation patch */
+ if (cpm->reloc)
+ cpm_reset_iic_params(iip);
+ tb = cpm->temp;
+ tb = (u_char *)(((uint)tb + 15) & ~15);
+ *tb = abyte; /* Device address byte w/rw flag */
+
+ flush_dcache_range((unsigned long) tb, (unsigned long) (tb+1));
+ flush_dcache_range((unsigned long) buf, (unsigned long) (buf+count));
+
+ DEBUGP(1, "cpm_iic_write(abyte=0x%x)\n", abyte);
+
+ /* set up 2 descriptors */
+ tbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_tbase];
+
+ tbdf[0].cbd_bufaddr = __pa(tb);
+ tbdf[0].cbd_datlen = 1;
+ tbdf[0].cbd_sc = BD_SC_READY | BD_IIC_START;
+
+ tbdf[1].cbd_bufaddr = __pa(buf);
+ tbdf[1].cbd_datlen = count;
+ tbdf[1].cbd_sc = BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP;
+
+ /* Chip bug, set enable here */
+ local_irq_save(flags);
+ i2c->i2c_i2cmr = 0x13; /* Enable some interupts */
+ i2c->i2c_i2cer = 0xff;
+ i2c->i2c_i2mod |= 1; /* Enable */
+ /*
+ * Begin transmission and force master.
+ * Some errors(CL) clears the M/S bit
+ */
+ i2c->i2c_i2com |= 0x80 | 0x01;
+
+ /* Wait for IIC transfer */
+ tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ);
+ local_irq_restore(flags);
+
+ if (signal_pending(current) || !tmo){
+ force_close(cpm);
+ if (!tmo)
+ DEBUGP(1, "IIC write: timeout!\n");
+ return -EIO;
+ }
+
+#if I2C_CHIP_ERRATA
+ /* Chip errata, clear enable. This is not needed on rev D4 CPUs.
+ Disabling I2C too early may cause too short stop condition */
+ udelay(4);
+ i2c->i2c_i2mod &= ~1;
+#endif
+ DEBUGP(1, "tx0 sc %04x, tx1 sc %04x\n", tbdf[0].cbd_sc,
+ tbdf[1].cbd_sc);
+
+ if ((tbdf[0].cbd_sc | tbdf[1].cbd_sc) & BD_SC_NAK) {
+ DEBUGP(1, "IIC write; no ack\n");
+ return 0;
+ }
+
+ if ((tbdf[0].cbd_sc | tbdf[1].cbd_sc) & BD_SC_READY) {
+ DEBUGP(1, "IIC write; complete but tbuf ready\n");
+ return 0;
+ }
+
+ return count;
+}
+
+/* See if an IIC address exists..
+ * addr = 7 bit address, unshifted
+ */
+static int
+cpm_iic_tryaddress(struct i2c_algo_8xx_data *cpm, int addr)
+{
+ volatile iic_t *iip = cpm->iip;
+ volatile i2c8xx_t *i2c = cpm->i2c;
+ volatile cpm8xx_t *cp = cpm->cp;
+ volatile cbd_t *tbdf, *rbdf;
+ u_char *tb;
+ unsigned long flags, len, tmo;
+
+ DEBUGP(2, "cpm_iic_tryaddress(cpm=%p,addr=%d)\n", cpm, addr);
+
+ /* check for and use a microcode relocation patch */
+ if (cpm->reloc)
+ cpm_reset_iic_params(iip);
+
+ if (addr == 0) {
+ DEBUGP(1, "iip %p, dp_addr 0x%x\n", cpm->iip, cpm->dp_addr);
+ DEBUGP(1, "iic_tbase %d, r_tbase %d\n", iip->iic_tbase,
+ r_tbase);
+ }
+
+ tbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_tbase];
+ rbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_rbase];
+
+ tb = cpm->temp;
+ tb = (u_char *)(((uint)tb + 15) & ~15);
+
+ /* do a simple read */
+ tb[0] = (addr << 1) | 1; /* device address (+ read) */
+ len = 2;
+
+ flush_dcache_range((unsigned long) tb, (unsigned long) (tb+1));
+
+ tbdf->cbd_bufaddr = __pa(tb);
+ tbdf->cbd_datlen = len;
+ tbdf->cbd_sc =
+ BD_SC_READY | BD_SC_LAST |
+ BD_SC_WRAP | BD_IIC_START;
+
+ rbdf->cbd_datlen = 0;
+ rbdf->cbd_bufaddr = __pa(tb+2);
+ rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP | BD_SC_INTRPT;
+
+ /* Chip bug, set enable here */
+ local_irq_save(flags);
+ i2c->i2c_i2cmr = 0x13; /* Enable some interupts */
+ i2c->i2c_i2cer = 0xff;
+ i2c->i2c_i2mod |= 1; /* Enable */
+ /*
+ * Begin transmission and force master.
+ * Some errors(CL) clears the M/S bit
+ */
+ i2c->i2c_i2com |= 0x80 | 0x01;
+
+ /* Wait for IIC transfer */
+ tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ);
+ local_irq_restore(flags);
+
+#ifdef I2C_CHIP_ERRATA
+ /* Chip errata, clear enable. This is not needed on rev D4 CPUs.
+ Disabling I2C too early may cause too short stop condition */
+ udelay(4);
+ i2c->i2c_i2mod &= ~1;
+#endif
+
+ if (signal_pending(current) || !tmo){
+ force_close(cpm);
+ if (!tmo)
+ DEBUGP(1, "IIC tryaddress: timeout!\n");
+ return -EIO;
+ }
+
+ DEBUGP(2, "back from sleep\n");
+
+ if (tbdf->cbd_sc & BD_SC_NAK) {
+ DEBUGP(2, "IIC try; no ack\n");
+ return 0;
+ }
+
+ if (tbdf->cbd_sc & BD_SC_READY)
+ printk(KERN_INFO "IIC try; complete but tbuf ready\n");
+
+ return 1;
+}
+
+static int cpm_xfer(struct i2c_adapter *i2c_adap,
+ struct i2c_msg msgs[],
+ int num)
+{
+ struct i2c_algo_8xx_data *adap = i2c_adap->algo_data;
+ struct i2c_msg *pmsg;
+ int i, ret;
+ u_char addr;
+
+ for (i = 0; i < num; i++) {
+ pmsg = &msgs[i];
+
+ DEBUGP(1, "#%d addr=0x%x flags=0x%x len=%d\n buf=%p\n",
+ i, pmsg->addr, pmsg->flags, pmsg->len, pmsg->buf);
+
+ addr = pmsg->addr << 1;
+ if (pmsg->flags & I2C_M_RD)
+ addr |= 1;
+ if (pmsg->flags & I2C_M_REV_DIR_ADDR)
+ addr ^= 1;
+
+ if (pmsg->flags & I2C_M_RD) {
+ /* read bytes into buffer*/
+ ret = cpm_iic_read(adap, addr, pmsg->buf, pmsg->len);
+ DEBUGP(1, "read %d bytes\n", ret);
+ if (ret < pmsg->len)
+ return (ret < 0)? ret:-EREMOTEIO;
+ } else {
+ /* write bytes from buffer */
+ ret = cpm_iic_write(adap, addr, pmsg->buf, pmsg->len);
+ DEBUGP(1, "wrote %d\n", ret);
+ if (ret < pmsg->len)
+ return (ret < 0)? ret:-EREMOTEIO;
+ }
+ }
+ return num;
+}
+
+static u32 cpm_func(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR |
+ I2C_FUNC_PROTOCOL_MANGLING;
+}
+
+static struct i2c_algorithm i2c_algo_8xx = {
+ .name = "MPC8xx CPM algorithm",
+ .id = I2C_ALGO_MPC8XX,
+ .master_xfer = cpm_xfer,
+ .functionality = cpm_func,
+};
+
+/*
+ * registering functions to load algorithms at runtime
+ */
+int i2c_8xx_add_bus(struct i2c_adapter *adap)
+{
+ int i;
+ struct i2c_algo_8xx_data *cpm_adap = adap->algo_data;
+
+ DEBUGP(1, "hw routines for %s registered.\n", adap->name);
+
+ /* register new adapter to i2c module... */
+
+ adap->id |= i2c_algo_8xx.id;
+ adap->algo = &i2c_algo_8xx;
+
+ i2c_add_adapter(adap);
+ cpm_iic_init(cpm_adap);
+
+ /* scan bus */
+ if (cpm_scan) {
+ printk(KERN_INFO "%s: scanning bus %s...\n", module_name,
+ adap->name);
+ for (i = 0; i < 128; i++)
+ if (cpm_iic_tryaddress(cpm_adap, i)) {
+ printk("(%02x)", i << 1);
+ }
+ printk("\n");
+ }
+ return 0;
+}
+
+int i2c_8xx_del_bus(struct i2c_adapter *adap)
+{
+ int res;
+ struct i2c_algo_8xx_data *cpm_adap = adap->algo_data;
+
+ cpm_iic_shutdown(cpm_adap);
+
+ if ((res = i2c_del_adapter(adap)) < 0)
+ return res;
+
+ printk(KERN_INFO "%s: adapter unregistered: %s\n", module_name,
+ adap->name);
+
+ return 0;
+}
+
+module_param(cpm_debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(cpm_debug, "Sets the debug level. (0 = none, 1 = normal, "
+ ">1 = plenty");
+MODULE_AUTHOR("Brad Parker <brad@heeltoe.com>");
+MODULE_DESCRIPTION("I2C-Bus MPC8XX algorithm");
+MODULE_LICENSE("GPL");
+
+EXPORT_SYMBOL(i2c_8xx_add_bus);
+EXPORT_SYMBOL(i2c_8xx_del_bus);
+
Index: 2.6-8xx/drivers/i2c/algos/Makefile
===================================================================
--- 2.6-8xx.orig/drivers/i2c/algos/Makefile 2005-08-08 09:50:57.000000000 -0300
+++ 2.6-8xx/drivers/i2c/algos/Makefile 2005-08-08 09:50:59.000000000 -0300
@@ -8,6 +8,7 @@
obj-$(CONFIG_I2C_ALGOITE) += i2c-algo-ite.o
obj-$(CONFIG_I2C_ALGO_SIBYTE) += i2c-algo-sibyte.o
obj-$(CONFIG_I2C_ALGO_SGI) += i2c-algo-sgi.o
+obj-$(CONFIG_I2C_ALGO8XX) += i2c-algo-8xx.o
ifeq ($(CONFIG_I2C_DEBUG_ALGO),y)
EXTRA_CFLAGS += -DDEBUG
Index: 2.6-8xx/include/linux/i2c-algo-8xx.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ 2.6-8xx/include/linux/i2c-algo-8xx.h 2005-08-08 09:50:59.000000000 -0300
@@ -0,0 +1,28 @@
+/* ------------------------------------------------------------------------- */
+/* i2c-algo-8xx.h i2c driver algorithms for MPX8XX CPM */
+/* ------------------------------------------------------------------------- */
+
+/* $Id$ */
+
+#ifndef I2C_ALGO_8XX_H
+#define I2C_ALGO_8XX_H
+
+#include <linux/i2c.h>
+#include <asm/8xx_immap.h>
+#include <asm/commproc.h>
+
+struct i2c_algo_8xx_data {
+ uint dp_addr;
+ int reloc;
+ volatile i2c8xx_t *i2c;
+ volatile iic_t *iip;
+ volatile cpm8xx_t *cp;
+
+ u_char temp[513];
+};
+
+int i2c_8xx_add_bus(struct i2c_adapter *);
+int i2c_8xx_del_bus(struct i2c_adapter *);
+
+#endif /* I2C_ALGO_8XX_H */
+
^ permalink raw reply
* RE: MPC885ADS and 2.6.13-rc5 - nogo ?
From: Schaefer-Hutter, Peter @ 2005-08-08 9:37 UTC (permalink / raw)
To: linuxppc-embedded list
Hello!
> From: aris@cathedrallabs.org [mailto:aris@cathedrallabs.org]=20
> Sent: Friday, August 05, 2005 6:26 PM
>
> > Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:348
> > Call trace:
> > [c0005b10] dump_stack+0x18/0x28
> > [c0003c60] check_bug_trap+0x84/0xac
> > [c0003de8] ProgramCheckException+0x160/0x1a0
> > [c0003260] ret_from_except_full+0x0/0x4c
> > [c01a9f84] dma_alloc_init+0x44/0xa0
> > [c01a66a4] do_initcalls+0x54/0xfc
> > [c0002260] init+0x2c/0xf4
> > [c000533c] kernel_thread+0x44/0x60
> > NET: Registered protocol family 16
> > JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
> > Serial: CPM driver $Revision: 0.01 $
> > ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART
> > ttyCPM1 at MMIO 0xff000a90 (irq =3D 19) is a CPM UART
> just out of curiosity, try changing CONSISTENT_START to 0xe0000000
Well, then the error in dma_alloc_init goes away.
However, i'm still not able to run 2.6.x on the MPC885ADS.
I'm now using 2.6.13-rc6 with the latest cpm-uart-fixes=20
applied. I made the defconfig, set CONSISTENT_START to 0xe0000000
an got:
Linux version 2.6.13-rc6 (root@rcf02) (gcc version 3.3.2) #5 Mon Aug 8
11:22:18 CEST 2005
Built 1 zonelists
Kernel command line: console=3DttyCPM0,38400n8 root=3D/dev/nfs
nfsroot=3D/home/test/nfs rw
ip=3D192.168.1.10:192.168.1.1:192.168.1.1:255.255.255.0::eth0:off
PID hash table entries: 64 (order: 6, 1024 bytes)
Decrementer Frequency =3D 450000000/60
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 6244k available (1432k kernel code, 332k data, 72k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART
ttyCPM1 at MMIO 0xff000a90 (irq =3D 19) is a CPM UART
io scheduler noop registered
PPP generic driver version 2.4.2
PPP Deflate Compression module registere
Looks like the console does not start (maybe still UART-issues)...=20
As some people on this list reported success on MPC885ADS - can somebody
please hit me with the cluebat ?
Best regards,=20
Peter
^ permalink raw reply
* Volunteers to test i2c-algo-8xx on v2.6?
From: Joakim Tjernlund @ 2005-08-08 8:08 UTC (permalink / raw)
To: Linuxppc-Embedded@Ozlabs. Org
Hi
Had a look at my old driver and it needs a little care.
Basically this block has changed
> + if(count > 16){
> + /* Chip bug, set enable here */
> + local_irq_save(flags);
> + i2c->i2c_i2cmr = 0x13; /* Enable some interupts */
> + i2c->i2c_i2cer = 0xff;
> + i2c->i2c_i2mod |= 1; /* Enable */
> + i2c->i2c_i2com |= 0x80; /* Begin transmission */
> +
> + /* Wait for IIC transfer */
> + tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ);
> + local_irq_restore(flags);
> + } else { /* busy wait for small transfers, its faster */
> + i2c->i2c_i2cmr = 0x00; /* Disable I2C interupts */
> + i2c->i2c_i2cer = 0xff;
> + i2c->i2c_i2mod |= 1; /* Enable */
> + i2c->i2c_i2com |= 0x80; /* Begin transmission */
> + tmo = jiffies + 1*HZ;
> + /* Busy wait, with a timeout */
> + while(!(i2c->i2c_i2cer & 0x11 || time_after(jiffies, tmo)));
> + }
into
> + /* Chip bug, set enable here */
> + local_irq_save(flags);
> + i2c->i2c_i2cmr = 0x13; /* Enable some interupts */
> + i2c->i2c_i2cer = 0xff;
> + i2c->i2c_i2mod |= 1; /* Enable */
> + i2c->i2c_i2com |= 0x80 | 0x01; /* Begin transmission and force master.
Some errors(CL) clears the M/S bit */
> +
> + /* Wait for IIC transfer */
> + tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ);
> + local_irq_restore(flags);
I have done this for cpm_iic_read, cpm_iic_write and cpm_iic_try_address.
Also note the the addition of "| 0x01" to i2c->i2c_i2com.
^ permalink raw reply
* Re: mpc 8xx watchdog eldh-3.1.1
From: Wolfgang Denk @ 2005-08-08 8:04 UTC (permalink / raw)
To: Debora Liu; +Cc: Linuxppc-embedded
In-Reply-To: <20050808060541.AD39E4299C@denx.de>
In message <20050808060541.AD39E4299C@denx.de> you wrote:
>
> how do I use watchdog with my userspace interface ?
>
> this wdt_mpc8xx.c is different from standard watchdog userspace interface.
Yes, I know. The "standard" watchdog UI is completely unsufficient
for real world applications.
There is a man page for our driver in Documentation/man4/wdt_mpc8xx.4
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
A person with one watch knows what time it is; a person with two
watches is never sure. Proverb
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 12, Issue 25
From: Anand Kasula @ 2005-08-08 6:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050808014925.6BB8867F40@ozlabs.org>
aGkgaSBhbSBzdGFydGluZyBwcm9qZWN0IG9uIHBvcnRpbmcgZW1iZWRkZWQgbGludXggb24gdG8g
cHEzCnByb2Nlc3NvciwgY2FuIGFueWJvZHkgaGVscCBtZSByZWdhcmRpbmcgdGhpcyB0aGluZy4g
cGxlYXNlIHNlbmQgbWUKdGhlIGRvY3VtZW50YXRpb24gb24gdGhpcy4KCgoKT24gOC84LzA1LCBs
aW51eHBwYy1lbWJlZGRlZC1yZXF1ZXN0QG96bGFicy5vcmcKPGxpbnV4cHBjLWVtYmVkZGVkLXJl
cXVlc3RAb3psYWJzLm9yZz4gd3JvdGU6Cj4gU2VuZCBMaW51eHBwYy1lbWJlZGRlZCBtYWlsaW5n
IGxpc3Qgc3VibWlzc2lvbnMgdG8KPiAJbGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+IAo+
IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNp
dAo+IAlodHRwczovL296bGFicy5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eHBwYy1lbWJlZGRl
ZAo+IG9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdo
ZWxwJyB0bwo+IAlsaW51eHBwYy1lbWJlZGRlZC1yZXF1ZXN0QG96bGFicy5vcmcKPiAKPiBZb3Ug
Y2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQKPiAJbGludXhwcGMtZW1i
ZWRkZWQtb3duZXJAb3psYWJzLm9yZwo+IAo+IFdoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlv
dXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMKPiB0aGFuICJSZTogQ29udGVu
dHMgb2YgTGludXhwcGMtZW1iZWRkZWQgZGlnZXN0Li4uIgo+IAo+IAo+IFRvZGF5J3MgVG9waWNz
Ogo+IAo+ICAgIDEuIFJlOiBbUEFUQ0hdIDh4eDogYWRkIGNwbV9nZXRfY3BtcCgpIChEYW4gTWFs
ZWspCj4gICAgMi4gUmU6IFtQQVRDSF0gOHh4OiBhZGQgY3BtX2dldF9jcG1wKCkgKERhbiBNYWxl
aykKPiAgICAzLiBSZTogW1BBVENIXSA4eHg6IGFkZCBjcG1fZ2V0X2NwbXAoKSAoTWFyY2VsbyBU
b3NhdHRpKQo+ICAgIDQuIEEgY29uZmlndXJlIGVycm9yIGZvciBzYW1iYTMgb24gcHBjIChKb2hu
c29uQ2hlbmcpCj4gICAgNS4gUmU6IFtQQVRDSF0gOHh4OiBhZGQgY3BtX2dldF9jcG1wKCkgKERh
biBNYWxlaykKPiAgICA2LiBSZTogW1BBVENIXSA4eHg6IGFkZCBjcG1fZ2V0X2NwbXAoKQo+ICAg
ICAgIChBcmlzdGV1IFNlcmdpbyBSb3phbnNraSBGaWxobykKPiAgICA3LiBSZTogW1BBVENIXSA4
eHg6IGFkZCBjcG1fZ2V0X2NwbXAoKSAoTWFyY2VsbyBUb3NhdHRpKQo+ICAgIDguIFJlOiBbUEFU
Q0hdIDh4eDogYWRkIGNwbV9nZXRfY3BtcCgpIChEYW4gTWFsZWspCj4gICAgOS4gUmU6IFtQQVRD
SF0gOHh4OiBhZGQgY3BtX2dldF9jcG1wKCkgKEV1Z2VuZSBTdXJvdmVnaW4pCj4gICAxMC4gUmU6
IFZvbHVudGVlcnMgdG8gdGVzdCBpMmMtYWxnby04eHggb24gdjIuNj8gKERlYm9yYSBMaXUpCj4g
Cj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQo+IAo+IE1lc3NhZ2U6IDEKPiBEYXRlOiBTYXQsIDYgQXVnIDIw
MDUgMjI6NDA6MzcgLTA0MDAKPiBGcm9tOiBEYW4gTWFsZWsgPGRhbkBlbWJlZGRlZGVkZ2UuY29t
Pgo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIDh4eDogYWRkIGNwbV9nZXRfY3BtcCgpCj4gVG86IE1h
cmNlbG8gVG9zYXR0aSA8bWFyY2Vsby50b3NhdHRpQGN5Y2xhZGVzLmNvbT4KPiBDYzogbGludXhw
cGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+IE1lc3NhZ2UtSUQ6IDxlNWNhYTgwYTJjZDcyMWE0ZjZl
ZTNjNzRlYWQ5MDZiMkBlbWJlZGRlZGVkZ2UuY29tPgo+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFp
bjsgY2hhcnNldD1VUy1BU0NJSTsgZm9ybWF0PWZsb3dlZAo+IAo+IAo+IE9uIEF1ZyA2LCAyMDA1
LCBhdCA3OjI3IFBNLCBNYXJjZWxvIFRvc2F0dGkgd3JvdGU6Cj4gCj4gPiBJdCBhbHJlYWR5IGlz
IGV4cG9ydGVkLCBkZWNsYXJlZCBhcwo+ID4KPiA+IGNvbW1wcm9jLmg6ZXh0ZXJuICAgICAgIGNw
bTh4eF90ICAgICAgICAqY3BtcDsgICAgICAgICAgLyogUG9pbnRlciB0byAKPiA+IGNvbW0gcHJv
Y2Vzc29yICovCj4gPgo+ID4KPiA+IGFuZCBtYW55IGRyaXZlcnMgdXNlIHRoZSBwb2ludGVyIGRp
cmVjdGx5Lgo+IAo+IFdlIHNob3VsZG4ndCBiZSBkb2luZyB0aGlzLiAgQWxsIGRyaXZlcnMgc2hv
dWxkIGlvcmVtYXAoKSBhbnkKPiBwZXJpcGhlcmFsIHNwYWNlcyB0aGV5IHVzZSBhbmQgbm90IG1h
a2UgYW55IGFzc3VtcHRpb25zCj4gc29tZW9uZSBlbHNlIGhhcyBkb25lIHRoYXQgYWxyZWFkeS4g
IFdlJ3ZlIGJlZW4gbWFraW5nCj4gc3VjaCBjaGFuZ2VzIGluIHRoZSA4Mnh4LzgzeHgvODV4eCBD
UE0yIGRyaXZlcnMuICBJZiBpdAo+IGlzbid0IGNvbnZlbmllbnQgdG8gZmluZCB0aGUgI2RlZmlu
ZXMgZm9yIHRoZSBpb3JlbWFwKCksIHdlCj4gc2hvdWxkIGNoYW5nZSB0aGF0LiAgV2hlbiBJIG9y
aWdpbmFsbHkgd3JvdGUgYWxsIG9mIHRoaXMKPiBjb2RlLCBpdCB3YXMgbG9uZyBhZ28gd2hlbiB3
ZSBkaWRuJ3QgaGF2ZSBzb21lIG9mIHRoZQo+IGFic3RyYWN0aW9ucyBhbmQgaXQgc2VlbWVkIGFu
eSBzaG9ydGN1dHMgZm9yIHBlcmZvcm1hbmNlCj4gd2VyZSBkZXNpcmVkIDotKQo+IAo+IAo+ID4g
YXJjaC9wcGMvODI2MF9pby8gZHJpdmVycyBhbHNvIHVzZSB0aGUgc2FtZSBjb252ZW50aW9uLgo+
IAo+IElmIHRoZXJlIGFyZSBhbnkgZHJpdmVycyBpbiBoZXJlLCB0aGV5IGVpdGhlciBhcmVuJ3Qg
dXNlZCBvcgo+IG9uIHRoZWlyIHdheSBvdXQuICBUaGUgb25seSB0aGluZ3MgdGhhdCBzaG91bGQg
cmVtYWluIGFyZQo+IGNvbW1vbiBzdXBwb3J0IGZ1bmN0aW9ucy4KPiAKPiAKPiBUaGFua3MuCj4g
Cj4gCS0tIERhbgo+IAo+IAo+IAo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IAo+
IE1lc3NhZ2U6IDIKPiBEYXRlOiBTYXQsIDYgQXVnIDIwMDUgMjM6MzY6MTYgLTA0MDAKPiBGcm9t
OiBEYW4gTWFsZWsgPGRhbkBlbWJlZGRlZGVkZ2UuY29tPgo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hd
IDh4eDogYWRkIGNwbV9nZXRfY3BtcCgpCj4gVG86IEFyaXN0ZXUgU2VyZ2lvIFJvemFuc2tpIEZp
bGhvIDxhcmlzQGNhdGhlZHJhbGxhYnMub3JnPgo+IENjOiBsaW51eHBwYy1lbWJlZGRlZEBvemxh
YnMub3JnCj4gTWVzc2FnZS1JRDogPGQ3NGUyNGJiZjgyZTRjZWRkMzM1ODQ2NTM0M2QyOGFlQGVt
YmVkZGVkZWRnZS5jb20+Cj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVTLUFT
Q0lJOyBmb3JtYXQ9Zmxvd2VkCj4gCj4gCj4gT24gQXVnIDYsIDIwMDUsIGF0IDc6NDIgUE0sIEFy
aXN0ZXUgU2VyZ2lvIFJvemFuc2tpIEZpbGhvIHdyb3RlOgo+IAo+ID4gYnV0IG5vdCB3aXRoIEVY
UE9SVF9TWU1CT0woKS4gSSBub3RpY2VkIHRoaXMgd2hpbGUgY29tcGlsaW5nIGkyYyBzdHVmZgo+
ID4gYXMgbW9kdWxlLiBhbHNvLCBJIHRoaW5rIGl0J3MgYmV0dGVyIGFkZCBhIGZ1bmN0aW9uIHRv
IGRvIHRoaXMgaW5zdGVhZAo+ID4gZG9pbmcgRVhQT1JUX1NZTUJPTCgpIGluIGEgdmFyaWFibGUu
Cj4gCj4gUmlnaHQuICBXZSBzaG91bGQganVzdCBpb3JlbWFwKCkgOi0pCj4gCj4gVGhhbmtzLgo+
IAo+IAktLSBEYW4KPiAKPiAKPiAKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAK
PiBNZXNzYWdlOiAzCj4gRGF0ZTogU3VuLCA3IEF1ZyAyMDA1IDAxOjMxOjEwIC0wMzAwCj4gRnJv
bTogTWFyY2VsbyBUb3NhdHRpIDxtYXJjZWxvLnRvc2F0dGlAY3ljbGFkZXMuY29tPgo+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0hdIDh4eDogYWRkIGNwbV9nZXRfY3BtcCgpCj4gVG86IERhbiBNYWxlayA8
ZGFuQGVtYmVkZGVkZWRnZS5jb20+Cj4gQ2M6IGxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcK
PiBNZXNzYWdlLUlEOiA8MjAwNTA4MDcwNDMxMTAuR0E2MzE2QGRtdC5jbmV0Pgo+IENvbnRlbnQt
VHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11cy1hc2NpaQo+IAo+IE9uIFNhdCwgQXVnIDA2LCAy
MDA1IGF0IDEwOjQwOjM3UE0gLTA0MDAsIERhbiBNYWxlayB3cm90ZToKPiA+IAo+ID4gT24gQXVn
IDYsIDIwMDUsIGF0IDc6MjcgUE0sIE1hcmNlbG8gVG9zYXR0aSB3cm90ZToKPiA+IAo+ID4gPkl0
IGFscmVhZHkgaXMgZXhwb3J0ZWQsIGRlY2xhcmVkIGFzCj4gPiA+Cj4gPiA+Y29tbXByb2MuaDpl
eHRlcm4gICAgICAgY3BtOHh4X3QgICAgICAgICpjcG1wOyAgICAgICAgICAvKiBQb2ludGVyIHRv
IAo+ID4gPmNvbW0gcHJvY2Vzc29yICovCj4gPiA+Cj4gPiA+Cj4gPiA+YW5kIG1hbnkgZHJpdmVy
cyB1c2UgdGhlIHBvaW50ZXIgZGlyZWN0bHkuCj4gPiAKPiA+IFdlIHNob3VsZG4ndCBiZSBkb2lu
ZyB0aGlzLiAgQWxsIGRyaXZlcnMgc2hvdWxkIGlvcmVtYXAoKSBhbnkKPiA+IHBlcmlwaGVyYWwg
c3BhY2VzIHRoZXkgdXNlIGFuZCBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbnMKPiA+IHNvbWVvbmUg
ZWxzZSBoYXMgZG9uZSB0aGF0IGFscmVhZHkuICBXZSd2ZSBiZWVuIG1ha2luZwo+ID4gc3VjaCBj
aGFuZ2VzIGluIHRoZSA4Mnh4LzgzeHgvODV4eCBDUE0yIGRyaXZlcnMuICBJZiBpdAo+ID4gaXNu
J3QgY29udmVuaWVudCB0byBmaW5kIHRoZSAjZGVmaW5lcyBmb3IgdGhlIGlvcmVtYXAoKSwgd2UK
PiA+IHNob3VsZCBjaGFuZ2UgdGhhdC4gIFdoZW4gSSBvcmlnaW5hbGx5IHdyb3RlIGFsbCBvZiB0
aGlzCj4gPiBjb2RlLCBpdCB3YXMgbG9uZyBhZ28gd2hlbiB3ZSBkaWRuJ3QgaGF2ZSBzb21lIG9m
IHRoZQo+ID4gYWJzdHJhY3Rpb25zIGFuZCBpdCBzZWVtZWQgYW55IHNob3J0Y3V0cyBmb3IgcGVy
Zm9ybWFuY2UKPiA+IHdlcmUgZGVzaXJlZCA6LSkKPiAKPiBPSyBtYWtlcyBzZW5zZSAoeWVwIGl0
IHdhcyBldmVuIGRpc2N1c3NlZCBhbHJlYWR5KS4KPiAKPiBBcmlzLCBzb3VuZHMgbGlrZSB5b3Ug
c2hvdWxkIHByb2NlZWQgd2l0aCBjcG1fZ2V0X2NwbXAoKSBhbmQgY2hhbmdlIGFsbAo+IG90aGVy
IGRyaXZlcnMgdXNpbmcgaXQgYWxzby4KPiAKPiA+IAo+ID4gCj4gPiA+YXJjaC9wcGMvODI2MF9p
by8gZHJpdmVycyBhbHNvIHVzZSB0aGUgc2FtZSBjb252ZW50aW9uLgo+ID4gCj4gPiBJZiB0aGVy
ZSBhcmUgYW55IGRyaXZlcnMgaW4gaGVyZSwgdGhleSBlaXRoZXIgYXJlbid0IHVzZWQgb3IKPiA+
IG9uIHRoZWlyIHdheSBvdXQuICBUaGUgb25seSB0aGluZ3MgdGhhdCBzaG91bGQgcmVtYWluIGFy
ZQo+ID4gY29tbW9uIHN1cHBvcnQgZnVuY3Rpb25zLgo+IAo+IE9LIQo+IAo+IAo+IC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IAo+IE1lc3NhZ2U6IDQKPiBEYXRlOiBTdW4sIDcgQXVn
IDIwMDUgMTc6MTU6NTUgKzA4MDAKPiBGcm9tOiAiSm9obnNvbkNoZW5nIiA8am9obnNvbmNoZW5n
QHFuYXAuY29tLnR3Pgo+IFN1YmplY3Q6IEEgY29uZmlndXJlIGVycm9yIGZvciBzYW1iYTMgb24g
cHBjCj4gVG86IDxsaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnPgo+IE1lc3NhZ2UtSUQ6IDwy
MDA1MDgwNzA5MTYwMy5DRTU3NjY3RjI5QG96bGFicy5vcmc+Cj4gQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSIKPiAKPiBXaGVuIEkgY29uZmlndXJlIHNhbWJhMy4w
LjEwIG9uIHBwYyBhcyBmb2xsb3dpbmcgY29tbWFuZDoKPiAKPiBDQz1wb3dlcnBjLWxpbnV4LWdj
YyBBUj1wb3dlcnBjLWxpbnV4LWFyIFJBTkxJQj1wb3dlcnBjLWxpbnV4LXJhbmxpYgo+IC4vY29u
ZmlndXJlIC1ob3N0PXBvd2VycGMtbGludXgKPiAKPiAgCj4gCj4gSSBnb3QgYSBjb25maWd1cmUg
ZXJyb3IgbWVzc2FnZSBhcyBmb2xsb3dpbmc6Cj4gCj4gQ29uZmlndXJlOiBlcnJvcjogY2Fubm90
IHJ1biB0ZXN0IHByb2dyYW0gd2hpbGUgY3Jvc3MgY29tcGlsaW5nCj4gCj4gU2VlICdjb25maWcu
bG9nJyBmb3IgbW9yZSBkZXRhaWxzCj4gCj4gIAo+IAo+IEkgdGhpbmsgdGhpcyBpcyBhIHNhbWJh
IGNvbmZpZ3VyZSBidWcsIGRvIGFueWJvZHkga25vdyBob3cgdG8gcGFzcyBpdD8KPiAKPiAgCj4g
Cj4gVGhhbmtzLAo+IAo+IEpvaG5zb24gQ2hlbmcKPiAKPiAtLS0tLS0tLS0tLS0tLSBuZXh0IHBh
cnQgLS0tLS0tLS0tLS0tLS0KPiBBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uCj4g
VVJMOgo+IGh0dHA6Ly9vemxhYnMub3JnL3BpcGVybWFpbC9saW51eHBwYy1lbWJlZGRlZC9hdHRh
Y2htZW50cy8yMDA1MDgwNy85NWYyMzU5Ny9hdHRhY2htZW50LTAwMDEuaHRtCj4gCj4gLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gCj4gTWVzc2FnZTogNQo+IERhdGU6IFN1biwgNyBB
dWcgMjAwNSAxMTozOTo1MiAtMDQwMAo+IEZyb206IERhbiBNYWxlayA8ZGFuQGVtYmVkZGVkZWRn
ZS5jb20+Cj4gU3ViamVjdDogUmU6IFtQQVRDSF0gOHh4OiBhZGQgY3BtX2dldF9jcG1wKCkKPiBU
bzogTWFyY2VsbyBUb3NhdHRpIDxtYXJjZWxvLnRvc2F0dGlAY3ljbGFkZXMuY29tPgo+IENjOiBs
aW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnCj4gTWVzc2FnZS1JRDogPDA5YjA3OTJmNDI2ZjFk
NTg4M2NmNWQ0Mzc3MjNmMDc1QGVtYmVkZGVkZWRnZS5jb20+Cj4gQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluOyBjaGFyc2V0PVVTLUFTQ0lJOyBmb3JtYXQ9Zmxvd2VkCj4gCj4gCj4gT24gQXVnIDcs
IDIwMDUsIGF0IDEyOjMxIEFNLCBNYXJjZWxvIFRvc2F0dGkgd3JvdGU6Cj4gCj4gPiBBcmlzLCBz
b3VuZHMgbGlrZSB5b3Ugc2hvdWxkIHByb2NlZWQgd2l0aCBjcG1fZ2V0X2NwbXAoKSBhbmQgY2hh
bmdlIGFsbAo+ID4gb3RoZXIgZHJpdmVycyB1c2luZyBpdCBhbHNvLgo+IAo+IEl0IGRlcGVuZHMg
aG93IHlvdSBkZWZpbmUgdGhlIHNlbWFudGljcyBvZiB0aGlzIGZ1bmN0aW9uIGNhbGwuCj4gQ2Fu
IHlvdSBjYWxsIGl0IGFueSAoYW5kIGFsbCBvZiB0aGUpIHRpbWUgeW91IG5lZWQgaXQsIG9yIGRv
ZXMgaXQKPiBhY3R1YWxseSBwZXJmb3JtIGFuIGlvcmVtYXAoKSBhbmQgeW91IG9ubHkgd2FudCB0
byBjYWxsIGl0Cj4gb25jZT8KPiAKPiBJIGd1ZXNzIGltcGxlbWVudGVkIHByb3Blcmx5IGl0IGRv
ZXNuJ3QgbWF0dGVyLiAgT24gdGhlIGZpcnN0Cj4gY2FsbCBpdCBzaG91bGQgZG8gdGhlIGlvcmVt
YXAoKSBhbmQgb24gc3Vic2VxdWVudCBjYWxscyBpdAo+IGp1c3QgcmV0dXJucyB0aGUgbWFwcGlu
Zy4gIFRoaXMgaXMgb25lIG9mIHRob3NlIGNvbW1vbgo+IGZ1bmN0aW9ucyB0aGF0IHNob3VsZCBi
ZSBpbiBjb21tcHJvYy5jLgo+IAo+IFRoYW5rcy4KPiAKPiAJLS0gRGFuCj4gCj4gCj4gCj4gLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gCj4gTWVzc2FnZTogNgo+IERhdGU6IFN1biwg
NyBBdWcgMjAwNSAxMjo0NDozMiAtMDMwMAo+IEZyb206IEFyaXN0ZXUgU2VyZ2lvIFJvemFuc2tp
IEZpbGhvIDxhcmlzQGNhdGhlZHJhbGxhYnMub3JnPgo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIDh4
eDogYWRkIGNwbV9nZXRfY3BtcCgpCj4gVG86IERhbiBNYWxlayA8ZGFuQGVtYmVkZGVkZWRnZS5j
b20+Cj4gQ2M6IGxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcKPiBNZXNzYWdlLUlEOiA8MjAw
NTA4MDcxNTQ0MzIuR0U1MjEwQGNhdGhlZHJhbGxhYnMub3JnPgo+IENvbnRlbnQtVHlwZTogdGV4
dC9wbGFpbjsgY2hhcnNldD11cy1hc2NpaQo+IAo+ID4gSXQgZGVwZW5kcyBob3cgeW91IGRlZmlu
ZSB0aGUgc2VtYW50aWNzIG9mIHRoaXMgZnVuY3Rpb24gY2FsbC4KPiA+IENhbiB5b3UgY2FsbCBp
dCBhbnkgKGFuZCBhbGwgb2YgdGhlKSB0aW1lIHlvdSBuZWVkIGl0LCBvciBkb2VzIGl0Cj4gPiBh
Y3R1YWxseSBwZXJmb3JtIGFuIGlvcmVtYXAoKSBhbmQgeW91IG9ubHkgd2FudCB0byBjYWxsIGl0
Cj4gPiBvbmNlPwo+IHdoYXQgYWJvdXQgZG9uJ3QgY2FjaGUgaXQgYW5kIGNhbGwgaW9yZW1hcCgp
IGZyb20gZHJpdmVyPyAoSSBndWVzcwo+IGlvcmVtYXAoKSBhbHJlYWR5IGNoZWNrIGlmIGFuIGFy
ZWEgaXMgYWxyZWFkeSBtYXBwZWQsIG5vPykKPiAKPiAtLQo+IEFyaXN0ZXUKPiAKPiAKPiAKPiAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAKPiBNZXNzYWdlOiA3Cj4gRGF0ZTogU3Vu
LCA3IEF1ZyAyMDA1IDEyOjU3OjMxIC0wMzAwCj4gRnJvbTogTWFyY2VsbyBUb3NhdHRpIDxtYXJj
ZWxvLnRvc2F0dGlAY3ljbGFkZXMuY29tPgo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIDh4eDogYWRk
IGNwbV9nZXRfY3BtcCgpCj4gVG86IEFyaXN0ZXUgU2VyZ2lvIFJvemFuc2tpIEZpbGhvIDxhcmlz
QGNhdGhlZHJhbGxhYnMub3JnPgo+IENjOiBsaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnCj4g
TWVzc2FnZS1JRDogPDIwMDUwODA3MTU1NzMxLkdBMjcxNUBkbXQuY25ldD4KPiBDb250ZW50LVR5
cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXMtYXNjaWkKPiAKPiBPbiBTdW4sIEF1ZyAwNywgMjAw
NSBhdCAxMjo0NDozMlBNIC0wMzAwLCBBcmlzdGV1IFNlcmdpbyBSb3phbnNraSBGaWxobwo+IHdy
b3RlOgo+ID4gPiBJdCBkZXBlbmRzIGhvdyB5b3UgZGVmaW5lIHRoZSBzZW1hbnRpY3Mgb2YgdGhp
cyBmdW5jdGlvbiBjYWxsLgo+ID4gPiBDYW4geW91IGNhbGwgaXQgYW55IChhbmQgYWxsIG9mIHRo
ZSkgdGltZSB5b3UgbmVlZCBpdCwgb3IgZG9lcyBpdAo+ID4gPiBhY3R1YWxseSBwZXJmb3JtIGFu
IGlvcmVtYXAoKSBhbmQgeW91IG9ubHkgd2FudCB0byBjYWxsIGl0Cj4gPiA+IG9uY2U/Cj4gPiB3
aGF0IGFib3V0IGRvbid0IGNhY2hlIGl0IGFuZCBjYWxsIGlvcmVtYXAoKSBmcm9tIGRyaXZlcj8g
KEkgZ3Vlc3MKPiA+IGlvcmVtYXAoKSBhbHJlYWR5IGNoZWNrIGlmIGFuIGFyZWEgaXMgYWxyZWFk
eSBtYXBwZWQsIG5vPykKPiAKPiBZZXAsIGlvcmVtYXAoKSBzaG91bGQgYmUgZG9pbmcgdmlydHVh
bCBhZGRyZXNzIGNhY2hpbmcgYWxyZWFkeSwgbm8/Cj4gCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCj4gCj4gTWVzc2FnZTogOAo+IERhdGU6IFN1biwgNyBBdWcgMjAwNSAxMzoy
NTozNCAtMDQwMAo+IEZyb206IERhbiBNYWxlayA8ZGFuQGVtYmVkZGVkZWRnZS5jb20+Cj4gU3Vi
amVjdDogUmU6IFtQQVRDSF0gOHh4OiBhZGQgY3BtX2dldF9jcG1wKCkKPiBUbzogQXJpc3RldSBT
ZXJnaW8gUm96YW5za2kgRmlsaG8gPGFyaXNAY2F0aGVkcmFsbGFicy5vcmc+Cj4gQ2M6IGxpbnV4
cHBjLWVtYmVkZGVkQG96bGFicy5vcmcKPiBNZXNzYWdlLUlEOiA8MmZjZDhhMzI5MjQ2YjJmMmMz
MDNlNTE1ZGQwY2I3YmZAZW1iZWRkZWRlZGdlLmNvbT4KPiBDb250ZW50LVR5cGU6IHRleHQvcGxh
aW47IGNoYXJzZXQ9VVMtQVNDSUk7IGZvcm1hdD1mbG93ZWQKPiAKPiAKPiBPbiBBdWcgNywgMjAw
NSwgYXQgMTE6NDQgQU0sIEFyaXN0ZXUgU2VyZ2lvIFJvemFuc2tpIEZpbGhvIHdyb3RlOgo+IAo+
ID4gd2hhdCBhYm91dCBkb24ndCBjYWNoZSBpdCBhbmQgY2FsbCBpb3JlbWFwKCkgZnJvbSBkcml2
ZXI/IChJIGd1ZXNzCj4gPiBpb3JlbWFwKCkgYWxyZWFkeSBjaGVjayBpZiBhbiBhcmVhIGlzIGFs
cmVhZHkgbWFwcGVkLCBubz8pCj4gCj4gRWl0aGVyIHdheS4gIEknbSBhY3R1YWxseSBsZWFuaW5n
IHRvd2FyZCB0aGVzZSAicG9pbnRlciBoZWxwZXIiCj4gZnVuY3Rpb25zLiA6LSkgIFNvbWV0aGlu
ZyBsaWtlIGdldF9jcG1wKCksIG9yIGdldF9pbW1yKCksIHRoYXQgd2lsbAo+IGhpZGUgdGhlIGRl
dGFpbHMgb2YgdGhlIG1hcHBpbmcsIHNvIHlvdSBkb24ndCBoYXZlIHRvIGluY2x1ZGUKPiBhbmQg
a25vdyB3aGljaCAjZGVmaW5lcyB0byB1c2UgYXMgcGFydCBvZiBhbiBpb3JlbWFwKCkgY2FsbC4K
PiAKPiBJdCBzZWVtcyB0byBiZSBtb3JlIGNsZWFyIHRvIG1lLCBhbmQgSSdtIHRoaW5raW5nIGFi
b3V0IG1ha2luZwo+IHRoZSBzYW1lIGNoYW5nZXMgdG8gdGhlIENQTTIgZHJpdmVycy4gIEl0IGFs
c28gYWxsb3dzIGEKPiBwZXJmb3JtYW5jZSB2ZXJzdXMgY29tcGFjdCBjb2RlIHRyYWRlIG9mZiwg
ZGVjbGFyaW5nIHRoZXNlCj4gYXMgaW5saW5lIGZ1bmN0aW9ucyBvciBhcyByZWFsIGZ1bmN0aW9u
cy4KPiAKPiBUaGFua3MuCj4gCj4gCS0tIERhbgo+IAo+IAo+IAo+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQo+IAo+IE1lc3NhZ2U6IDkKPiBEYXRlOiBTdW4sIDcgQXVnIDIwMDUgMTI6
MTg6MjkgLTA3MDAKPiBGcm9tOiBFdWdlbmUgU3Vyb3ZlZ2luIDxlYnNAZWJzaG9tZS5uZXQ+Cj4g
U3ViamVjdDogUmU6IFtQQVRDSF0gOHh4OiBhZGQgY3BtX2dldF9jcG1wKCkKPiBUbzogTWFyY2Vs
byBUb3NhdHRpIDxtYXJjZWxvLnRvc2F0dGlAY3ljbGFkZXMuY29tPgo+IENjOiBsaW51eHBwYy1l
bWJlZGRlZEBvemxhYnMub3JnCj4gTWVzc2FnZS1JRDogPDIwMDUwODA3MTkxODI5LkdBNTM3NUBn
YXRlLmVic2hvbWUubmV0Pgo+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11cy1h
c2NpaQo+IAo+IE9uIFN1biwgQXVnIDA3LCAyMDA1IGF0IDEyOjU3OjMxUE0gLTAzMDAsIE1hcmNl
bG8gVG9zYXR0aSB3cm90ZToKPiA+IE9uIFN1biwgQXVnIDA3LCAyMDA1IGF0IDEyOjQ0OjMyUE0g
LTAzMDAsIEFyaXN0ZXUgU2VyZ2lvIFJvemFuc2tpIEZpbGhvCj4gd3JvdGU6Cj4gPiA+ID4gSXQg
ZGVwZW5kcyBob3cgeW91IGRlZmluZSB0aGUgc2VtYW50aWNzIG9mIHRoaXMgZnVuY3Rpb24gY2Fs
bC4KPiA+ID4gPiBDYW4geW91IGNhbGwgaXQgYW55IChhbmQgYWxsIG9mIHRoZSkgdGltZSB5b3Ug
bmVlZCBpdCwgb3IgZG9lcyBpdAo+ID4gPiA+IGFjdHVhbGx5IHBlcmZvcm0gYW4gaW9yZW1hcCgp
IGFuZCB5b3Ugb25seSB3YW50IHRvIGNhbGwgaXQKPiA+ID4gPiBvbmNlPwo+ID4gPiB3aGF0IGFi
b3V0IGRvbid0IGNhY2hlIGl0IGFuZCBjYWxsIGlvcmVtYXAoKSBmcm9tIGRyaXZlcj8gKEkgZ3Vl
c3MKPiA+ID4gaW9yZW1hcCgpIGFscmVhZHkgY2hlY2sgaWYgYW4gYXJlYSBpcyBhbHJlYWR5IG1h
cHBlZCwgbm8/KQo+ID4gCj4gPiBZZXAsIGlvcmVtYXAoKSBzaG91bGQgYmUgZG9pbmcgdmlydHVh
bCBhZGRyZXNzIGNhY2hpbmcgYWxyZWFkeSwgbm8/Cj4gCj4gSW4gZ2VuZXJhbCwgaW9yZW1hcCgp
IGRvZXNuJ3QgZG8gYW55IGNhY2hpbmcgY3VycmVudGx5LiBTb21lIHN1YmFyY2hzIAo+IGRvIHNv
bWUgbGltaXRlZCBjYWNoaW5nLCBlLmcuIGlmIEJBVHMgKGNsYXNzaWMgUFBDKSBvciBDQU1zIChl
NTAwKSBhcmUgCj4gYXZhaWxhYmxlIGFuZCB3ZXJlIHVzZWQgcHJldmlvdXNseSBmb3IgaW9yZW1h
cCgpIG1hcHBpbmdzLiAKPiAKPiBTb21lIHRpbWUgYWdvIEkgbWFkZSBhIHRyaXZpYWwgaW9yZW1h
cCBjYWNoZSBwYXRjaCAodXNlZnVsIG9uIDR4eCwgCj4gd2hpY2ggZG9lc24ndCBoYXZlIEJBVHMg
bm9yIENBTXMpLCBhbHRob3VnaCBpdCB3YXNzIHJlYWxseSBhIGhhY2sgYW5kIAo+IGl0IHdhcyBu
ZXZlciBtZXJnZWQgOikuCj4gCj4gLS0gCj4gRXVnZW5lCj4gCj4gCj4gCj4gLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCj4gCj4gTWVzc2FnZTogMTAKPiBEYXRlOiBNb24sIDggQXVnIDIw
MDUgMDk6NTM6MzIgKzA4MDAKPiBGcm9tOiAiRGVib3JhIExpdSIgPGRlYm9yYWxoQGZlbC5jb20u
Y24+Cj4gU3ViamVjdDogUmU6IFZvbHVudGVlcnMgdG8gdGVzdCBpMmMtYWxnby04eHggb24gdjIu
Nj8KPiBUbzogIk1hcmNlbG8gVG9zYXR0aSIgPG1hcmNlbG8udG9zYXR0aUBjeWNsYWRlcy5jb20+
Cj4gQ2M6IExpbnV4cHBjLWVtYmVkZGVkIDxMaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnPgo+
IE1lc3NhZ2UtSUQ6IDwyMDA1MDgwODAxNDkyMC4wMzczNDY3RjFFQG96bGFicy5vcmc+Cj4gCj4g
SGVsbG8sIE1hcmNlbG8gVG9zYXR0aQo+IAo+IEluIG1lc3NhZ2UgPDIwMDUtMDgtMDcgMDg6MzQ6
NTIgbWFyY2Vsby50b3NhdHRpQGN5Y2xhZGVzLmNvbT4geW91IHdyb3RlOgo+ID4KPiA+RG9lcyBh
bnlvbmUgdm9sdW50ZWVyIHRvIHRlc3QgdGhpcyA4eHggaTJjIGRyaXZlcj8KPiA+Cj4gPgo+IEkg
ZG9uJ3QgaGF2ZSBrZXJuZWwgdjIuNiwgYnV0IEkgaGF2ZSB0ZXN0IG15IGJvYXJkIHdpdGggZWxk
ay0zLjEuMQo+IGxpbnV4LTIuNC4yNQo+IHdoZW4gbXkgYm9hcmQga2VybmVsIGJvb3RpbmcsIEkg
Zm91bmQgb25lIHByb2JsZW0uCj4gZWxkay0zLjEuMSBsaW51eC0yLjQuMjUga2VybmVsIGluY2x1
ZGUgaTJjLCBpMmMtYWxnby04eHgsIHBjZjg1NjMgZHJpdmVyLgo+IElmIG9uZSBwY2Y4NTYzIGNo
aXAgb24gbXkgYm9hcmQsIHRoZXJlIGFyZSd0IHByb2JsZW0uCj4gQnV0IGlmIG15IGJvYXJkIGRv
bid0IGhhdmUgcGNmODU2MyBjaGlwLCBrZXJuZWwgc3RvcCBhcyBibG93Ogo+IExpbnV4IHZlcnNp
b24gMi40LjI1IChsaXVAYmlnaGVhZCkgKGdjYyB2ZXJzaW9uIDMuMy4zIChERU5YIEVMREsgMy4x
LjEKPiAzLjMuMy05KSkKPiAjNCDvv73vv70gN++/ve+/vSAyOSAxMjoxOToxNCBDU1QgMjAwNQo+
IG04eHhfc2V0dXAuYzpSZXNlcnZlZCAweDEwMDAwIG1lbW9yeSBhdCAweGMwMTkwMDAwCj4gT24g
bm9kZSAwIHRvdGFscGFnZXM6IDgxOTIKPiB6b25lKDApOiA4MTkyIHBhZ2VzLgo+IHpvbmUoMSk6
IDAgcGFnZXMuCj4gem9uZSgyKTogMCBwYWdlcy4KPiBLZXJuZWwgY29tbWFuZCBsaW5lOiByb290
PS9kZXYvbmZ0bGExCj4gaXA9MTkyLjE2OC4wLjIwNzoxOTIuMTY4LjAuODI6OjpzYzg1NXQ6ZXRo
Cj4gMDpvZmYKPiBEZWNyZW1lbnRlciBGcmVxdWVuY3kgPSAzMDAwMDAwMDAvNjAKPiBXYXJuaW5n
OiByZWFsIHRpbWUgY2xvY2sgc2VlbXMgc3R1Y2shCj4gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcC4u
LiA3OS42NiBCb2dvTUlQUwo+ID09PT09PT09PSBIWj0xMDAgICBsb29wc19wZXJfamlmZnk9Mzk4
MzM2Cj4gTWVtb3J5OiAzMDc1MmsgYXZhaWxhYmxlICgxMTQ0ayBrZXJuZWwgY29kZSwgMzU2ayBk
YXRhLCA1NmsgaW5pdCwgMGsKPiBoaWdobWVtKQo+IERlbnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVu
dHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBieXRlcykKPiBJbm9kZSBjYWNoZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiAyLCAxNjM4NCBieXRlcykKPiBNb3VudCBjYWNoZSBo
YXNoIHRhYmxlIGVudHJpZXM6IDUxMiAob3JkZXI6IDAsIDQwOTYgYnl0ZXMpCj4gQnVmZmVyIGNh
Y2hlIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXI6IDAsIDQwOTYgYnl0ZXMpCj4gUGFn
ZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDgxOTIgKG9yZGVyOiAzLCAzMjc2OCBieXRlcykK
PiBQT1NJWCBjb25mb3JtYW5jZSB0ZXN0aW5nIGJ5IFVOSUZJWAo+IFdEVF84eHg6IFNXVCBub3Qg
ZW5hYmxlZCBieSBmaXJtd2FyZSwgU1lQQ1I9MHhmZmZmZmY4OAo+IExpbnV4IE5FVDQuMCBmb3Ig
TGludXggMi40Cj4gQmFzZWQgdXBvbiBTd2Fuc2VhIFVuaXZlcnNpdHkgQ29tcHV0ZXIgU29jaWV0
eSBORVQzLjAzOQo+IEluaXRpYWxpemluZyBSVCBuZXRsaW5rIHNvY2tldAo+ICAgICAgIFN0YXJ0
aW5nIGtzd2FwZAo+IEpvdXJuYWxsZWQgQmxvY2sgRGV2aWNlIGRyaXZlciBsb2FkZWQKPiBpMmMt
Y29yZS5vOiBpMmMgY29yZSBtb2R1bGUgdmVyc2lvbiAyLjYuMSAoMjAwMTA4MzApCj4gaTJjLWRl
di5vOiBpMmMgL2RldiBlbnRyaWVzIGRyaXZlciBtb2R1bGUgdmVyc2lvbiAyLjYuMSAoMjAwMTA4
MzApCj4gaTJjLWFsZ28tOHh4Lm86IGkyYyBtcGM4eHggYWxnb3JpdGhtIG1vZHVsZSB2ZXJzaW9u
IDIuNi4xICgyMDAxMDgzMCkKPiBpMmMtcnB4Lm86IGkyYyBNUEM4eHggbW9kdWxlIHZlcnNpb24g
Mi42LjEgKDIwMDEwODMwKQo+IGkyYy1wcm9jLm8gdmVyc2lvbiAyLjYuMSAoMjAwMTA4MzApCj4g
Q1BNIFVBUlQgZHJpdmVyIHZlcnNpb24gMC4wNAo+IHR0eVMwIGF0IDB4MDI4MCBpcyBvbiBTTUMx
IHVzaW5nIEJSRzEKPiB0dHlTMSBhdCAweDAzODAgaXMgb24gU01DMiB1c2luZyBCUkcyCj4gcHR5
OiAyNTYgVW5peDk4IHB0eXMgY29uZmlndXJlZAo+IFBDRjg1NjMgUmVhbC1UaW1lIENsb2NrIERy
aXZlciAkUmV2aXNpb246IDEuMyAkIHdkQGRlbnguZGUKPiAKPiAKPiAKPiBJIG1vZGlmeSBpMmMt
YWxnby04eHguYyBjcG1faWljX3dyaXRlKCksIHRoZW4gbm8gcHJvYmxlbSwKPiBteSBib2FyZCBk
ZWZpbmVkIGJ5IENPTkZJR19TVk04eHgKPiAKPiAjaWZkZWYgQ09ORklHX1NWTTh4eAo+ICAgICB3
aGlsZSghKGkyYy0+aTJjX2kyY2VyICYgMHgxMikpCj4gICAgICAgaWYgKHRpbWVfYWZ0ZXIoamlm
ZmllcywgdG1vKSkgewo+ICAgICAgICAgdG1vID0gMDsKPiAgICAgICAgIGJyZWFrOwo+ICAgICAg
IH0KPiAjZWxzZQo+ICAgICAgICAgICAgICAgICB3aGlsZSghKGkyYy0+aTJjX2kyY2VyICYgMHgx
MiB8fCB0aW1lX2FmdGVyKGppZmZpZXMsIHRtbykpKTsKPiAvKiBCdXMKPiAjZW5kaWYKPiAKPiAK
PiAKPiA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0KPiAJCQkJIAo+IO+/
ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/ve+/vURlYm9yYSBMaXUK
PiDvv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv71kZWJvcmFs
aEBmZWwuY29tLmNuCj4g77+977+977+977+977+977+977+977+977+977+977+977+977+977+9
77+977+977+977+977+977+9MjAwNS0wOC0wOAo+IAo+IAo+IAo+IAo+IAo+IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fCj4gTGludXhwcGMtZW1iZWRkZWQgbWFpbGluZyBsaXN0Cj4gTGludXhw
cGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+IGh0dHBzOi8vb3psYWJzLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2xpbnV4cHBjLWVtYmVkZGVkCj4gCj4gRW5kIG9mIExpbnV4cHBjLWVtYmVkZGVkIERpZ2Vz
dCwgVm9sIDEyLCBJc3N1ZSAyNQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioKPgo=
^ permalink raw reply
* mpc 8xx watchdog eldh-3.1.1
From: Debora Liu @ 2005-08-08 6:08 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 352 bytes --]
Hello, Wolfgang Denk
how do I use watchdog with my userspace interface ?
this wdt_mpc8xx.c is different from standard watchdog userspace interface.
example: WDIOC_KEEPALIVE
ioctl(fd, WDIOC_KEEPALIVE, 0);
= = = = = = = = = = = = = = = = = = = =
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Debora Liu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡deboralh@fel.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-08
^ permalink raw reply
* Re: Volunteers to test i2c-algo-8xx on v2.6?
From: Debora Liu @ 2005-08-08 1:53 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]
Hello, Marcelo Tosatti
In message <2005-08-07 08:34:52 marcelo.tosatti@cyclades.com> you wrote:
>
>Does anyone volunteer to test this 8xx i2c driver?
>
>
I don't have kernel v2.6, but I have test my board with eldk-3.1.1 linux-2.4.25
when my board kernel booting, I found one problem.
eldk-3.1.1 linux-2.4.25 kernel include i2c, i2c-algo-8xx, pcf8563 driver.
If one pcf8563 chip on my board, there are't problem.
But if my board don't have pcf8563 chip, kernel stop as blow:
Linux version 2.4.25 (liu@bighead) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9))
#4 Îå 7ÔÂ 29 12:19:14 CST 2005
m8xx_setup.c:Reserved 0x10000 memory at 0xc0190000
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nftla1 ip=192.168.0.207:192.168.0.82:::sc855t:eth
0:off
Decrementer Frequency = 300000000/60
Warning: real time clock seems stuck!
Calibrating delay loop... 79.66 BogoMIPS
========= HZ=100 loops_per_jiffy=398336
Memory: 30752k available (1144k kernel code, 356k data, 56k init, 0k highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
WDT_8xx: SWT not enabled by firmware, SYPCR=0xffffff88
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
i2c-algo-8xx.o: i2c mpc8xx algorithm module version 2.6.1 (20010830)
i2c-rpx.o: i2c MPC8xx module version 2.6.1 (20010830)
i2c-proc.o version 2.6.1 (20010830)
CPM UART driver version 0.04
ttyS0 at 0x0280 is on SMC1 using BRG1
ttyS1 at 0x0380 is on SMC2 using BRG2
pty: 256 Unix98 ptys configured
PCF8563 Real-Time Clock Driver $Revision: 1.3 $ wd@denx.de
I modify i2c-algo-8xx.c cpm_iic_write(), then no problem,
my board defined by CONFIG_SVM8xx
#ifdef CONFIG_SVM8xx
while(!(i2c->i2c_i2cer & 0x12))
if (time_after(jiffies, tmo)) {
tmo = 0;
break;
}
#else
while(!(i2c->i2c_i2cer & 0x12 || time_after(jiffies, tmo))); /* Bus
#endif
= = = = = = = = = = = = = = = = = = = =
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Debora Liu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡deboralh@fel.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-08
^ permalink raw reply
* Re: [PATCH] 8xx: add cpm_get_cpmp()
From: Eugene Surovegin @ 2005-08-07 19:18 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050807155731.GA2715@dmt.cnet>
On Sun, Aug 07, 2005 at 12:57:31PM -0300, Marcelo Tosatti wrote:
> On Sun, Aug 07, 2005 at 12:44:32PM -0300, Aristeu Sergio Rozanski Filho wrote:
> > > It depends how you define the semantics of this function call.
> > > Can you call it any (and all of the) time you need it, or does it
> > > actually perform an ioremap() and you only want to call it
> > > once?
> > what about don't cache it and call ioremap() from driver? (I guess
> > ioremap() already check if an area is already mapped, no?)
>
> Yep, ioremap() should be doing virtual address caching already, no?
In general, ioremap() doesn't do any caching currently. Some subarchs
do some limited caching, e.g. if BATs (classic PPC) or CAMs (e500) are
available and were used previously for ioremap() mappings.
Some time ago I made a trivial ioremap cache patch (useful on 4xx,
which doesn't have BATs nor CAMs), although it wass really a hack and
it was never merged :).
--
Eugene
^ permalink raw reply
* Re: [PATCH] 8xx: add cpm_get_cpmp()
From: Dan Malek @ 2005-08-07 17:25 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20050807154432.GE5210@cathedrallabs.org>
On Aug 7, 2005, at 11:44 AM, Aristeu Sergio Rozanski Filho wrote:
> what about don't cache it and call ioremap() from driver? (I guess
> ioremap() already check if an area is already mapped, no?)
Either way. I'm actually leaning toward these "pointer helper"
functions. :-) Something like get_cpmp(), or get_immr(), that will
hide the details of the mapping, so you don't have to include
and know which #defines to use as part of an ioremap() call.
It seems to be more clear to me, and I'm thinking about making
the same changes to the CPM2 drivers. It also allows a
performance versus compact code trade off, declaring these
as inline functions or as real functions.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] 8xx: add cpm_get_cpmp()
From: Marcelo Tosatti @ 2005-08-07 15:57 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20050807154432.GE5210@cathedrallabs.org>
On Sun, Aug 07, 2005 at 12:44:32PM -0300, Aristeu Sergio Rozanski Filho wrote:
> > It depends how you define the semantics of this function call.
> > Can you call it any (and all of the) time you need it, or does it
> > actually perform an ioremap() and you only want to call it
> > once?
> what about don't cache it and call ioremap() from driver? (I guess
> ioremap() already check if an area is already mapped, no?)
Yep, ioremap() should be doing virtual address caching already, no?
^ permalink raw reply
* Re: [PATCH] 8xx: add cpm_get_cpmp()
From: Aristeu Sergio Rozanski Filho @ 2005-08-07 15:44 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <09b0792f426f1d5883cf5d437723f075@embeddededge.com>
> It depends how you define the semantics of this function call.
> Can you call it any (and all of the) time you need it, or does it
> actually perform an ioremap() and you only want to call it
> once?
what about don't cache it and call ioremap() from driver? (I guess
ioremap() already check if an area is already mapped, no?)
--
Aristeu
^ permalink raw reply
* Re: [PATCH] 8xx: add cpm_get_cpmp()
From: Dan Malek @ 2005-08-07 15:39 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050807043110.GA6316@dmt.cnet>
On Aug 7, 2005, at 12:31 AM, Marcelo Tosatti wrote:
> Aris, sounds like you should proceed with cpm_get_cpmp() and change all
> other drivers using it also.
It depends how you define the semantics of this function call.
Can you call it any (and all of the) time you need it, or does it
actually perform an ioremap() and you only want to call it
once?
I guess implemented properly it doesn't matter. On the first
call it should do the ioremap() and on subsequent calls it
just returns the mapping. This is one of those common
functions that should be in commproc.c.
Thanks.
-- Dan
^ permalink raw reply
* A configure error for samba3 on ppc
From: JohnsonCheng @ 2005-08-07 9:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
When I configure samba3.0.10 on ppc as following command:
CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib
./configure -host=powerpc-linux
I got a configure error message as following:
Configure: error: cannot run test program while cross compiling
See 'config.log' for more details
I think this is a samba configure bug, do anybody know how to pass it?
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 3541 bytes --]
^ permalink raw reply
* Re: [PATCH] 8xx: add cpm_get_cpmp()
From: Marcelo Tosatti @ 2005-08-07 4:31 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <e5caa80a2cd721a4f6ee3c74ead906b2@embeddededge.com>
On Sat, Aug 06, 2005 at 10:40:37PM -0400, Dan Malek wrote:
>
> On Aug 6, 2005, at 7:27 PM, Marcelo Tosatti wrote:
>
> >It already is exported, declared as
> >
> >commproc.h:extern cpm8xx_t *cpmp; /* Pointer to
> >comm processor */
> >
> >
> >and many drivers use the pointer directly.
>
> We shouldn't be doing this. All drivers should ioremap() any
> peripheral spaces they use and not make any assumptions
> someone else has done that already. We've been making
> such changes in the 82xx/83xx/85xx CPM2 drivers. If it
> isn't convenient to find the #defines for the ioremap(), we
> should change that. When I originally wrote all of this
> code, it was long ago when we didn't have some of the
> abstractions and it seemed any shortcuts for performance
> were desired :-)
OK makes sense (yep it was even discussed already).
Aris, sounds like you should proceed with cpm_get_cpmp() and change all
other drivers using it also.
>
>
> >arch/ppc/8260_io/ drivers also use the same convention.
>
> If there are any drivers in here, they either aren't used or
> on their way out. The only things that should remain are
> common support functions.
OK!
^ permalink raw reply
* Re: [PATCH] 8xx: add cpm_get_cpmp()
From: Dan Malek @ 2005-08-07 3:36 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20050806234244.GB5210@cathedrallabs.org>
On Aug 6, 2005, at 7:42 PM, Aristeu Sergio Rozanski Filho wrote:
> but not with EXPORT_SYMBOL(). I noticed this while compiling i2c stuff
> as module. also, I think it's better add a function to do this instead
> doing EXPORT_SYMBOL() in a variable.
Right. We should just ioremap() :-)
Thanks.
-- Dan
^ 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