E1/T1 on mpc8260.

E1/T1 on mpc8260.

[Omanakuttan]

Greetings,
We are developing a bridge which will convert 7 E1/T1 channels to
100Mbps ethernet using mpc8260 and Exar XRT84L38 Octal framer.

According the design, TDMs will be fed data from octal T1/E1 framer. I
will have to program the MCC to accept data from the TDMs and give it to
a pppd daemon.

If the TDMs are fed data from the framer (i.e. E1/T1's stripped of
signaling and channeling information), how many channels do I have to
program in the MCC?
Do I have to program one channel for each E1/T1 lines or 30 channels for
each E1 and 24 channels for each T1s? Or any of the approach is OK
provided I do not want the 64kbps granularity and ready to accept it as
a big stram of bytes (64 x 30 kbps)? if I do so, can I demultiplex it
using some other device?

if one E1 is accepted as one channel in MCC, then why is it stated that
it takes 128 channels of 64k each? (MPC8260UM.pdf,

The motorola manual uses the term `channel` both for E1 lines and the
thirty (or 32) 'channels' inside it. I am confused.
Any help is appreciated.

Thanks and regards,
Om.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

New invalidate/clean/flush_dcache functions

[Joakim Tjernlund]

How about adding new xxx_dcache_range() functions functions to PPC.
Below is my suggestion which is more logical and more efficient:


static inline void invalidate_dcache_region(void *adr, unsigned long len)
{
	if(len == 0) return;
	len = ((len-1) >> LG_L1_CACHE_LINE_SIZE) +1;
	do {
		asm  ("dcbi     0,%0" : : "r" (adr));
		adr += L1_CACHE_LINE_SIZE;
	} while(--len > 0);
}

static inline void clean_dcache_region(void *adr, unsigned long len)
{
	if(len == 0) return;
	len = ((len-1) >> LG_L1_CACHE_LINE_SIZE) +1;
	do {
		asm  ("dcbst     0,%0" : : "r" (adr));
		adr += L1_CACHE_LINE_SIZE;
	} while(--len > 0);
	asm  ("sync" : : );
}

static inline void flush_dcache_region(void *adr, unsigned long len)
{
	if(len == 0) return;
	len = ((len-1) >> LG_L1_CACHE_LINE_SIZE) +1;
	do {
		asm  ("dcbf     0,%0" : : "r" (adr));
		adr += L1_CACHE_LINE_SIZE;
	} while(--len > 0);
	asm  ("sync" : : );
}

int *ptr1;
char *ptr2;
void *ptr3;

main()
{
	unsigned long len1 = 1600;
	unsigned long len2 = 900;
	unsigned long len3 = 702;

	invalidate_dcache_region(ptr1, len1);
	clean_dcache_region(ptr2, len2);
	flush_dcache_region(ptr3, len3);
}

/* Assembler output:
ppc_8xx-gcc -O2 -S inv_dcache.c -mregnames inv_dcache.c

        .file   "inv_dcache.c"
gcc2_compiled.:
        .section        ".text"
        .align 2
        .globl main
        .type    main,@function
main:
        li %r0,100
        mtctr %r0
        lis %r9,ptr1@ha
        lwz %r9,ptr1@l(%r9)
.L39:
        dcbi     0,%r9
        addi %r9,%r9,16
        bdnz .L39
        li %r0,57
        mtctr %r0
        lis %r9,ptr2@ha
        lwz %r9,ptr2@l(%r9)
.L30:
        dcbst     0,%r9
        addi %r9,%r9,16
        bdnz .L30
        sync
        li %r0,44
        mtctr %r0
        lis %r9,ptr3@ha
        lwz %r9,ptr3@l(%r9)
.L36:
        dcbf     0,%r9
        addi %r9,%r9,16
        bdnz .L36
        sync
        blr
.Lfe1:
        .size    main,.Lfe1-main
        .comm   ptr1,4,4
        .comm   ptr2,4,4
        .comm   ptr3,4,4
        .ident  "GCC: (GNU) 2.95.3 20010315 (release/MontaVista)"

*/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

New invalidate/clean/flush_dcache functions

[Joakim Tjernlund]

[Resending again as it did not reach the list, is it me or problems with the list?]

How about adding new xxx_dcache_range() functions functions to PPC.
Below is my suggestion which is more logical and more efficient:


static inline void invalidate_dcache_region(void *adr, unsigned long len)
{
	if(len == 0) return;
	len = ((len-1) >> LG_L1_CACHE_LINE_SIZE) +1;
	do {
		asm  ("dcbi     0,%0" : : "r" (adr));
		adr += L1_CACHE_LINE_SIZE;
	} while(--len > 0);
}

static inline void clean_dcache_region(void *adr, unsigned long len)
{
	if(len == 0) return;
	len = ((len-1) >> LG_L1_CACHE_LINE_SIZE) +1;
	do {
		asm  ("dcbst     0,%0" : : "r" (adr));
		adr += L1_CACHE_LINE_SIZE;
	} while(--len > 0);
	asm  ("sync" : : );
}

static inline void flush_dcache_region(void *adr, unsigned long len)
{
	if(len == 0) return;
	len = ((len-1) >> LG_L1_CACHE_LINE_SIZE) +1;
	do {
		asm  ("dcbf     0,%0" : : "r" (adr));
		adr += L1_CACHE_LINE_SIZE;
	} while(--len > 0);
	asm  ("sync" : : );
}

int *ptr1;
char *ptr2;
void *ptr3;

main()
{
	unsigned long len1 = 1600;
	unsigned long len2 = 900;
	unsigned long len3 = 702;

	invalidate_dcache_region(ptr1, len1);
	clean_dcache_region(ptr2, len2);
	flush_dcache_region(ptr3, len3);
}

/* Assembler output:
ppc_8xx-gcc -O2 -S inv_dcache.c -mregnames inv_dcache.c

        .file   "inv_dcache.c"
gcc2_compiled.:
        .section        ".text"
        .align 2
        .globl main
        .type    main,@function
main:
        li %r0,100
        mtctr %r0
        lis %r9,ptr1@ha
        lwz %r9,ptr1@l(%r9)
.L39:
        dcbi     0,%r9
        addi %r9,%r9,16
        bdnz .L39
        li %r0,57
        mtctr %r0
        lis %r9,ptr2@ha
        lwz %r9,ptr2@l(%r9)
.L30:
        dcbst     0,%r9
        addi %r9,%r9,16
        bdnz .L30
        sync
        li %r0,44
        mtctr %r0
        lis %r9,ptr3@ha
        lwz %r9,ptr3@l(%r9)
.L36:
        dcbf     0,%r9
        addi %r9,%r9,16
        bdnz .L36
        sync
        blr
.Lfe1:
        .size    main,.Lfe1-main
        .comm   ptr1,4,4
        .comm   ptr2,4,4
        .comm   ptr3,4,4
        .ident  "GCC: (GNU) 2.95.3 20010315 (release/MontaVista)"

*/


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: New invalidate/clean/flush_dcache functions

[Paul Mackerras]

Joakim Tjernlund writes:

> How about adding new xxx_dcache_range() functions functions to PPC.
> Below is my suggestion which is more logical and more efficient:

Why do you say it's more efficient?  Because it's inline?  Inlining
isn't necessarily a win, you know; by inlining something you can
reduce the number of instructions executed in a particular code path,
but usually you increase the size of the kernel, and together with
that, the icache footprint, which is important because you can execute
quite a lot of instructions in the time taken for one cache miss.

I'm not saying that your functions aren't more efficient, I'm saying
that you haven't established that they are more efficient.  Simply
inlining things doesn't necessarily increase efficiency.  What you
need to do is to show a measurable increase in efficiency, in the
context of the kernel, which is sufficient to justify the increased
size of the kernel.

The other thing is that you haven't included the synchronization
instructions that are required by the PPC architecture spec.

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

SV: New invalidate/clean/flush_dcache functions

[Joakim Tjernlund]

>
> Joakim Tjernlund writes:
>
> > How about adding new xxx_dcache_range() functions functions to PPC.
> > Below is my suggestion which is more logical and more efficient:
>
> Why do you say it's more efficient?  Because it's inline?  Inlining
> isn't necessarily a win, you know; by inlining something you can
> reduce the number of instructions executed in a particular code path,
> but usually you increase the size of the kernel, and together with
> that, the icache footprint, which is important because you can execute
> quite a lot of instructions in the time taken for one cache miss.

Sorry for not being more verbose. Most(all?) uses of these functions
are of the form xxx_dcache_range(ptr, ptr+len)(len is usally known at
compile time). So for the current impl. There will be one add then a
call,
inside the function there are a few instructions to set the loop
variables
then the actual loop is executed. Finally a return is executed.

In my inline functions will just use 5 or 6 instructions in total for
all
cases where len is known at compile time, which should be close to the
number of instructions needed for preparing the arguments and making the
call to the old versions(I did not check this, but I guess I will have
to)
>
> I'm not saying that your functions aren't more efficient, I'm saying
> that you haven't established that they are more efficient.  Simply
> inlining things doesn't necessarily increase efficiency.  What you
> need to do is to show a measurable increase in efficiency, in the
> context of the kernel, which is sufficient to justify the increased
> size of the kernel.

Yes I know, but in this case it should a win. I hope the above
explanation makes it clearer.

>
> The other thing is that you haven't included the synchronization
> instructions that are required by the PPC architecture spec.

Only the invalidate function is missing the sync instruction.
It's not needed. Invalidating the cache does not touch the memory
so there is no need to sync the memory. I have been running my system
without it for a long time and I asked my HW contact at Motorola about
it and he agreed. Others has used the dcbi without a sync without
problems.

Can you give me a pointer to where the spec claims that a sync is
needed after a dcbi?

    Jocke
>
> Paul.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: New invalidate/clean/flush_dcache functions

[Dan Malek]

Joakim Tjernlund wrote:
> [Resending again as it did not reach the list, is it me or problems with the list?]
>
> How about adding new xxx_dcache_range() functions functions to PPC.
> Below is my suggestion which is more logical and more efficient:

These aren't any different from what we have, other than you give it
a length instead of an ending address.  Someone has to do that
arithmetic anyway, and you chose to do it inside of your new functions
when a caller may already have it available.  We also try to keep these
functions common across multiple architectures, which is especially
important to embedded systems that may share common devices connected
to the processor bus.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

SV: New invalidate/clean/flush_dcache functions

[Joakim Tjernlund]

> Joakim Tjernlund wrote:
> >
> > How about adding new xxx_dcache_range() functions functions to PPC.
> > Below is my suggestion which is more logical and more efficient:
>
> These aren't any different from what we have, other than you give it
> a length instead of an ending address.  Someone has to do that
> arithmetic anyway, and you chose to do it inside of your new functions
> when a caller may already have it available.

I choose to let gcc do the arithmetic(and it's easier to understand for
A non assembler guy). Check the assembler output included last in my
mail.

> We also try to keep these
> functions common across multiple architectures, which is especially
> important to embedded systems that may share common devices connected
> to the processor bus.

OK, what are the other arch's that have these functions?

Merry X-mas
            Jocke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: SV: New invalidate/clean/flush_dcache functions

[Dan Malek]

Joakim Tjernlund wrote:

> OK, what are the other arch's that have these functions?

At least MIPS and ARM.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: SV: New invalidate/clean/flush_dcache functions

[Paul Mackerras]

Joakim Tjernlund writes:

> In my inline functions will just use 5 or 6 instructions in total for
> all
> cases where len is known at compile time, which should be close to the
> number of instructions needed for preparing the arguments and making the
> call to the old versions(I did not check this, but I guess I will have
> to)

Were you thinking that the address must be cacheline-aligned?  If it
isn't, the number of cachelines that you have to do depends not only
on the length parameter but also on the low-order bits of the
address.  For example, if cache lines are 16 bytes and len = 18, then
if addr = 0xc0000001 then we want to do 2 cache lines, but if addr =
0xc000000f then we need to do 3 cache lines.

> Only the invalidate function is missing the sync instruction.
> It's not needed. Invalidating the cache does not touch the memory
> so there is no need to sync the memory. I have been running my system
> without it for a long time and I asked my HW contact at Motorola about
> it and he agreed. Others has used the dcbi without a sync without
> problems.

I don't have the architecture manual to hand, it's at work.  I can
easily believe that sync after dcbi is not needed on any current 8xx
implementation, or on any 4xx either.

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

SV: SV: New invalidate/clean/flush_dcache functions

[Joakim Tjernlund]

> Joakim Tjernlund writes:
>
> > In my inline functions will just use 5 or 6 instructions in total
for
> > all
> > cases where len is known at compile time, which should be close to
the
> > number of instructions needed for preparing the arguments and making
the
> > call to the old versions(I did not check this, but I guess I will
have
> > to)
>
> Were you thinking that the address must be cacheline-aligned?  If it
> isn't, the number of cachelines that you have to do depends not only
> on the length parameter but also on the low-order bits of the
> address.  For example, if cache lines are 16 bytes and len = 18, then
> if addr = 0xc0000001 then we want to do 2 cache lines, but if addr =
> 0xc000000f then we need to do 3 cache lines.

You are right, on the other hand maybe it should be cache line aligned?
I can fix my functions but then I need to muck with the pointer address
and that will probably not generate very good assembler. Perhaps
these functions could coexist with the current ones, use the xx_range if
the address/len is not cache line aligned and mine if you know they are
cache line aligned? Invalidate on non cache line aligned memory is
usally
a bug.

>
> > Only the invalidate function is missing the sync instruction.
> > It's not needed. Invalidating the cache does not touch the memory
> > so there is no need to sync the memory. I have been running my
system
> > without it for a long time and I asked my HW contact at Motorola
about
> > it and he agreed. Others has used the dcbi without a sync without
> > problems.
>
> I don't have the architecture manual to hand, it's at work.  I can
> easily believe that sync after dcbi is not needed on any current 8xx
> implementation, or on any 4xx either.

Which arch's do need sync? I don't understand what the sync is good
for when invalidating the dcache. If it has something to with draining
the
pipe into cache, then the sync should be before the dcbi's or ...?

     Jocke

>
> Paul.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: SV: New invalidate/clean/flush_dcache functions

[Segher Boessenkool]

Joakim Tjernlund wrote:

> Only the invalidate function is missing the sync instruction.
> It's not needed. Invalidating the cache does not touch the memory
> so there is no need to sync the memory. I have been running my system

sync is not a "sync the memory" instruction, whatever that should mean.
>From chapter 8 of the 32-bit PEM:

	The sync instruction provides an ordering function for the effects of
	all instructions executed by a given processor. Executing a sync
	instruction ensures that all instructions preceding the sync instruction
	appear to have completed before the sync instruction completes, and that
	no subsequent instructions are initiated by the processor until after the
	sync instruction completes. When the sync instruction completes, all
	external accesses caused by instructions preceding the sync instruction
	will have been performed with respect to all other mechanisms that access
	memory.

dcbi can cause external accesses (it invalidates cache on _all_ cpu's in a
system, not just the local cpu).

> without it for a long time and I asked my HW contact at Motorola about
> it and he agreed. Others has used the dcbi without a sync without
> problems.
>
> Can you give me a pointer to where the spec claims that a sync is
> needed after a dcbi?

It doesn't.  Whether the sync is needed or not depends on your usage of the
dcbi, i.e. 1) is it necessary that the cache line gets invalidated on all
other cpu's, too?  and 2) do you already have another sync instruction on this
cpu, some time after the dcbi, but before the point where you have the requirement
of invalidation?

It might very well be true that a sync here isn't necessary, and sync's can be very
costly (on smp systems), but better be safe than sorry.


Cheers,

Segher


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

SV: SV: New invalidate/clean/flush_dcache functions

[Joakim Tjernlund]

> Joakim Tjernlund wrote:
>
> > Only the invalidate function is missing the sync instruction.
> > It's not needed. Invalidating the cache does not touch the memory
> > so there is no need to sync the memory. I have been running my
system
>
> sync is not a "sync the memory" instruction, whatever that should
mean.
> >From chapter 8 of the 32-bit PEM:
>
> 	The sync instruction provides an ordering function for the
> effects of
> 	all instructions executed by a given processor. Executing a
> sync
> 	instruction ensures that all instructions preceding the sync
> instruction
> 	appear to have completed before the sync instruction completes,
> and that
> 	no subsequent instructions are initiated by the processor until
> after the
> 	sync instruction completes. When the sync instruction
> completes, all
> 	external accesses caused by instructions preceding the sync
> instruction
> 	will have been performed with respect to all other mechanisms
> that access
> 	memory.
>
> dcbi can cause external accesses (it invalidates cache on _all_ cpu's
in a
> system, not just the local cpu).


OK thanks.

>
> > without it for a long time and I asked my HW contact at Motorola
about
> > it and he agreed. Others has used the dcbi without a sync without
> > problems.
> >
> > Can you give me a pointer to where the spec claims that a sync is
> > needed after a dcbi?
>
> It doesn't.  Whether the sync is needed or not depends on your usage
of
> the
> dcbi, i.e. 1) is it necessary that the cache line gets invalidated on
all
> other cpu's, too?  and 2) do you already have another sync instruction
on
> this
> cpu, some time after the dcbi, but before the point where you have the
> requirement
> of invalidation?

