On Thu, Jul 28, 2011 at 02:44:17PM -0400, Nicolas Pitre wrote: > On Thu, 28 Jul 2011, Dave Martin wrote:
[...] > > Currently, device tree is not fully supported upstream for vexpress. > > Lorenzo Pieralisi wrote some patches, but there were a few outstanding > > issues and these weren't merged yet. > > > > It could make sense for me to take a look at this, since vexpress is > > also the base for our initial Cortex-A15 refernece platform. With > > the right people around next week, we have a chance to get any issues > > thrashed out more quickly. > > > > Is this a good idea for next week, or should we be focusing more on > > core issues? > > DT enablement will also be an important topic next week. I'm sure > you'll be appreciated whatever you work on. OK, I may spend some time on that then. Lorenzo will be around for some of the time too. > > Some more thoughts: > > > > > 1.1.5) Other weird things > > > > > > Some machines have non linear memory maps or bus address translations, > > > sparsemem, etc. Examples of that are: > > > > > > arch/arm/mach-realview/include/mach/memory.h > > > arch/arm/mach-integrator/include/mach/memory.h > > > > > > I think solving this is out of scope for this round. Deleting > > > arch/arm/mach-*/include/mach/memory.h can't be done universally. So a > > > new Kconfig symbol (NO_MACH_MEMORY_H) is introduced to indicate which > > > machine class has its legacy <mach/memory.h> file removed. The single > > > zImage for multiple targets will be restricted, amongst other things, to > > > those machines or SOCs with that symbol selected. Partial result here: > > > http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/heads/redux > > > > One possibility here is to enable any non-sparsemem platform to be > > built with sparsemem enabled by just defining a single memory block > > in this case to encompass the platform's RAM. I believe that platforms > > which have small I/O holes in their memory maps can continue to use > > memblock_reserve techniques as before -- there's no need to represent > > the holes via sparsemem (which would be expensive) > > > > Having talked to Will Deacon about this, it sounds like the feasibiltiy > > and performance impact may depend on how often things like pfn_valid get > > called when sparsemem is enabled. > > > > Is this worth looking into? > > Certainly, especially given your bias. ;-) > > The sparsemem might get pretty inefficient if the build time constants > such as SECTION_SIZE_BITS can't be relied upon though. I will try and take a look. We may find that a lot of platforms can be supported with a single, sane definition of SECTION_SIZE_BITS. If they can't all be supported by the same definition, this at least grows the single zImage kernel scope to include more platforms. > > I have a slightly biased interest in this, since ARM seems to like > > funky memory maps for many of its newer boards, and it would be > > unfortunate for these to get left out of the whole single effort. > > > > Of course we could include those platforms in non-sparsemem kernels, > > but since that will often mean sacrificing half the RAM, this is > > far from ideal. > > Maybe that half could simply be pushed to home. Eh? > > LPAE (Seems to fit neatly under "weird things" for now ;) > > > > Do we care strongly about supporting LPAE and non-LPAE platforms > > in a single kernel? > > No. I think that would be rather insane. The page table definitions > have deep repercussions all over the place, often in performance critical > paths down in core kernel code. Trying to introduce variable elements > which are otherwise build time optimized constants is probably not going > to find many followers. Subtle hint taken ;) [...] > > We could even embed the printch() function body into the DT if we > > wanted to make the kernel's job even simpler. Realistic implementations > > of this function are tiny, so this shouldn't be too cumbersome. > > That really seems an abuse of the DT though, since this goes beyond > > just describing the hardware. > > Well... I'm not entirely against the idea. This could be seen as the > most efficient way to describe how to output a character over some > serial device for the given hardware. The danger is that some vendors > might be tempted to abuse that idea by stuffing BIOS-like services in > there that the kernel would have to cope with. See my reply to Arnd... It's not high priority anyway. Cheers ---Dave _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
