* Question about porting VxWorks driver
@ 2003-04-03 8:11 Donald White
2003-04-03 15:27 ` Dan Malek
2003-04-03 15:41 ` Vladimir Gurevich
0 siblings, 2 replies; 3+ messages in thread
From: Donald White @ 2003-04-03 8:11 UTC (permalink / raw)
To: linux-embedded
I am porting a Vxworks driver for an encryption chip from Vxworks to Linux on a
cutom MPC860 board. The Linux is HHL 2.0. The driver communicates with the chip
through chip registers and shared memory buffers. The VxWorks driver set the system
memory cache policy to writethrough. I am using ioremap for the chip registers and
consistent_alloc for the shared buffers. This all works fine. Now for my questions.
Is this the right approach for me to take? Does Linux support designating memory
regions for writethrough caching? If it does, should I use it rather than doing
what I am doing?
Thanks,
Don
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Question about porting VxWorks driver
2003-04-03 8:11 Question about porting VxWorks driver Donald White
@ 2003-04-03 15:27 ` Dan Malek
2003-04-03 15:41 ` Vladimir Gurevich
1 sibling, 0 replies; 3+ messages in thread
From: Dan Malek @ 2003-04-03 15:27 UTC (permalink / raw)
To: Donald White; +Cc: linux-embedded
Donald White wrote:
> Is this the right approach for me to take? Does Linux support
> designating memory
> regions for writethrough caching? If it does, should I use it rather
> than doing
> what I am doing?
Writethough policies to I/O devices seems kind of weird. If there
is a performance advantage because you are treating the device like
memory and using it to store buffers you will soon read again (unchanged),
you are likely to see even higher performance if you allocate system
memory in copyback mode for this purpose and just copy the data to
the I/O device when necessary.
I suspect writethrough was used to avoid cache flushing operations,
but uncached would likely result in better system performance because
you aren't blowing away cache lines useful to other software in
the system.
Linux does not support writethrough attributes through any memory
management functions, it only selects between cached and uncached
policies. On 8xx, you can globally select all cached memory to be
writethrough (usually for debugging), and *all* ioremap() areas are uncached.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Question about porting VxWorks driver
2003-04-03 8:11 Question about porting VxWorks driver Donald White
2003-04-03 15:27 ` Dan Malek
@ 2003-04-03 15:41 ` Vladimir Gurevich
1 sibling, 0 replies; 3+ messages in thread
From: Vladimir Gurevich @ 2003-04-03 15:41 UTC (permalink / raw)
To: Donald White; +Cc: linux-embedded
Hello Donald,
Is it one of Hifn chips by any chance? If yes, then I can
tell you that their drivers do not know about cache flushes
and invalidates at all, which presents a real challenge on
PowerPC.
Writeback cache usually won't work. You have to manually
flush it before sending a message to the board and invalidate
it after you receive the encrypted (decrypted) message back.
If you do the transformation "in-place" then you can use
flush-and-invalidate before seding the message. Using uncached
memory is another option, but if you want to do further
processing without copying data to a cached buffer, you
performance will likely suffer.
In general you keep data buffers in cached memory and
do manual flushes/invalidates when needed, but keep
buffer descriptors and other similar structures (as
well as chip's registers and chip's private memory)
in uncached space.
Best regards,
Vladimir
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-04-03 15:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-04-03 8:11 Question about porting VxWorks driver Donald White
2003-04-03 15:27 ` Dan Malek
2003-04-03 15:41 ` Vladimir Gurevich
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).