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?
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
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, ...).
- 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.
Then there's also the problem of uncompress.h. The last piece of the puzzle is the common clock stuff.
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