On Fri, Aug 22, 2014 at 4:16 PM, Jonas Gorski <jogo@xxxxxxxxxxx> wrote: > On Sat, Aug 23, 2014 at 12:10 AM, Andrew Bresticker > <abrestic@xxxxxxxxxxxx> wrote: >> On Fri, Aug 22, 2014 at 1:57 PM, David Daney <ddaney.cavm@xxxxxxxxx> wrote: >>> On 08/22/2014 01:42 PM, Florian Fainelli wrote: >>>> >>>> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@xxxxxxxxxxxx >>>> <mailto:abrestic@xxxxxxxxxxxx>> wrote: >>>> > >>>> > To be consistent with other architectures and to avoid unnecessary >>>> > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts >>>> > and build them with a common makefile. >>>> >>>> I recall reading that the ARM organization for DTS files was a bit >>>> unfortunate and should have been something like: >>>> >>>> arch/arm/boot/dts/<vendor>/ >>>> >>>> Is this something we should do for the MIPS and update the other >>>> architectures to follow that scheme? >>> >>> >>> If we choose not to intermingle .dts files from all the vendors in a single >>> directory, why do anything at all? Currently the .dts files for a vendor >>> are nicely segregated with the rest of the vendors code under a single >>> directory. >>> >>> Personally I think things are fine as they are. Any common code remaining >>> in the Makefiles could be moved to the scripts directory for a smaller >>> change. >> >> Assuming we don't move them to a common location just to segregate >> them again, it makes MIPS consistent with every other architecture >> (not just ARM!) using DT. It also makes it easier to introduce common >> changes later on, like the 'dtbs' or 'dtbs_install' make targets. > > I think having dts files under a predictable location is a good idea, > especially if it allows common code/targets as "dtbs". > > Maybe a totally insane idea, but how this for having the cake and eating it too: > > arch/mips/boot/dts/*.dts => dts files to be built along side the kernel as .dtbs > > arch/mips/<mach>/*.dts => dts files built into the kernel > > (the ../*.dts isn't meant as they should be in the top directory, just > somewhere in that sub tree) > > Because I can see a use case where you want both. For example octeon > uses generic device tree boards to use as a basis if the bootloader > did not provide one/is too old, but maybe also provide dts files for > known boards, which shouldn't be included in the kernel binary itself. I'm not sure I like having DTs in both the common and per-platform directories, but this is a use case I've been think about as well. What I'm thinking is: have "make dtbs" build all applicable DTBs for the selected platform and, based on other config options, build some subset of those DTBs in the kernel. For example: if CONFIG_RALINK, "make dtbs" builds all the {mt,rt}*_eval.dtb's and, when building the kernel, one of those dtbs may be built into the kernel based on which CONFIG_DTB_RT* option is selected (if any). I'm not sure yet what the cleanest way to do that is though. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
