From: Matt Porter <porter@cox.net>
To: Sangmoon Kim <dogoil@etinsys.com>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: map iomem in linux_2_4_dev
Date: Tue, 28 May 2002 06:23:51 -0700 [thread overview]
Message-ID: <20020528062351.A2267@home.com> (raw)
In-Reply-To: <022501c20633$cbeb4f10$1a11efcb@industrialDiv.hanasys.co.kr>; from dogoil@etinsys.com on Tue, May 28, 2002 at 07:38:19PM +0900
On Tue, May 28, 2002 at 07:38:19PM +0900, Sangmoon Kim wrote:
>
> Hi,
> >
> > No, that's rubbish. Use one or the other. ioremap() takes a physical
> > address and returns the virtual address at which it mapped it.
> >
> Sometimes it is needed to use io_block_mapping and ioremap.
> io_block_mapping maps a phiscal address to a virtual address.
> And ioremap returns the virtual address.
> When I ported linux on an MPC755 based custom board.
> My hardware didn't running because it had a serial port at 0x78000000.
> Linux uses 0 to 0x7fffffff as a virtual memory for applications.
> And the address of 0x78000000 overlaped the serial port.
> I had to use io_block_mapping to map it at different location on system initialization,
> and ioremap to get the mapped address on serial port driver.
> I'm sorry, if it's another rubbish.
You don't need io_block_mapping. Follow one of the many examples to
use early_serial_init with an ioremap call for your UART.
The only reason your method works is that the io_block_mapping is
actually using a BAT on our classic PPC platform. ioremap will
look for an existent BAT mapping and just return the translated
virtual address in this case. Relying on this is bad practice
since it will not work on other PPC systems.
As David correctly pointed out, only use io_block_mapping when
you absolutely must control the placement of the virtual address.
There are cases when this is necessary since the hardware engineers
always send us garbage to support. Mapping a UART at init time is
not one of these.
BTW, your UART at physical 0x78000000 has zero bearing on the default
PPC Linux task size virtual addresses from 0-0x7fffffff.
Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-05-28 13:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-28 10:38 map iomem in linux_2_4_dev Sangmoon Kim
2002-05-28 13:23 ` Matt Porter [this message]
2002-05-29 4:57 ` Sangmoon Kim
2002-05-29 5:47 ` Roland Dreier
2002-05-29 6:01 ` Sangmoon Kim
2002-05-29 5:47 ` David Gibson
2002-05-29 6:14 ` Sangmoon Kim
2002-05-29 12:48 ` shaowei dai
-- strict thread matches above, loose matches on Subject: below --
2002-05-27 5:59 shaowei dai
2002-05-27 6:34 ` David Gibson
2002-05-27 6:51 ` shaowei dai
2002-05-27 8:13 ` Sangmoon Kim
2002-05-27 8:13 ` shaowei dai
2002-05-28 0:36 ` David Gibson
2002-05-28 4:42 ` Sangmoon Kim
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=20020528062351.A2267@home.com \
--to=porter@cox.net \
--cc=dogoil@etinsys.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).