Making ARM multiplatform kernels DT-only?

[robherring2@gmail.com (Rob Herring)]

On 05/04/2012 07:20 AM, Arnd Bergmann wrote:
> On Thursday 03 May 2012, Russell King - ARM Linux wrote:
>> I'm basing my comments off mach-zynq.
> 
> It's a different question because mach-zynq is already DT-only, but we
> can also discuss this for a bit.
> 
>> How about we take the following steps towards it?
>>
>> 1. create arch/arm/include/mach/ which contains standardized headers
>>    for DT based implementations.  This must include all headers included
>>    by asm/ or linux/ includes.  This will also be the only mach/ header
>>    directory included for code outside of arch/arm/mach-*.  This also
>>    acts as the 'default' set of mach/* includes for stuff like timex.h
>>    and the empty hardware.h
>>
>> 2. DT based mach-* directories do not have an include directory; their
>>    include files must be located in the main include/ heirarchy if shared
>>    with other parts of the kernel, otherwise they must be in the mach-*
>>    directory.
> 
> My idea for the header files was slightly different, reorganizing only
> the headers that actually conflict between the platforms renaming the
> ones that conflict by name but not by content.
> 
> I know you are aware of my experiment with just renaming the header files
> from mach/*.h to mach-*/*.h, and that has helped me a lot in understanding
> the specific problems. I don't care about the specific names of the headers
> but it has helped so far in identifying which drivers are already relying
> on a specific platform's version of a header and which ones multiplex
> between different platforms (e.g. sa1100/pxa/mmp or s3c*/s5p*/exynos)
> and need more work. 
> 
> I also wouldn't change anything for the current configurations where
> you only have one mach-* directory at a time (or the samsung speciality).
> 
> My plan is to have multiplatform kernels in parallel with what we have now,
> so we can avoid breaking working machines but also play with multiplatform
> configurations at the same time for a subset of the platforms and with
> certain restrictions (not all board files, not all drivers, no generic
> early printk, ...).
> 

Many of the headers are simply platform_data structs which may still be
needed on DT platforms, but could be moved elsewhere.

>> 3. Allow build multiple mach-* directories (which we already do... see
>>    the samsung stuff.)
> 
> Incidentally, the samsung headers are what are currently causing the most
> headaches regarding the header files, because they use a lot of files
> with soc-specific definitions for the same symbols, which means significant
> reorganization of the code using to to turn that into run-time selectable
> values.
> 
>> We still have irqs.h being SoC dependent, and we still haven't taken
>> debug-macros.S far enough along to get rid of that.
> 
> I believe the irqs.h conflict is only for the NR_IRQS constant, all other
> defines in there should only be used inside of the mach-* directory,
> or not at all for fully DT-based platforms.

A DT-enabled platform does not need irqs.h or NR_IRQS. SPARSE_IRQ should
be selected for DT. However, some DT enabled platforms don't have all
irq chips converted to domains and may still need to set the mach .nr_irqs.

> 
>> Then there's also the problem of uncompress.h.  The last piece of the
>> puzzle is the common clock stuff.

The smp/hotplug/localtimer related functions are still global. Marc Z
has posted patches for this, but I haven't seen recent activity. This
and clocks were the 2 main issues I saw trying to build 2 platforms
together. highbank and picoxcell could be built together since only
highbank has clocks and smp.

gpio.h is still required, but empty for most platforms.

Rob

> Initially, I think we can live without debug-macros.S and uncompress.h
> and change the code using those to just not output anything when
> MULTIPLATFORM is enabled: you'd have to disable MULTIPLATFORM in order
> to debug the early boot process and hope that any bugs are not
> specific to multiplatform configurations. In the long run, we probably
> want to have a better solution, but it's not on my hotlist.
> 
> The common clock support OTOH is definitely a requirement as soon as
> we want to actually run multiplatform kernels rather than just building
> them.
>  
>> So, I think we're still a way off it yet - maybe six months or so.
> 
> True, but in order to work on the points you raised and a few others,
> I would like to know where we're heading because it does impact
> some decisions like whether we need to make all initcalls in non-DT
> board files aware of potentially being run on other platforms.
> 
> 	Arnd
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel