From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mundt Date: Thu, 14 Feb 2008 14:57:44 +0000 Subject: Re: ioremap() on SH Message-Id: <20080214145744.GB14777@linux-sh.org> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sh@vger.kernel.org On Thu, Feb 14, 2008 at 03:36:31PM +0100, Franck Bui-Huu wrote: > I'm puzzled by the implementation of ioremap() on SH architecture. > > Here it is: > > if (likely(PXSEG(offset) < P3SEG && PXSEG(last_addr) < P3SEG)) { > if (unlikely(flags & _PAGE_CACHABLE)) > return (void __iomem *)P1SEGADDR(offset); > > return (void __iomem *)P2SEGADDR(offset); > } > > return __ioremap(offset, size, flags); > > where 'offset' is a physical address... > > If I understand correctly PXSEG(x) is used to get the segment of a > _virtual_ address, so doing PXSEG(offset) looks weird. > In 29-bit physical mode, there is no real differentiation. P1 and P2 are both non-translatable sections that refer to the low 512M (P1 is cached, and P2 is uncached). If you're using the MIPS terminology, these are KSEG0 and KSEG1 respectively. In the nommu context the logic is simplified since we don't really have that sort of segmentation, so there's still a direct 1:1 correlation between physical and virtual there also. Thus, we can take a P2 address with a cached remap and hand back the P1 equivalent, and vice versa for cached->uncached transitions. Page table mappings are only used for certain parts of P3 and other parts of the address space. There are also non-translatable holes in the address space further along that need special care, so there is further special casing for those. The comment above the __ioremap() prototype attempts to clarify some of this. There are additional notes in arch/sh/mm/ioremap_32.c as well, mostly relating to the special casing in the P3 address space. There are also cases where address space behaviour is determined by special PTE bits relative to a given chip-select. PCMCIA and CF via area 5 and area 6 are examples of this, and are traditionally why P3 remapping requires special handling. Other P3 addresses don't generally require special casing, and can use fairly standard page table mapping. sh64 on the other hand accomplishes similar behaviour through the mapping of 512M superpages in the DTLB (using wired entries), which can be seen in arch/sh/kernel/head_64.S. Hope that helps.