hi i am starting project on porting embedded linux on to pq3 processor, can anybody help me regarding this thing. please send me the documentation on this.
On 8/8/05, linuxppc-embedded-request at ozlabs.org <linuxppc-embedded-request at ozlabs.org> wrote: > Send Linuxppc-embedded mailing list submissions to > linuxppc-embedded at 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 at ozlabs.org > > You can reach the person managing the list at > linuxppc-embedded-owner at 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 at embeddededge.com> > Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() > To: Marcelo Tosatti <marcelo.tosatti at cyclades.com> > Cc: linuxppc-embedded at ozlabs.org > Message-ID: <e5caa80a2cd721a4f6ee3c74ead906b2 at 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 at embeddededge.com> > Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() > To: Aristeu Sergio Rozanski Filho <aris at cathedrallabs.org> > Cc: linuxppc-embedded at ozlabs.org > Message-ID: <d74e24bbf82e4cedd3358465343d28ae at 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 at cyclades.com> > Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() > To: Dan Malek <dan at embeddededge.com> > Cc: linuxppc-embedded at ozlabs.org > Message-ID: <20050807043110.GA6316 at 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 at qnap.com.tw> > Subject: A configure error for samba3 on ppc > To: <linuxppc-embedded at ozlabs.org> > Message-ID: <20050807091603.CE57667F29 at 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 at embeddededge.com> > Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() > To: Marcelo Tosatti <marcelo.tosatti at cyclades.com> > Cc: linuxppc-embedded at ozlabs.org > Message-ID: <09b0792f426f1d5883cf5d437723f075 at 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 at cathedrallabs.org> > Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() > To: Dan Malek <dan at embeddededge.com> > Cc: linuxppc-embedded at ozlabs.org > Message-ID: <20050807154432.GE5210 at 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 at cyclades.com> > Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() > To: Aristeu Sergio Rozanski Filho <aris at cathedrallabs.org> > Cc: linuxppc-embedded at ozlabs.org > Message-ID: <20050807155731.GA2715 at 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 at embeddededge.com> > Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() > To: Aristeu Sergio Rozanski Filho <aris at cathedrallabs.org> > Cc: linuxppc-embedded at ozlabs.org > Message-ID: <2fcd8a329246b2f2c303e515dd0cb7bf at 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 at ebshome.net> > Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() > To: Marcelo Tosatti <marcelo.tosatti at cyclades.com> > Cc: linuxppc-embedded at ozlabs.org > Message-ID: <20050807191829.GA5375 at 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 at fel.com.cn> > Subject: Re: Volunteers to test i2c-algo-8xx on v2.6? > To: "Marcelo Tosatti" <marcelo.tosatti at cyclades.com> > Cc: Linuxppc-embedded <Linuxppc-embedded at ozlabs.org> > Message-ID: <20050808014920.0373467F1E at ozlabs.org> > > Hello, Marcelo Tosatti > > In message <2005-08-07 08:34:52 marcelo.tosatti at 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 at 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 at 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 at fel.com.cn > ????????????????????2005-08-08 > > > > > > ------------------------------ > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > End of Linuxppc-embedded Digest, Vol 12, Issue 25 > ************************************************* >
