* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-15 15:01 UTC (permalink / raw)
To: Jason McMullan; +Cc: Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <1118846034.7564.113.camel@jmcmullan.timesys>
On Jun 15, 2005, at 9:33 AM, Jason McMullan wrote:
> On Wed, 2005-06-15 at 09:25 -0500, Kumar Gala wrote:
>> Yes, I removed the fcc_regs_c since its not always true. Please don't
>> rename the file to cpm2_. I think I'm going to end up renaming them
>> to
>> pq2_ since that is the most appropriate name. I'd say we are about
>> 80%
>
> PQ2_? But all these devices are on PQ3 also!
Sure and they are in the mpc85xx_* files. Maybe I'm missing some
concern people have here. It dont see what the issue is. This is just
like how TSEC/gianfar show up in both mpc85xx_* and mpc83xx_*. These
files are intended to represent the devices found on a product family
(PQ2, PQ3, PQ2 Pro, etc.). There is going to be overlap.
Also, its not 100% true that all of the devices on a PQ2 exist in PQ3.
For example (and this isn't a great one) the security block on
8248/8272 is different than the security block on PQ3 devices.
- kumar
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-15 15:06 UTC (permalink / raw)
To: Jason McMullan; +Cc: linuxppc-embedded
In-Reply-To: <1118845450.7564.111.camel@jmcmullan.timesys>
On Jun 15, 2005, at 9:24 AM, Jason McMullan wrote:
> My personal opinions:
>
> * Use macro-offsets into a cpm2_map_t struct
Not going to happen. Sorry.
> * Put fcc_c regs back in
Can you explain this. I'm not 100% sure what regs you are referring to.
> * dpram[PROFF_*] should be in the resources list
The patch I posted seems to do that. I'm guessing these comments may
be against Allen's initial patch.
> * cpm2_* is a better name than MPC82xx_* or MPC85xx_*
> * Keep CPM2_DMA, etc, as these *should* be showing up in
> /proc/iomem, since, IIRC, the platform layer does
> reserve them upon registration. (And I *do* have a DMA
> layer then uses CPM2_DMA as a driver-ish thing)
I'll agree on DMA, do you see value in CPM, SI1 and SI2 being here?
And if so for what?
- kumar
^ permalink raw reply
* Re: 2.4.26 and MPC885 context switching time
From: Mark Chambers @ 2005-06-15 15:13 UTC (permalink / raw)
To: Schaefer-Hutter, Peter, linuxppc-embedded
In-Reply-To: <8E342283C2100540AAC5D1030970547766F7A1@rcexc.racoms.loc>
>Hi all,
>
>i'm evaluating IPC on the MPC885ADS and discovered
>that the context switching times seem to be quite
>disappointing (up to 1ms). As we need to do a lot
>of IPC later on, i'm interested bringing the time
>down.
>
>Therefore i wonder, if there are any known problems
>with the MMU on 8xx and 2.4.2x which might explain
>that?
Maybe it would help if you gave more detail about how
you are measuring these times in your system.
I'm interested to know the answer to this myself!
Mark Chambers
^ permalink raw reply
* CPM2 vs PQ2: The Naming Issue
From: Jason McMullan @ 2005-06-15 15:18 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
I think the issue with naming is that there are people that consider the
'part name' to be CPM2 (the macrocell), and other consider the
'part name' to be the whole SoC.
Both are valid concepts, I just tend to go towards the macrocell
side of the fence.
If we consider the CPM2 to be a 'part' that dispenses other 'parts',
we could actually consider the CPM2 to be a bus-type object.
Hmm. I kinda like that, actually. (But then, I'm a crazy nutball)
--
Jason McMullan <jason.mcmullan@gmail.com>
"Sure, send me the latest Knoppix DVD as an attachment..."
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Vitaly Bordug @ 2005-06-15 15:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <2731d19a2e3b9413db32be59726a4c82@freescale.com>
Kumar Gala wrote:
>
> On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote:
>
>> Kumar,
>> I assume this as a IMMR enumerating you promised to help with. Is it in
>> the final state? And what was the reason of fcc_regs_c removal?
>> I'm also going to change the files name to cpm2_.. .
>
>
> Yes, I removed the fcc_regs_c since its not always true. Please don't
> rename the file to cpm2_. I think I'm going to end up renaming them
> to pq2_ since that is the most appropriate name. I'd say we are about
> 80% the way to a final patch.
>
Great. Apart of naming issue - what else remaining to do?
I mean how can I contribute to speed-up this?
--
Sincerely,
Vitaly
^ permalink raw reply
* AW: 2.4.26 and MPC885 context switching time
From: Martin Krause @ 2005-06-15 15:12 UTC (permalink / raw)
To: Schaefer-Hutter, Peter; +Cc: linuxppc-embedded
Hi Peter,
linuxppc-embedded-bounces@ozlabs.org wrote on :
> i'm evaluating IPC on the MPC885ADS and discovered
> that the context switching times seem to be quite
> disappointing (up to 1ms). As we need to do a lot
..=20
> Or is this the expected context switching time for
> CPU @ 100 MHz (RAM @ 50 MHz)? Suggestions for a
> benchmark program?
Denx has done some detailed performance measurements=20
(including context switching). You could find the report=20
here: http://www.denx.de/twiki/bin/view/Know/Linux24vs26.
Hope that is of some help.
Regards,
Martin
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-15 15:41 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <42B049DC.7040703@ru.mvista.com>
On Jun 15, 2005, at 10:31 AM, Vitaly Bordug wrote:
> Kumar Gala wrote:
>
>>
>> On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote:
>>
>>> Kumar,
>>> I assume this as a IMMR enumerating you promised to help with. Is it
>>> in
>>> the final state? And what was the reason of fcc_regs_c removal?
>>> I'm also going to change the files name to cpm2_.. .
>>
>>
>> Yes, I removed the fcc_regs_c since its not always true. Please don't
>> rename the file to cpm2_. I think I'm going to end up renaming them
>> to pq2_ since that is the most appropriate name. I'd say we are about
>> 80% the way to a final patch.
>>
> Great. Apart of naming issue - what else remaining to do?
> I mean how can I contribute to speed-up this?
At this point, I think a bit more discussion is going to be needed on
if SI1, SI2, and CPM are "devices" or not.
Also, does the proposed FCC defn. sufficient or do we need the extended
registers that exist on some of the newer PQ2/PQ3 devices? I wasn't
sure if the drivers used them or not.
- kumar
^ permalink raw reply
* RE: 2.4.26 and MPC885 context switching time
From: Schaefer-Hutter, Peter @ 2005-06-15 15:43 UTC (permalink / raw)
To: Mark Chambers, linuxppc-embedded
> Maybe it would help if you gave more detail about how
> you are measuring these times in your system.
I basically used the two programs from=20
http://www.ibm.com/developerworks/linux/library/l-rt9/
since running lmbench is currently not an option;
however, i'm looking into creating a nfs filesystem that
has enough stuff in it to run lmbench.
Regards,
Peter
^ permalink raw reply
* Linux 2.4.26 boot over network
From: Barbier, Renaud (GE Infrastructure) @ 2005-06-15 15:09 UTC (permalink / raw)
To: linuxppc-embedded
I have a 440GX based board running Linux 2.4.26
I have successfully booted over the network by setting the boot =
argument to
Kernel command line: console=3DttyS0,9600n8 root=3D/dev/nfs rw =
ip=3Dbootp da104_gpio=3D8
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
eth0: IBM emac, MAC 00:30:f7:71:35:20
eth0: Link is Up
eth0: Speed: 10, Half duplex.
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 192.168.49.189, my address is =
192.168.49.1
IP-Config: Complete:
device=3Deth0, addr=3D192.168.49.1, mask=3D255.255.255.0, =
gw=3D255.255.255.255,
host=3D192.168.49.1, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.49.189, rootserver=3D192.168.49.189, =
rootpath=3D/home/proj/at921/Filesys/usr/local/gefnes/target
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.49.189
Looking up port of RPC 100005/1 on 192.168.49.189
Now, I am trying to boot Linux over the network using the following boot =
arguments:
Kernel command line: console=3DttyS0,9600n8 console=3Dtty0 =
root=3D/dev/nfs rw =
nfsroot=3D192.168.49.189:/home/proj/at921/Filesys/usr/local/gefnes/target=
192.168.49.1:192.168.49.189::255.255.255.0::eth0:off da104_gpio=3D8
It ends up failing:
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.49.189
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.49.189
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting =
/home/proj/at921/Filesys/usr/local/gefnes/target
eth0: Link is Up
eth0: Speed: 10, Half duplex.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or 02:00
While debugging I noticed that emac_open was not even called yet. Hence, =
no packets come out.=20
Linux tried to look up for a RPC port before the EMAC port is is opened.
Is that a problem that has already been seen?
^ permalink raw reply
* RE: Linux 2.4.26 boot over network
From: Steven Blakeslee @ 2005-06-15 15:59 UTC (permalink / raw)
To: Barbier, Renaud (GE Infrastructure), linuxppc-embedded
>Now, I am trying to boot Linux over the network using the following
boot arguments:
>Kernel command line: console=3DttyS0,9600n8 console=3Dtty0 =
root=3D/dev/nfs rw
nfsroot=3D
>192.168.49.189:/home/proj/at921/Filesys/usr/local/gefnes/target
>192.168.49.1:192.168.49.189::255.255.255.0::eth0:off da104_gpio=3D8
In the first one you had ip=3Dbootp, this uses bootp to get the ip
address. In the second one you do not have an ip define so the ethernet
is not being enabled. You need something like this
ip=3D192.168.49.1:::255.255.255.0
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Vitaly Bordug @ 2005-06-15 16:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
In-Reply-To: <7e2a8c0e483e5dfdc532c47d20776bbd@freescale.com>
Kumar Gala wrote:
>
> On Jun 15, 2005, at 10:31 AM, Vitaly Bordug wrote:
>
>> Kumar Gala wrote:
>>
>>>
>>> On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote:
>>>
>>>> Kumar,
>>>> I assume this as a IMMR enumerating you promised to help with. Is
>>>> it in
>>>> the final state? And what was the reason of fcc_regs_c removal?
>>>> I'm also going to change the files name to cpm2_.. .
>>>
>>>
>>>
>>> Yes, I removed the fcc_regs_c since its not always true. Please don't
>>> rename the file to cpm2_. I think I'm going to end up renaming them
>>> to pq2_ since that is the most appropriate name. I'd say we are about
>>> 80% the way to a final patch.
>>>
>> Great. Apart of naming issue - what else remaining to do?
>> I mean how can I contribute to speed-up this?
>
>
> At this point, I think a bit more discussion is going to be needed on
> if SI1, SI2, and CPM are "devices" or not.
>
> Also, does the proposed FCC defn. sufficient or do we need the
> extended registers that exist on some of the newer PQ2/PQ3 devices? I
> wasn't sure if the drivers used them or not.
>
fs_enet uses fcc_regs_c but only as a pass to the generic ethtool stuff
but I'm not currently aware if it's compulsory. I guess FCC's mem(used
to be IORESORCE) will be passed through platform_info but... Well, we
have tiptridx etc. stuff that wants DPRAM offsets but pad area has to be
real address. I'm still not sure how to handle this correct...
> - kumar
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* RE: Linux 2.4.26 boot over network
From: Barbier, Renaud (GE Infrastructure) @ 2005-06-15 16:11 UTC (permalink / raw)
To: Steven Blakeslee, linuxppc-embedded
thanks.=20
That was it. Too much dirt in my eyes today.
My U-boot script that builds the bootargs was wrong.
-----Original Message-----
From: Steven Blakeslee [mailto:BlakesleeS@embeddedplanet.com]
Sent: Wednesday, June 15, 2005 4:59 PM
To: Barbier, Renaud (GE Infrastructure); linuxppc-embedded@ozlabs.org
Subject: RE: Linux 2.4.26 boot over network
>Now, I am trying to boot Linux over the network using the following
boot arguments:
>Kernel command line: console=3DttyS0,9600n8 console=3Dtty0 =
root=3D/dev/nfs rw
nfsroot=3D
>192.168.49.189:/home/proj/at921/Filesys/usr/local/gefnes/target
>192.168.49.1:192.168.49.189::255.255.255.0::eth0:off da104_gpio=3D8
In the first one you had ip=3Dbootp, this uses bootp to get the ip
address. In the second one you do not have an ip define so the ethernet
is not being enabled. You need something like this
ip=3D192.168.49.1:::255.255.255.0
^ permalink raw reply
* Error while opennig device file
From: Garcia Jérémie @ 2005-06-15 16:19 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody,
I'd like to have your opinion on such a stupid question. Indeed, it must =
be very easy to see but
I can't find out what goes on.
I'm writing a device driver. In the init_module(), I register it with =
TEST_DEV_MAJOR =3D 122=20
ret_val =3D register_chrdev(TEST_DEV_MAJOR, TEST_DEV_PROC_NAME, =
&lcd_fops);
In the user space, I have a programm that creates two device files using =
the same major number but with=20
different minor numbers:
ret_val =3D system("mknod -m 777 /dev/Test1 c 122 1");
ret_val =3D system("mknod -m 777 /dev/Test1 c 122 2");
Then I try to open both files :
file_desc1 =3D open("/dev/test1", O_RDWR);
file_desc2 =3D open("/dev/test2", O_RDWR);
Unfortunately, I go through an error on the second open. It seems that I =
can't get those 2 files opened
at the same time. I'm a newbie in linux kernel development, so could you =
explain me why?
What I want to do is to have 2 device files that use the same driver =
module. In my module, I test the minor number
and handle an array of 2 structures (1 for each minor number).
For example, it could represent 2 communication channels ; I could have =
1 device file by channel on which I
could do read/write operation. My module will write/read in array[0] for =
channel 0 and in array[1] for channel 1.
Tks a lot and sorry for such a question but nobody can help me there and =
I can't find out browsing forums and books...
^ permalink raw reply
* RE: 2.4.26 and MPC885 context switching time
From: Andrew Williams @ 2005-06-15 17:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
Question embedded below..
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
> Martin Krause
> Sent: June 15, 2005 11:12 AM
> To: Schaefer-Hutter, Peter
> Cc: linuxppc-embedded@ozlabs.org
> Subject: AW: 2.4.26 and MPC885 context switching time
>
>
> Hi Peter,
>
> linuxppc-embedded-bounces@ozlabs.org wrote on :
> > i'm evaluating IPC on the MPC885ADS and discovered
> > that the context switching times seem to be quite
> disappointing (up to
> > 1ms). As we need to do a lot
> ..
> > Or is this the expected context switching time for
> > CPU @ 100 MHz (RAM @ 50 MHz)? Suggestions for a
> > benchmark program?
>
> Denx has done some detailed performance measurements
> (including context switching). You could find the report
> here: http://www.denx.de/twiki/bin/view/Know/Linux24vs26.
> Hope that is of some help.
>
Has anything changed with 2.6 in the last 12 months that
would alter the conclusions presented in this article?
A.
> Regards,
> Martin
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-> embedded
>
>
[-- Attachment #2: Type: text/html, Size: 2922 bytes --]
^ permalink raw reply
* Re: Error while opennig device file
From: Eugene Surovegin @ 2005-06-15 17:26 UTC (permalink / raw)
To: Garcia J?r?mie; +Cc: linuxppc-dev
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B35@exnet.3il.fr>
On Wed, Jun 15, 2005 at 06:19:43PM +0200, Garcia J?r?mie wrote:
> Hi everybody,
> I'd like to have your opinion on such a stupid question. Indeed, it must be very easy to see but
> I can't find out what goes on.
> I'm writing a device driver. In the init_module(), I register it with TEST_DEV_MAJOR = 122
>
> ret_val = register_chrdev(TEST_DEV_MAJOR, TEST_DEV_PROC_NAME, &lcd_fops);
>
> In the user space, I have a programm that creates two device files using the same major number but with
> different minor numbers:
>
> ret_val = system("mknod -m 777 /dev/Test1 c 122 1");
> ret_val = system("mknod -m 777 /dev/Test1 c 122 2");
^
> Then I try to open both files :
> file_desc1 = open("/dev/test1", O_RDWR);
> file_desc2 = open("/dev/test2", O_RDWR);
You must be kidding.
You create /dev/Test1 twice, and then open /dev/test1 and /dev/test2.
First of all, Linux fs are case sensitive, second, you don't create
test2 (even with wrong case).
--
Eugene
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Allen Curtis @ 2005-06-15 17:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <e7e59bf0180e5958169a0f7fc0196098@freescale.com>
> On Jun 15, 2005, at 9:24 AM, Jason McMullan wrote:
>
>> My personal opinions:
>>
>> * Use macro-offsets into a cpm2_map_t struct
>
> Not going to happen. Sorry.
>
Interesting... So are you thinking of eliminating the cpm_map_t
structure all together?
>> * Put fcc_c regs back in
>
> Can you explain this. I'm not 100% sure what regs you are referring
> to.
>
The registers that he is referring to are in my patch with a comment
about moving them to the device driver specific structure. The base
address changed depending on processor.
>> * dpram[PROFF_*] should be in the resources list
>
> The patch I posted seems to do that. I'm guessing these comments may
> be against Allen's initial patch.
>
My patch did you the #defines from cpm2.h to specify the PROFF
locations. It did not use dpram[PROFF] since that would be an address
not an offset from the base.
>> * cpm2_* is a better name than MPC82xx_* or MPC85xx_*
>> * Keep CPM2_DMA, etc, as these *should* be showing up in
>> /proc/iomem, since, IIRC, the platform layer does
>> reserve them upon registration. (And I *do* have a DMA
>> layer then uses CPM2_DMA as a driver-ish thing)
>
> I'll agree on DMA, do you see value in CPM, SI1 and SI2 being here?
> And if so for what?
>
I really do not want to belabor this point about naming conventions but
I believe it will become more of a problem in the future. The problem
as I see it is the PQ2 is a multi-core processor composed of a PPC 603
and a CPM. So the question is, is it more efficient to describe the
multi-core permutations or the pieces that are put together to create
the processor. As industry uses more IP blocks to create SoCs I can see
the "describe the chip" approach to be a exponential problem.
DMA and CPM should be in the device list. They represent a shared
resource or a management function shared by the "real" devices. Putting
them in the list has the advantage that their resources are mapped with
the device is registered. (as mentioned by Jason M.) Perhaps there will
be a need for a DMA manager.
^ permalink raw reply
* RE : Error while opennig device file
From: Garcia Jérémie @ 2005-06-15 17:47 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev
I'm sorry but this is a "copy to mail" error. =20
Here is the right code:
ret_val =3D system("mknod -m 777 /dev/test1 c 122 1");
ret_val =3D system("mknod -m 777 /dev/test2 c 122 2");
file_desc1 =3D open("/dev/test1", O_RDWR);
file_desc2 =3D open("/dev/test2", O_RDWR);
Sorry again but I would have liked that it was so easy...lol
-------- Message d'origine--------
De: Eugene Surovegin [mailto:ebs@ebshome.net]
Date: mer. 15/06/2005 19:26
=C0: Garcia J=E9r=E9mie
Cc: linuxppc-dev@ozlabs.org
Objet : Re: Error while opennig device file
=20
On Wed, Jun 15, 2005 at 06:19:43PM +0200, Garcia J?r?mie wrote:
> Hi everybody,
> I'd like to have your opinion on such a stupid question. Indeed, it =
must be very easy to see but
> I can't find out what goes on.
> I'm writing a device driver. In the init_module(), I register it with =
TEST_DEV_MAJOR =3D 122=20
>=20
> ret_val =3D register_chrdev(TEST_DEV_MAJOR, TEST_DEV_PROC_NAME, =
&lcd_fops);
>=20
> In the user space, I have a programm that creates two device files =
using the same major number but with=20
> different minor numbers:
>=20
> ret_val =3D system("mknod -m 777 /dev/Test1 c 122 1");
> ret_val =3D system("mknod -m 777 /dev/Test1 c 122 2");
^=20
> Then I try to open both files :
> file_desc1 =3D open("/dev/test1", O_RDWR);
> file_desc2 =3D open("/dev/test2", O_RDWR);
You must be kidding.
You create /dev/Test1 twice, and then open /dev/test1 and /dev/test2.
First of all, Linux fs are case sensitive, second, you don't create=20
test2 (even with wrong case).
--=20
Eugene
^ permalink raw reply
* Re: RE : Error while opennig device file
From: Eugene Surovegin @ 2005-06-15 18:00 UTC (permalink / raw)
To: Garcia J?r?mie; +Cc: linuxppc-dev
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B36@exnet.3il.fr>
On Wed, Jun 15, 2005 at 07:47:56PM +0200, Garcia J?r?mie wrote:
> I'm sorry but this is a "copy to mail" error.
> Here is the right code:
>
> ret_val = system("mknod -m 777 /dev/test1 c 122 1");
> ret_val = system("mknod -m 777 /dev/test2 c 122 2");
>
> file_desc1 = open("/dev/test1", O_RDWR);
> file_desc2 = open("/dev/test2", O_RDWR);
>
> Sorry again but I would have liked that it was so easy...lol
OK, how does open routine for your device look like?
What error do you get on second open?
--
Eugene
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Vitaly Bordug @ 2005-06-15 18:05 UTC (permalink / raw)
To: Allen Curtis; +Cc: linuxppc-embedded list
In-Reply-To: <a9c3f58e85815e58496be38eeee609bf@onz.com>
Allen Curtis wrote:
>> On Jun 15, 2005, at 9:24 AM, Jason McMullan wrote:
>>
>>> My personal opinions:
>>>
>>> * Use macro-offsets into a cpm2_map_t struct
>>
>>
>> Not going to happen. Sorry.
>>
>
> Interesting... So are you thinking of eliminating the cpm_map_t
> structure all together?
I guess not that tough. I used to have really disappointing problem when
on of the patches added a small error to immr structure. Whole day of
ghost hust while the problem wasn't even mine. So the hardcoded offsets
are intended to prevent such cases. I don't think cpm_map_t will be
eliminated as structure is much more comfortable and understandable than
pure offsets. Bus I agree that structure-dependence within platform
definitions is not very good idea. IMHO.
>
>>> * Put fcc_c regs back in
>>
>>
>> Can you explain this. I'm not 100% sure what regs you are referring to.
>>
>
> The registers that he is referring to are in my patch with a comment
> about moving them to the device driver specific structure. The base
> address changed depending on processor.
>
>>> * dpram[PROFF_*] should be in the resources list
>>
>>
>> The patch I posted seems to do that. I'm guessing these comments may
>> be against Allen's initial patch.
>>
> My patch did you the #defines from cpm2.h to specify the PROFF
> locations. It did not use dpram[PROFF] since that would be an address
> not an offset from the base.
>
>>> * cpm2_* is a better name than MPC82xx_* or MPC85xx_*
>>> * Keep CPM2_DMA, etc, as these *should* be showing up in
>>> /proc/iomem, since, IIRC, the platform layer does
>>> reserve them upon registration. (And I *do* have a DMA
>>> layer then uses CPM2_DMA as a driver-ish thing)
>>
>>
>> I'll agree on DMA, do you see value in CPM, SI1 and SI2 being here?
>> And if so for what?
>>
> I really do not want to belabor this point about naming conventions
> but I believe it will become more of a problem in the future. The
> problem as I see it is the PQ2 is a multi-core processor composed of a
> PPC 603 and a CPM. So the question is, is it more efficient to
> describe the multi-core permutations or the pieces that are put
> together to create the processor. As industry uses more IP blocks to
> create SoCs I can see the "describe the chip" approach to be a
> exponential problem.
>
Definitely.And there isn't only one issue. For example, I think 8xx will
never get such device/sys files because the fact that the board has 8xx
chip means nearly nothing in term of what devices it has. The best
decision this case to manually call platform_device_register on
structures created within board-specific code.
> DMA and CPM should be in the device list. They represent a shared
> resource or a management function shared by the "real" devices.
> Putting them in the list has the advantage that their resources are
> mapped with the device is registered. (as mentioned by Jason M.)
> Perhaps there will be a need for a DMA manager.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* RE : RE : Error while opennig device file
From: Garcia Jérémie @ 2005-06-15 18:22 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev
I give you all those infos tomorrow cause I'm from France and it's soon =
9:00pm, so I'm not at office.
Tks a lot for your help
-------- Message d'origine--------
De: Eugene Surovegin [mailto:ebs@ebshome.net]
Date: mer. 15/06/2005 20:00
=C0: Garcia J=E9r=E9mie
Cc: linuxppc-dev@ozlabs.org
Objet : Re: RE : Error while opennig device file
=20
On Wed, Jun 15, 2005 at 07:47:56PM +0200, Garcia J?r?mie wrote:
> I'm sorry but this is a "copy to mail" error. =20
> Here is the right code:
>=20
> ret_val =3D system("mknod -m 777 /dev/test1 c 122 1");
> ret_val =3D system("mknod -m 777 /dev/test2 c 122 2");
>=20
> file_desc1 =3D open("/dev/test1", O_RDWR);
> file_desc2 =3D open("/dev/test2", O_RDWR);
>=20
> Sorry again but I would have liked that it was so easy...lol
OK, how does open routine for your device look like?
What error do you get on second open?
--=20
Eugene
^ permalink raw reply
* Re: Discuss: Adding OF Flat Dev Tree to ppc32
From: Jon Loeliger @ 2005-06-15 19:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev, linuxppc-embedded@ozlabs.org
In-Reply-To: <1118199997.6850.106.camel@gaston>
On Tue, 2005-06-07 at 22:06, Benjamin Herrenschmidt wrote:
> It's basically used to extract some infos directly from the flattened
> tree in order to construct the LMB list (list of memory blocks,
> equivalent of ppc32's mem_pieces),
OK. So the unflattenting process requires a small amount
of memory allocation which is currently implemented using
the lmb mechanism in PPC64 land.
As you indicate, there is also the mem_pieces implementation
over in ppc32 land. I think it is currently only used by
arch/ppc/platforms/pmac_setup.c.
In porting this code over to PPC32 land, there are roughly
three choices:
1) Copy the LMB implementation from ppc64 over to PPC32 land,
2) Change the unflattening code in PPC32 to use mem_pieces,
or rewrite it to allow a configurable choice between
LMB and mem_pieces,
or
3) Make up something new, yet very similar to LMB and
mem_pieces.
Does anyone have suggestions or advice on route 1) or 2)?
Anyone? Kumar? Ben? Bueller?
Thanks,
jdl
^ permalink raw reply
* Re: RE : Error while opennig device file
From: Dustin Lang @ 2005-06-15 18:16 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, Garcia J?r?mie
In-Reply-To: <20050615180011.GB21165@gate.ebshome.net>
Also - does it work from the command line? Do both mknod commands work?
When you "ls -l /dev/test{1,2}" , what do you get? What happens when you
"cat /dev/test1" or "echo > /dev/test1" ?
Cheers,
dstn.
>> I'm sorry but this is a "copy to mail" error.
>> Here is the right code:
>>
>> ret_val = system("mknod -m 777 /dev/test1 c 122 1");
>> ret_val = system("mknod -m 777 /dev/test2 c 122 2");
>>
>> file_desc1 = open("/dev/test1", O_RDWR);
>> file_desc2 = open("/dev/test2", O_RDWR);
^ permalink raw reply
* Re: 2.4.26 and MPC885 context switching time
From: Jaap-Jan Boor @ 2005-06-15 20:04 UTC (permalink / raw)
To: Schaefer-Hutter, Peter; +Cc: linuxppc-embedded
In-Reply-To: <8E342283C2100540AAC5D1030970547766F7A1@rcexc.racoms.loc>
I did once ran lmbench on a proprietry 850 based board running at
62/31 Mhz
using 1 16-bit dram:
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/
64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
ctxsw
--------- ------------- ----- ------ ------ ------ ------ -------
-------
test Linux 2.4.25- 259.2 234.2 302.6 304.7
This is ~ 3x faster then your 100Mhz 885...
Jaap-Jan
On 15-jun-2005, at 16:55, Schaefer-Hutter, Peter wrote:
> Hi all,
>
> i'm evaluating IPC on the MPC885ADS and discovered
> that the context switching times seem to be quite
> disappointing (up to 1ms). As we need to do a lot
> of IPC later on, i'm interested bringing the time
> down.
>
> Therefore i wonder, if there are any known problems
> with the MMU on 8xx and 2.4.2x which might explain
> that?
>
> Or is this the expected context switching time for
> CPU @ 100 MHz (RAM @ 50 MHz)? Suggestions for a
> benchmark program?
>
> Thanks!
>
> Peter
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
____
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum jjboor at aimsys dot nl
^ permalink raw reply
* Re: Discuss: Adding OF Flat Dev Tree to ppc32
From: Benjamin Herrenschmidt @ 2005-06-15 21:52 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc64-dev, linuxppc-embedded@ozlabs.org
In-Reply-To: <1118862046.25372.49.camel@cashmere.sps.mot.com>
On Wed, 2005-06-15 at 14:00 -0500, Jon Loeliger wrote:
> On Tue, 2005-06-07 at 22:06, Benjamin Herrenschmidt wrote:
>
> > It's basically used to extract some infos directly from the flattened
> > tree in order to construct the LMB list (list of memory blocks,
> > equivalent of ppc32's mem_pieces),
>
>
> OK. So the unflattenting process requires a small amount
> of memory allocation which is currently implemented using
> the lmb mechanism in PPC64 land.
Not only the unflattening process. The full MMU initialisation (ability
to map things etc...) needs mem_pieces too. The ppc32 kernel runs with a
very limited memory setup until that happens.
> As you indicate, there is also the mem_pieces implementation
> over in ppc32 land. I think it is currently only used by
> arch/ppc/platforms/pmac_setup.c.
mem_pieces is used in several places in the early mmu setup too
in arch/ppc/mm/*
> In porting this code over to PPC32 land, there are roughly
> three choices:
>
> 1) Copy the LMB implementation from ppc64 over to PPC32 land,
No, we can stick to mem_pieces
> 2) Change the unflattening code in PPC32 to use mem_pieces,
> or rewrite it to allow a configurable choice between
> LMB and mem_pieces,
mem_pieces is fine
> 3) Make up something new, yet very similar to LMB and
> mem_pieces.
>
> Does anyone have suggestions or advice on route 1) or 2)?
> Anyone? Kumar? Ben? Bueller?
The main issues is not really there. The problem is that we will have to
scan the flattened tree at boot in order to setup the MMU and that will
have to be done with a very limited access to memory, possibly only the
low 32Mb of RAM for example (though we may manage something better
running in real mode with some CPUs).
That means maybe imposing some restrictions on where the flattened
device-tree block can be when passed to the kernel (unless we can run
that C code in real mode) and other niceties that will have to be dealt
per CPU family.
Ben.
^ permalink raw reply
* Re: 2.4.26 and MPC885 context switching time
From: Wolfgang Denk @ 2005-06-15 23:38 UTC (permalink / raw)
To: Jaap-Jan Boor; +Cc: Schaefer-Hutter, Peter, linuxppc-embedded
In-Reply-To: <187119B8-515D-4903-AAB5-05BF80215A4D@aimsys.nl>
In message <187119B8-515D-4903-AAB5-05BF80215A4D@aimsys.nl> you wrote:
> I did once ran lmbench on a proprietry 850 based board running at
> 62/31 Mhz using 1 16-bit dram:
>
> Context switching - times in microseconds - smaller is better
> -------------------------------------------------------------
> Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/
> 64K
> ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
> ctxsw
> --------- ------------- ----- ------ ------ ------ ------ -------
> -------
> test Linux 2.4.25- 259.2 234.2 302.6 304.7
>
> This is ~ 3x faster then your 100Mhz 885...
I just ran lmbench on a MPC866 system (CPU at 132 MHz, bus at 66 MHz):
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
tqm8xx Linux 2.4.25 5.4500 27.5 30.3 39.0 36.0 37.7 33.5
There is definitely something wrong with Peter's measurements.
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
Quantum particles: The dreams that stuff is made of.
^ 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