From: Steve Rossi <srossi@ccrl.mot.com>
To: Dan Malek <dan@netx4.com>
Cc: Embedded Linux PPC List <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: allocating non-cacheable regions
Date: Thu, 01 Jun 2000 08:01:44 -0500 [thread overview]
Message-ID: <39365EB8.427CD744@ccrl.mot.com> (raw)
In-Reply-To: 39358E65.145F7EA3@embeddededge.com
Dan Malek wrote:
>
> > .... How can I make it so that
> > reads as well as writes to a particular page bypass the cache?
>
> You need to invalidate the data cache for this address and the TLB
> entry for this address when you set the flag. Those drivers in your
> example get away with it because the caches/TLB have been invalidated
> and not yet touched at this point. You also need to ensure you are not
> multiple mapping the same physical address....
>
I'm invalidating the TLB entry via a call to flush_tlb_page as in the examples
that you pointed me to - which simply maps to tlbia on 8xx. But I haven't yet
figured out how to invalidate the data cache for the entire page. I'm trying
invalidate_dcache_range() - but I'm having really strange problems with it. If
I compile the driver into the kernel with a call to invalidate_dcache_range(),
the kernel won't boot. (It'll get as far as "Uncompressing Linux ..." and
it'll hang). The same happens if I export invalidate_dcache_range in
ppc_ksyms.c in an attempt to load the driver as a module. I haven't looked
into what is going on here - but I do know that it is being caused by the
invalidate_dcache_range being present. Am I totally off base here? Should
I even be using invalidate_dcache_range or is there another method for
invalidating the data cache? A pointer to an example would be sufficient if
anyone has one.
Thanks,
Steve
--
-------------------------------------------------------
Steven K. Rossi srossi@ccrl.mot.com
Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-06-01 13:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-03 15:47 allocating non-cacheable regions Steve Rossi
2000-05-03 19:52 ` Dan Malek
2000-05-04 6:45 ` MPC860 enet driver dony
2000-05-31 20:53 ` allocating non-cacheable regions Steve Rossi
2000-05-31 22:12 ` Dan Malek
2000-05-31 22:39 ` Tom Roberts
2000-06-01 13:01 ` Steve Rossi [this message]
2000-06-01 20:10 ` Steve Rossi
2000-06-02 14:24 ` Steve Rossi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39365EB8.427CD744@ccrl.mot.com \
--to=srossi@ccrl.mot.com \
--cc=dan@netx4.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.