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-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