In my typical example I need to invalidate a buffer before I give it to
the
CPM to be used as a receive buffer. Once given to the CPM there must be
no more writes to that buffer memory. When the CPM has received data
and written the data into the buffer and hands it over to the CPU
(usally via an interrupt) the next read from the CPU must access it from
the memory.  Does the above require a sync?

Does it take some time before a invalidate is completed?

   Jocke
>
> It might very well be true that a sync here isn't necessary, and
sync's
> can be very
> costly (on smp systems), but better be safe than sorry.
>
>
> Cheers,
>
> Segher


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: SV: SV: New invalidate/clean/flush_dcache functions

[Segher Boessenkool]

Joakim Tjernlund wrote:
>
> In my typical example I need to invalidate a buffer before I give it to
> the
> CPM to be used as a receive buffer. Once given to the CPM there must be
> no more writes to that buffer memory. When the CPM has received data
> and written the data into the buffer and hands it over to the CPU
> (usally via an interrupt) the next read from the CPU must access it from
> the memory.  Does the above require a sync?

Probably not, I don't know much about the CPM though (and I assume this
is a system without any extra cpu's).

> Does it take some time before a invalidate is completed?

Depends on your cpu; I don't know the details for your cpu.  Check your
manuals :)


Segher


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

High resolution timer in driver

