On Thursday 14 January 2016 11:29:24 Thierry Reding wrote: > > It just occurred to me that none of these options really make much of a > difference. As Jon mentioned once we merge this series a lot of features > on Tegra will start to rely on PM_GENERIC_DOMAINS and hence PM. So if we > do want to build a kernel with a maximum of Tegra features enabled (and > I think a multi_v7_defconfig should include that) we'll end up with a PM > dependency anyway, whether forced via select or implied via depends on. > > I'm beginning to wonder if PM really should be an option these days. The > disadvantages of making it optional do outweigh the advantages in my > opinion. I'm not saying that, in general, it's totally useless to build > a kernel that has no PM support, but for the more specific case where > you would want to enable multi-platform support I don't think there's > much practical advantage in allowing !PM. One of the most common build > warnings are triggered because of this option. Also multi-platform > kernels are really big already, so much so that I doubt it would make a > significant difference if we unconditionally built PM support. Also the > chances are that we'll be seeing more and more SoCs support PM and rely > on it, much like Tegra would with the addition of this series. > > I imagine that we could save ourselves a lot of headaches by simply > enabling PM by default, whether that be via the PM Kconfig option or by > selecting it from ARCH_TEGRA and any other architectures that may come > to rely on it. Doing so would also reduce the amount of test coverage > that we need to do, both at compile- and runtime. I think this needs some investigation. As a general policy, we should not grow the kernel image size when moving from a traditional ARM platform to an ARCH_MULTIPLATFORM one. This is somewhat contradicted by how we already require CONFIG_OF to be set for multiplatform kernels, and that adds around 80kb to the image size. Looking at just the defconfig files, these are the ones that currently do not set CONFIG_PM: build/acs5k_defconfig/.config:# CONFIG_PM is not set build/acs5k_tiny_defconfig/.config:# CONFIG_PM is not set build/axm55xx_defconfig/.config:# CONFIG_PM is not set build/bcm2835_defconfig/.config:# CONFIG_PM is not set build/clps711x_defconfig/.config:# CONFIG_PM is not set build/ebsa110_defconfig/.config:# CONFIG_PM is not set build/footbridge_defconfig/.config:# CONFIG_PM is not set build/ks8695_defconfig/.config:# CONFIG_PM is not set build/netwinder_defconfig/.config:# CONFIG_PM is not set build/rpc_defconfig/.config:# CONFIG_PM is not set build/u300_defconfig/.config:# CONFIG_PM is not set build/vf610m4_defconfig/.config:# CONFIG_PM is not set The only ones among these are are actually multiplatform are axm55xx, bcm2835, and u300. I see no downsides of force-enabling PM for any of those, so we could decide to 'select PM' from CONFIG_ARCH_MULTIPLATFORM. The one usecase where we may want to have a modern machine without CONFIG_PM is a minimal MACH_VIRT kernel for running in a virtual machine or QEMU with minimal memory requirements, e.g. trying to squeeze a large number of guests on a single host system. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
