64 bit memory access - again ...

64 bit memory access - again ...

[Shie Erlich]

( i know this has been talked about before, but i couldn't get
  a complete answer from reading the posts, so ... )

i'm porting linux to a powerPC750 and have the following problem:
we have a piece of hardware whose memory region can only be
written or read to using 64bit memory access.
(i know it's a bad design, but as usual, it's not up to me ;-)

as far as i know, there are 2 ways to do a 64bit access on a 750:
1) use the FPU and do a floating point access
2) something about using a cache line and flushing it (don't know
   anymore about this one)

i also know that floating point in the kernel is a big NO, but if no other
choice is found, i'll have to do it. my questions are:

a) what is the recommended way of doing a 64bit access in the linux kernel ?
b) if the fpu is the way to go, what do i need to do so that the kernel does
not
    trap my floating point access ? details here would be greatly
appriciated ;-)


any help anyone can offer will be great,

                            thanks
 			shie erlich


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

Re: 64 bit memory access - again ...

[Dan Malek]

Shie Erlich wrote:


> i also know that floating point in the kernel is a big NO, but if no other
> choice is found, i'll have to do it. my questions are:

If possible, I would mmap() the device from user space and perform
the access there.

> a) what is the recommended way of doing a 64bit access in the linux kernel ?

I would first try to do it with a cache line burst access.  Put it in
copyback mode, zero the line, write the line, flush the line, invalidate
the line.

> b) if the fpu is the way to go, what do i need to do so that the kernel does
> not
>     trap my floating point access ?

You can't trap and emulate, that defeats the purpose.  The biggest challenge
when using floating point in the kernel is context switching the FPU.
I would probably force the kernel to always context switch the FPU (as
it does on SMP) so you would always have a clean context to use in
the kernel.  I would then disable interrupts (to avoid other FPU context
problems), enable the FPU, perform the access, ensure the context is
reloaded for the switched-in thread, disable the FPU, enable interrupts.

Any system performance gains you thought you may have by using 64-bit
I/O are likely to be significantly reduced by the amount of software
overhead needed to manage this.

Depending upon what you are using for a bridge/memory controller you
may have a DMA controller that could perform this access as well.


	-- Dan


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

RE: 64 bit memory access - again ...

[Shie Erlich]

> a) what is the recommended way of doing a 64bit access in the linux kernel
?
>
>>I would first try to do it with a cache line burst access.  Put it in
>>copyback mode, zero the line, write the line, flush the line, invalidate
>>the line.

i tried that: first, i mapped the memory region as _PAGE_RW | _PAGE_GUARDED,
making
it cachable and since no _PAGE_WRITETHRU - it is supposed to be set in
writeback mode.
i tried writing to the address i need (a simple long long*) and than to
flush and invalidate
the address using the following function (found in arch/ppc/kernel/misc.S):
<===========================================================================
=========>
_GLOBAL(flush_dcache_range)
       li      r5,CACHE_LINE_SIZE-1
       andc    r3,r3,r5
       subf    r4,r3,r4
       add     r4,r4,r5
       srwi.   r4,r4,LG_CACHE_LINE_SIZE
       beqlr
       mtctr   r4

#if defined(CONFIG_IBM405_REVB) || defined(CONFIG_IBM405_REVC)
1:      mfmsr   r5
        li      r7,0
        ori     r7,r7,MSR_EE
        andc    r7,r5,r7
        mtmsr   r7
        dcbt    0,r3
        dcbf    0,r3
        mtmsr   r5
#else
1:     dcbf    0,r3
#endif
       addi    r3,r3,CACHE_LINE_SIZE
       bdnz    1b
       sync                            /* wait for dcbf's to get to ram */
       blr
<===========================================================================
=========>

the function accepts 2 parameters: start address and stop address. i tried
calling it
as flush_dcache_range(MY_ADDRESS, MY_ADDRESS + 8) - to flush the 64 bit i
need.
this did not work, and obviously, i'm doing something really wrong here.
any clues ???



>> b) if the fpu is the way to go, what do i need to do so that the kernel
does
>> not trap my floating point access ?
>
>You can't trap and emulate, that defeats the purpose.  The biggest
challenge
>when using floating point in the kernel is context switching the FPU.
>I would probably force the kernel to always context switch the FPU (as
>it does on SMP) so you would always have a clean context to use in
>the kernel.  I would then disable interrupts (to avoid other FPU context
>problems), enable the FPU, perform the access, ensure the context is
>reloaded for the switched-in thread, disable the FPU, enable interrupts.

the FPU solution does work, however (and thanks for the pointers) - but if
my
function saves the fpu registers and restores them, do i really need to
force
the kernel to context switch the fpu ?


		thanks for your help.
			shie erlich


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

Re: 64 bit memory access - again ...

[Dan Malek]

Shie Erlich wrote:


> the FPU solution does work, however (and thanks for the pointers) - but if
> my
> function saves the fpu registers and restores them, do i really need to
> force
> the kernel to context switch the fpu ?

You have to be careful that moving the bits in/out of the FP register
doesn't have other side effects in FP status or condition codes.  Always
saving/restoring the context will guarantee the application doesn't see
these side effects, but you can experiment if you wish.

Good Luck.


	-- Dan


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