On Thu, 2008-10-16 at 06:22 +0400, Ilya Yanok wrote: > These patches add support for selecting page size on PPC 44x. > First one adds support for 16K/64K pages while second one adds support > for 256K pages along with some hacks. > > However there are still number of problems: > 1. We can't use default PKMAP_BASE definition with 64KB/256KB pages so > we change it. Not sure that it's optimal. Then redefined PKMAP_BASE is > not aligned on (1<<PMD_SHIFT), don't know if it is really bad.
Well, the main thing is the implementation of kmap and kmap_atomic. They both basically assumes that all the reserved PTEs for kmap and kmap_atomic are in a single PTE page since it uses a simple addition (substraction for _atomic really but heh, that's about the same). Note that PKMAP (kmap) and FIXMAP (kmap_atomic) can be in two different PTE pages. But it's important that the whole PKMAP is entirely contained within a PTE page. It doesn't have to -start- on a PTE page boundary though. > 2. with 16KB/64KB/256KB pages WARN_ON(!pmd_none(*pmd)) is triggered > inside dma_alloc_init() function. Not sure if it is really bad. I think that's a bogus WARN_ON. > 3. with 256KB pages ENTRIES_PER_PAGEPAGE in mm/shem.c become zero. Yeah well, I'd like to keep that 256K page separate for now, let's focus on merging 16K/64K support first. > 4. We use asm-offsets mechanism to make PTE_SHIFT/PMD_SHIFT available in > assembler but we don't really need the power of asm-offsets here. Maybe > it will be more convinient to just take these defines out of #ifndef > __ASSEMBLY__? But this would change asm-generic... We sure should do that. I don't think of a reason why those need to be protected by __ASSEMBLY__. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
