linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* 64 bit memory access
@ 2000-12-29 17:08 Tim Montgomery
  2000-12-29 18:09 ` Dan Malek
  0 siblings, 1 reply; 3+ messages in thread
From: Tim Montgomery @ 2000-12-29 17:08 UTC (permalink / raw)
  To: linuxppc-dev, tjmontgo


Hello,

I have a quandary.

My platform is a PowerPC (MPC750) based embedded machine.

I have a device (memory-mapped) that I need to access that lives on an
internal peripheral bus but has the unfortunate constraint of allowing
only 64bit-wide writes.  Any write of a smaller width results in an
exception generated by the memory controller.

Drivers exist for this device for other, lesser OSs that use FP regs to
write the 64bit quantity to the bus (using lfd and stfd).  However, from
what I gather, using the FP regs in kernel drivers under Linux kernel
(2.4.0test12-based) seems to be a no-no.

I am afraid I am at an impasse.

I need to:
1.) figure out a way to perform a 64bit write via other means
OR
2.) make sure I don't screw up user mode FP usage (potential consequence
of dinking with FP while in the kernel?)

Any suggestions/insight would be appreciated.

Regards,
Tim

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 64 bit memory access
  2000-12-29 17:08 64 bit memory access Tim Montgomery
@ 2000-12-29 18:09 ` Dan Malek
  2000-12-29 20:52   ` Tony Mantler
  0 siblings, 1 reply; 3+ messages in thread
From: Dan Malek @ 2000-12-29 18:09 UTC (permalink / raw)
  To: Tim Montgomery; +Cc: linuxppc-dev


Tim Montgomery wrote:

> I need to:
> 1.) figure out a way to perform a 64bit write via other means

Cache the location.  When you access the space the processor will
do a 64-bit read.  You will have to run in copyback mode then when
done updating the location push the cache line to the device.

> Any suggestions/insight would be appreciated.

Using 64-bit only I/O, and FP registers on a 32-bit processor is
an interesting hardware/software hack, but not a very good system
design.

I guess we could write some kernel 64-bit I/O functions that use
an FP register.  This would require disabling interrupts, enabling
the FPU in the kernel, saving a register, doing the I/O, restoring the
register, disabling the FPU, and enabling interrupts.  Not very efficient
when a proper 60x bus implementation that allowed sizing would have
been really fast.........


	-- Dan

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 64 bit memory access
  2000-12-29 18:09 ` Dan Malek
@ 2000-12-29 20:52   ` Tony Mantler
  0 siblings, 0 replies; 3+ messages in thread
From: Tony Mantler @ 2000-12-29 20:52 UTC (permalink / raw)
  To: Dan Malek, Tim Montgomery; +Cc: linuxppc-dev


At 12:09 PM -0600 12/29/2000, Dan Malek wrote:
>Tim Montgomery wrote:
[...]
>> Any suggestions/insight would be appreciated.
>
>Using 64-bit only I/O, and FP registers on a 32-bit processor is
>an interesting hardware/software hack, but not a very good system
>design.
>
>I guess we could write some kernel 64-bit I/O functions that use
>an FP register.  This would require disabling interrupts, enabling
>the FPU in the kernel, saving a register, doing the I/O, restoring the
>register, disabling the FPU, and enabling interrupts.  Not very efficient
>when a proper 60x bus implementation that allowed sizing would have
>been really fast.........

I'm almost tempted to say that the classic BSD-ish meme might apply here:

Q: How do I work around XYZ hardware bogosity?
A: Buy better hardware.

But of course, back in the world of linux, the "We Luv Everybody" OS, hope
still lays in the form of unmergable patchsets, but I would be dissapointed
if IO functions like these were to their way into any mainstream kernel.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-12-29 20:52 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-12-29 17:08 64 bit memory access Tim Montgomery
2000-12-29 18:09 ` Dan Malek
2000-12-29 20:52   ` Tony Mantler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).