[lkml]   [2012]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Making ARM multiplatform kernels DT-only?
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.


> 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

 \ /
  Last update: 2012-05-04 19:01    [W:0.147 / U:4.212 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site