[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF60EFC2CD.F8FB1D23-ONC1257220.00315F90-C1257220.0038B8E3@de.ibm.com>
Date: Wed, 8 Nov 2006 11:22:27 +0100
From: Christoph Raisch <RAISCH@...ibm.com>
To: Roland Dreier <rdreier@...co.com>
Cc: Hoang-Nam Nguyen <hnguyen@...ibm.com>,
linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
openib-general@...nib.org, rolandd@...co.com
Subject: Re: [PATCH 2.6.19 2/4] ehca: hcp_phyp.c: correct page mapping in 64k page
mode
Roland Dreier wrote on 07.11.2006 20:25:12:
> > - *mapaddr = (u64)(ioremap(physaddr, EHCA_PAGESIZE));
> > + *mapaddr = (u64)ioremap((physaddr & PAGE_MASK), PAGE_SIZE) +
> > + (physaddr & (~PAGE_MASK));
>
> I'm confused -- shouldn't ioremap() do the right thing even if
> physaddr isn't page-aligned? Why is this needed?
>
> - R.
ioremap maps 4k pages on 4k kernels and on 64k pages on 64k kernels. So far
the theory.
This is true for memory.
For mapped PCI or ebus registers things are a bit different.
Some PCI adapters expect that every other 4k page is a new area with
different meaning starts
(some PCI adapters are definetly ehca and mellanox here). The consequence
is you have to map
only 4k instead of 64k, otherwise you'd map 15 other "access areas" are
also mapped.
On POWER the ebus memory is mapped by H_ENTER.
The hypervisor checks for 4k page size on H_ENTER, reason see above.
The nopage handler now does seperate 4k H_ENTERs even for 64k pages in the
ebus area,
therefore we have to register a 64k page on a 64k boundary, and the nopage
triggers the right H_ENTER
as soon as we access the page at the right offset.
We plan to change that as soon as the base kernel can handle mixed
pagesizes in a more official way.
Christop R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists