From: Sylvain Munaut <tnt@246tnt.com>
To: ppc linux embedded <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: Getting rid of static IO mapping
Date: Wed, 07 Jul 2004 19:07:20 +0200 [thread overview]
Message-ID: <40EC2DC8.5020400@246tNt.com> (raw)
In-Reply-To: <40EB1C28.3000402@246tNt.com>
Hi
I'll try to re-explain my problem more clearly. Maybe some one will
see a solution.
I'm trying to avoid any static io mapping. So no use of
setup_io_mapping. I also setup a handler for ppc_md.progress to have
early debug.
This progress function makes use of the UART, so at every call the
uart must be mapped and I have to know where.
In the current code, during platform setup, I setup BAT2 to 1:1 map
this area. So I can access it early and I know the address. But when
load_up_mmu is called, my mapping disapear ( wanted behavior ), so
from this point, I should ioremap the zone once and keep it in a
static var (to avoir ioremap/iounmap each time). The problem is to
detect WHEN I should ioremap it, detect if the load_up_mmu part is
done or not.
The solutions I have thinked of :
- Don't use BAT2 at all and ioremap it from the start. But at that
point ioremap will use io_remap_base and not the vm. So I'm not sure
it's a good idea to keep it all the time. Does the vm will know not to
use it ? And looking at the comment in arch/ppc/mm/init.c :
ioremap_base = 0xfe000000UL; /* for now, could be 0xfffff000 */
I'd say that I should avoir ioremap before mem_init_done.
- Another solution, use BAT2, then when mem_init_done == 1, ioremap.
But mem_init_done is set to 1 before load_up_mmu, so I would end up
with the same area mapped by the BATs and the pages. IIRC in the 603
manual, it's clearly noted that should not happen.
So anyone has a clue on how to do it ?
Sylvain Munaut
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-07-07 17:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-06 21:39 Getting rid of static IO mapping Sylvain Munaut
2004-07-06 22:33 ` Sylvain Munaut
2004-07-07 3:58 ` Linh Dang
2004-07-07 8:40 ` Sylvain Munaut
2004-07-07 17:07 ` Sylvain Munaut [this message]
2004-07-07 20:49 ` Dan Malek
2004-07-07 22:45 ` Sylvain Munaut
2004-07-07 23:41 ` Linh Dang
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=40EC2DC8.5020400@246tNt.com \
--to=tnt@246tnt.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 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).