[bhupinder sahran]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 500 bytes --]


Hi guys

I am writting a device driver. I have a requirement
that i need a timer base interrupt serive routine
which shall be called 1024 times in a second. But my
understanding is saying that i can call it only once
in a second through generic linux timer.


Can anyone through some pointer here.

Thanx and regards
Bhupi




Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: High resolution timer in driver

[Wolfgang Denk]

In message <20040426164104.21828.qmail@web41503.mail.yahoo.com> you wrote:
>
> I am writting a device driver. I have a requirement
> that i need a timer base interrupt serive routine
> which shall be called 1024 times in a second. But my

Find an unused timer on your processor, install an interrupt  handler
for it, and finally programm it in periodic mode with f=1024 Hz.

Where is the problem?

> understanding is saying that i can call it only once
> in a second through generic linux timer.

This is definitely wrong. Wrong twice, at least.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
They say a little knowledge is a dangerous thing,  but it is not  one
half so bad as a lot of ignorance.   - Terry Pratchett, _Equal Rites_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: High resolution timer in driver

[bhupinder sahran]

I understood. It will help.

thanx a lot.

Bhupi

--- Wolfgang Denk <wd@denx.de> wrote:
> In message <20040426164104.21828.qmail@web41503.mail.yahoo.com> you wrote:
>
> > I am writting a device driver. I have a requirement that i need a
> > timer base interrupt serive routine which shall be called 1024 times
> > in a second. But my
>
> Find an unused timer on your processor, install an interrupt handler
> for it, and finally programm it in periodic mode with f=1024 Hz.
>
> Where is the problem?
>
> > understanding is saying that i can call it only once in a second
> > through generic linux timer.
>
> This is definitely wrong. Wrong twice, at least.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/