Linuxppc-embedded Digest, Vol 12, Issue 25
Anand Kasula
anandkasula at gmail.com
Mon Aug 8 16:40:41 EST 2005
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
> *************************************************
>
More information about the Linuxppc-embedded
mailing list