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%3Ba=shortlog%3Bh=refs/h...
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