From: Dan Malek <dan@embeddededge.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
Date: Fri, 6 May 2005 18:49:11 -0400 [thread overview]
Message-ID: <3ebef94782a6090ac3eb44bd7e78efbf@embeddededge.com> (raw)
In-Reply-To: <20050506133858.GA6032@logos.cnet>
On May 6, 2005, at 9:38 AM, Marcelo Tosatti wrote:
> 1) avoids the creation of pte tables in the 8Mbyte range, thus
> preserving
> the pinned TLB entry.
This has nothing to do with "preserving" the pinned TLB entry.
The pinned entries are placed into the reserved portion of the TLB,
and are never evicted. We never get a fault on these pages, so we
never look up an entry in the page table. We need to create the
page tables for informational purposes, so software or debugger
lookups will do the right thing.
> 2) restricts bootmem to above 8Mbyte region
Why is this necessary?
> 3) Memory for DMA pages must not be in the pinned region. ie. drivers
> should not allocate memory directly for DMA purposes.
Why not? It doesn't matter if we cover a VM space with a bunch of 4K
entries or a single 8M entry. The physical pages are always going to
be multiple mapped, either through the mapin_ram() space or a single 8M
entry, and also through the vmalloc() space. You just have to ensure,
in any case, that you don't access the pages through both VM spaces.
> Dan, I would really enjoy having access to some of your precious 8xx
> knowledge: share it, along with the correct way to fix this and the
> other pending issues.
The correct fix is rather simple, just make sure you configure the TLB
to reserve entries, and get the pinned entries into those reserved
entries. I know I had it right once, I don't know what happened :-)
Just hang on and I'll get you some code to test ....
Thanks.
-- Dan
next prev parent reply other threads:[~2005-05-06 22:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-05 17:20 [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries Marcelo Tosatti
2005-05-06 13:04 ` Jason McMullan
2005-05-06 11:39 ` Marcelo Tosatti
2005-05-06 16:43 ` Dan Malek
2005-05-06 13:38 ` Marcelo Tosatti
2005-05-06 22:49 ` Dan Malek [this message]
2005-05-06 20:03 ` Marcelo Tosatti
2005-05-07 3:09 ` Dan Malek
2005-05-06 23:05 ` Marcelo Tosatti
2005-05-07 4:39 ` Dan Malek
2005-05-07 5:16 ` Dan Malek
2005-05-07 13:16 ` Marcelo Tosatti
2005-05-07 20:02 ` Dan Malek
2005-05-07 15:47 ` Marcelo Tosatti
2005-05-07 14:05 ` Marcelo Tosatti
2005-05-09 6:09 ` Pantelis Antoniou
2005-05-07 14:59 ` Wolfgang Denk
2005-05-07 5:27 ` Dan Malek
2005-05-07 5:55 ` Dan Malek
2005-05-06 23:10 ` Dan Malek
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=3ebef94782a6090ac3eb44bd7e78efbf@embeddededge.com \
--to=dan@embeddededge.com \
--cc=linuxppc-embedded@ozlabs.org \
--cc=marcelo.tosatti@cyclades.com \
/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 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).