| Message ID | 1965890.bT7bZyQJt8@amdc1032 (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Friday, August 29, 2014 08:05:49 PM Bartlomiej Zolnierkiewicz wrote: > +CONFIG_VIDEO_RENESAS_VSP1=y > > This seems to be another option for Renesas specific hardware and it has > a footprint of 23kB. s/23/38/ [ sorry for the mistake ] > [ I think that this option should depend on ARCH_SHMOBILE. ] Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 29 August 2014 20:05:49 Bartlomiej Zolnierkiewicz wrote: > I've been looking lately into making it possible to easily go > from multi_v7_defconfig config to a single platform one (in my > case Exynos one) and removing the need to keep the latter (i.e. > exynos_defconfig) in the kernel tree in the long-term. > > Because of this I've noticed that some config options for platform > specific hardware that are selected in multi_v7_defconfig don't > have proper dependencies. This results in more complex than > necessary single platform configs (obtained from a multiplatform > config) and unnecessarily bigger resulting kernel images. > > Your patch also adds/uncovers some such config options. > > Lets first look at sizes of resulting vmlinux images for single > platform Exynos config before and after your patch: > > $ size vmlinux.* > text data bss dec hex filename > 7817317 517188 278992 8613497 836e79 vmlinux.before > 7978325 527012 279056 8784393 860a09 vmlinux.after > > (=> the patch results in 170kB bigger vmlinux size) > Interesting work. We don't currently have a policy for this, so we should first talk about whether the behavior that you want is desirable. The alternative would be that everybody who wants to build a platform-specific kernel out of multi_v7_defconfig has to go through the extra work of not only disabling the platforms but also the individual drivers for the other platforms. This is a bit tricky for drivers that may be shared between a few platforms in multi_v7_defconfig but are meaningless on the others. We could solve that by having more complex dependencies for each of those drivers, but that is where maintaining those gets really messy. A related problem that I think is more significant is that some platforms 'select' a particular driver and when you disable the platform, that driver is suddenly removed from the defconfig for all other platforms as well. This has bitten us a few times in the past, and I'd really like to fix those cases first. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arnd Bergmann wrote: > Hi, > On Friday 29 August 2014 20:05:49 Bartlomiej Zolnierkiewicz wrote: > > I've been looking lately into making it possible to easily go > > from multi_v7_defconfig config to a single platform one (in my > > case Exynos one) and removing the need to keep the latter (i.e. > > exynos_defconfig) in the kernel tree in the long-term. > > Why? I don't have any idea why we should use only multi_v7_defconfig for each hardware platform. In my understanding, multi_v7_defconfig can be used for one kernel image can support all of the platforms but it doesn't mean it should be used for each platform. And I think, if we cannot maintain each platform's defconfig in mainline, it will be kept in each SoC vendor and it is not a good way. I mean both defconfigs has each value in mainline, exynos_defconfig should be updated though ;) > > Because of this I've noticed that some config options for platform > > specific hardware that are selected in multi_v7_defconfig don't > > have proper dependencies. This results in more complex than > > necessary single platform configs (obtained from a multiplatform > > config) and unnecessarily bigger resulting kernel images. > > > > Your patch also adds/uncovers some such config options. > > > > Lets first look at sizes of resulting vmlinux images for single > > platform Exynos config before and after your patch: > > > > $ size vmlinux.* > > text data bss dec hex filename > > 7817317 517188 278992 8613497 836e79 vmlinux.before > > 7978325 527012 279056 8784393 860a09 vmlinux.after > > > > (=> the patch results in 170kB bigger vmlinux size) > > > > Interesting work. We don't currently have a policy for this, > so we should first talk about whether the behavior that you > want is desirable. The alternative would be that everybody > who wants to build a platform-specific kernel out of > multi_v7_defconfig has to go through the extra work of not > only disabling the platforms but also the individual drivers > for the other platforms. > > This is a bit tricky for drivers that may be shared between > a few platforms in multi_v7_defconfig but are meaningless > on the others. We could solve that by having more complex > dependencies for each of those drivers, but that is where > maintaining those gets really messy. > Agreed and it is not required. > A related problem that I think is more significant is that > some platforms 'select' a particular driver and when you > disable the platform, that driver is suddenly removed from the > defconfig for all other platforms as well. This has bitten > us a few times in the past, and I'd really like to fix those > cases first. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd, On Fri, Aug 29, 2014 at 10:11 PM, Arnd Bergmann <arnd@arndb.de> wrote: > A related problem that I think is more significant is that > some platforms 'select' a particular driver and when you > disable the platform, that driver is suddenly removed from the > defconfig for all other platforms as well. This has bitten > us a few times in the past, and I'd really like to fix those > cases first. Indeed. "select" is evil, and has a devastating effect on minimal defconfigs (lots of churn and nasty surprises like the one you mentioned). So it actually makes more sense to derive multi_v7_defconfig from the individual platform's defconfigs. I also have a script for that, which I wrote to create m68k's multi_defconfig a long time ago: https://github.com/geertu/linux-scripts/blob/master/linux-config-merge In the long run, I think creating defconfigs from DTS is the way to go. Extracting dependencies from the build system (both Makefile and the myriad of complex dependencies in Kconfig) are the biggest hurdles to solve. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 29, 2014 at 08:05:49PM +0200, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Thursday, August 28, 2014 04:00:28 PM Geert Uytterhoeven wrote: > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > --- > > Based on next-20140828 > > For now excluding r8a7740/armadillo, as it fails to boot on armadillo > > > > arch/arm/configs/multi_v7_defconfig | 51 +++++++++++++++++++++++++++++++++++-- > > 1 file changed, 49 insertions(+), 2 deletions(-) > > I've been looking lately into making it possible to easily go > from multi_v7_defconfig config to a single platform one (in my > case Exynos one) and removing the need to keep the latter (i.e. > exynos_defconfig) in the kernel tree in the long-term. > > Because of this I've noticed that some config options for platform > specific hardware that are selected in multi_v7_defconfig don't > have proper dependencies. This results in more complex than > necessary single platform configs (obtained from a multiplatform > config) and unnecessarily bigger resulting kernel images. > > Your patch also adds/uncovers some such config options. > > Lets first look at sizes of resulting vmlinux images for single > platform Exynos config before and after your patch: > > $ size vmlinux.* > text data bss dec hex filename > 7817317 517188 278992 8613497 836e79 vmlinux.before > 7978325 527012 279056 8784393 860a09 vmlinux.after > > (=> the patch results in 170kB bigger vmlinux size) > > and the configs diff later: > > --- multi_v7_exynos_only 2014-08-29 12:29:31.881485357 +0200 > +++ multi_v7_exynos_only_shmobile 2014-08-29 12:36:24.361496247 +0200 > @@ -70,6 +70,8 @@ > CONFIG_BRCMSTB_GISB_ARB=y > CONFIG_VEXPRESS_CONFIG=y > CONFIG_MTD=y > +CONFIG_MTD_M25P80=y > +CONFIG_MTD_SPI_NOR=y > CONFIG_BLK_DEV_LOOP=y > CONFIG_ICS932S401=y > CONFIG_APDS9802ALS=y > @@ -86,11 +88,13 @@ > CONFIG_MVMDIO=y > CONFIG_KS8851=y > CONFIG_R8169=y > +CONFIG_SH_ETH=y > > This seems to be option for Renesas specific hardware and it has > a footprint of 23kB. > > [ I think that this option should depend on ARCH_SHMOBILE || ARCH_SH. ] > > CONFIG_SMSC911X=y > CONFIG_STMMAC_ETH=y > CONFIG_AT803X_PHY=y > CONFIG_MARVELL_PHY=y > CONFIG_ICPLUS_PHY=y > +CONFIG_MICREL_PHY=y > > This gets selected by CONFIG_SH_ETH and costs us 4kB. > > CONFIG_USB_PEGASUS=y > CONFIG_USB_USBNET=y > CONFIG_USB_NET_SMSC75XX=y > @@ -110,6 +114,7 @@ > CONFIG_SERIAL_8250=y > CONFIG_SERIAL_8250_CONSOLE=y > CONFIG_SERIAL_8250_DW=y > +CONFIG_SERIAL_8250_EM=y > CONFIG_SERIAL_AMBA_PL011=y > CONFIG_SERIAL_AMBA_PL011_CONSOLE=y > CONFIG_SERIAL_SAMSUNG=y > @@ -122,11 +127,13 @@ > CONFIG_SERIAL_ST_ASC=y > CONFIG_SERIAL_ST_ASC_CONSOLE=y > CONFIG_I2C_CHARDEV=y > +CONFIG_I2C_MUX=y > CONFIG_I2C_MUX_PCA954x=y > CONFIG_I2C_MUX_PINCTRL=y > CONFIG_I2C_DESIGNWARE_PLATFORM=y > CONFIG_I2C_NOMADIK=y > CONFIG_I2C_XILINX=y > +CONFIG_SPI=y > CONFIG_SPI_CADENCE=y > CONFIG_SPI_PL022=y > CONFIG_SPI_XILINX=y > @@ -135,6 +142,7 @@ > CONFIG_PINCTRL_PALMAS=y > CONFIG_GPIO_SYSFS=y > CONFIG_GPIO_DWAPB=y > +CONFIG_GPIO_EM=y > CONFIG_GPIO_PL061=y > CONFIG_GPIO_PCA953X=y > CONFIG_GPIO_PCA953X_IRQ=y > @@ -173,6 +181,7 @@ > CONFIG_REGULATOR_VIRTUAL_CONSUMER=y > CONFIG_REGULATOR_AS3722=y > CONFIG_REGULATOR_BCM590XX=y > +CONFIG_REGULATOR_DA9210=y > CONFIG_REGULATOR_GPIO=y > CONFIG_REGULATOR_MAX8907=y > CONFIG_REGULATOR_PALMAS=y > @@ -187,9 +196,18 @@ > CONFIG_REGULATOR_VEXPRESS=y > CONFIG_MEDIA_SUPPORT=y > CONFIG_MEDIA_CAMERA_SUPPORT=y > +CONFIG_MEDIA_CONTROLLER=y > +CONFIG_VIDEO_V4L2_SUBDEV_API=y > CONFIG_MEDIA_USB_SUPPORT=y > CONFIG_USB_VIDEO_CLASS=y > CONFIG_USB_GSPCA=y > +CONFIG_V4L_PLATFORM_DRIVERS=y > +CONFIG_SOC_CAMERA=y > +CONFIG_SOC_CAMERA_PLATFORM=y > +CONFIG_V4L_MEM2MEM_DRIVERS=y > +CONFIG_VIDEO_RENESAS_VSP1=y > > This seems to be another option for Renesas specific hardware and it has > a footprint of 23kB. > > [ I think that this option should depend on ARCH_SHMOBILE. ] > > +# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set > +CONFIG_VIDEO_ADV7180=y > CONFIG_DRM=y > CONFIG_FB=y > CONFIG_FB_ARMCLCD=y > @@ -204,6 +222,7 @@ > CONFIG_SND_SOC=y > CONFIG_SND_SOC_WM8753=y > CONFIG_SND_SOC_WM8903=y > +CONFIG_SND_SIMPLE_CARD=y > CONFIG_USB=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_EHCI_HCD=y > @@ -211,6 +230,7 @@ > CONFIG_USB_ISP1760_HCD=y > CONFIG_USB_OHCI_HCD=y > CONFIG_USB_OHCI_HCD_PLATFORM=y > +CONFIG_USB_RENESAS_USBHS=y > > It seems to be yet another option for Renesas specific hardware and it > has a footprint of 18kB. > > [ I think that this option should depend on ARCH_SHMOBILE || ARCH_SH. ] > > CONFIG_USB_STORAGE=y > CONFIG_USB_CHIPIDEA=y > CONFIG_USB_CHIPIDEA_HOST=y > @@ -220,6 +240,8 @@ > CONFIG_USB_GPIO_VBUS=y > CONFIG_USB_ISP1301=y > CONFIG_USB_ULPI=y > +CONFIG_USB_GADGET=y > +CONFIG_USB_RENESAS_USBHS_UDC=y > > This one depends on CONFIG_USB_RENESAS_USBHS and costs us 3kB. > > CONFIG_MMC=y > CONFIG_MMC_BLOCK_MINORS=16 > CONFIG_MMC_ARMMMCI=y > > In total by fixing the above three options to have correct dependencies > it is possible to recover 86kB out of 170kB of vmlinux size inrease for > a single platform only config derived from a multiplatform one. > > Simon/Magnus, is it okay to send patches fixing > > CONFIG_SH_ETH > CONFIG_VIDEO_RENESAS_VSP1 > CONFIG_USB_RENESAS_USBHS > > dependencies? Hi Bartlomiej, In general that seems reasonable to me. But I would tweak the dependency slightly to: ARCH_SHMOBILE || ARCH_SH || COMPILE_TEST And in the case of CONFIG_VIDEO_RENESAS_VSP1 and CONFIG_USB_RENESAS_USBHS I think ARCH_SH could be omitted. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 30 August 2014 11:32:30 Geert Uytterhoeven wrote: > Hi Arnd, > > On Fri, Aug 29, 2014 at 10:11 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > A related problem that I think is more significant is that > > some platforms 'select' a particular driver and when you > > disable the platform, that driver is suddenly removed from the > > defconfig for all other platforms as well. This has bitten > > us a few times in the past, and I'd really like to fix those > > cases first. > > Indeed. "select" is evil, and has a devastating effect on minimal > defconfigs (lots of churn and nasty surprises like the one you mentioned). > > So it actually makes more sense to derive multi_v7_defconfig > from the individual platform's defconfigs. > I also have a script for that, which I wrote to create m68k's multi_defconfig > a long time ago: > https://github.com/geertu/linux-scripts/blob/master/linux-config-merge This looks like a very interesting method, and is similar to the "Kconfig fragments" that a lot of people are using. However I'm not sure we can replace the multi_v7_defconfig with it, the main problem I see with that is that it can get unpredictable when changes are done to one of the inputs. I'd rather keep the multi_v7_defconfig in some form (possibly extend it to v6) and use fragments for some specialized variation (v6-smp, v7, v7-lpae, ...). > In the long run, I think creating defconfigs from DTS is the way to go. > Extracting dependencies from the build system (both Makefile and > the myriad of complex dependencies in Kconfig) are the biggest hurdles to > solve. Yes, this looks like very interesting work. We won't be able to use it for all cases, in particular for distro kernels that are meant to run on a large number of machines that don't all have dts files in the kernel, but it should simplify the workflow for a lot of embedded use cases. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 30 August 2014 18:10:59 Kukjin Kim wrote: > Arnd Bergmann wrote: > > On Friday 29 August 2014 20:05:49 Bartlomiej Zolnierkiewicz wrote: > > > I've been looking lately into making it possible to easily go > > > from multi_v7_defconfig config to a single platform one (in my > > > case Exynos one) and removing the need to keep the latter (i.e. > > > exynos_defconfig) in the kernel tree in the long-term. > > > > Why? I don't have any idea why we should use only multi_v7_defconfig for each > hardware platform. In my understanding, multi_v7_defconfig can be used for one > kernel image can support all of the platforms but it doesn't mean it should be > used for each platform. And I think, if we cannot maintain each platform's > defconfig in mainline, it will be kept in each SoC vendor and it is not a good > way. I mean both defconfigs has each value in mainline, exynos_defconfig should > be updated though ;) It's not clear how we are going to do this in the long run. We definitely have far more defconfig files in the kernel than we want to have, it's a burden for testers. In theory, running multi_v7_defconfig should have no downsides other than the obvious space overhead of the unused platform code and there should be no difference between disabling unused file systems and PCI drivers to disabling unused platforms. Another argument is that even an exynos_defconfig contains much more code than you really want, and for an embedded system you would turn off all the drivers that a particular exynos machine does not have. So there is no fundamental difference between turning off part of exynos_defconfig and turning off parts of multi_v7_defconfig, the difference is mainly how many options you'd turn off. Then again, I also don't see a reason to remove exynos_defconfig any time soon. So far the rule is that each platform can have its own defconfig because that's the way it has been done for a long time. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Saturday, August 30, 2014 06:10:59 PM Kukjin Kim wrote: > Arnd Bergmann wrote: > > > Hi, > > > On Friday 29 August 2014 20:05:49 Bartlomiej Zolnierkiewicz wrote: > > > I've been looking lately into making it possible to easily go > > > from multi_v7_defconfig config to a single platform one (in my > > > case Exynos one) and removing the need to keep the latter (i.e. > > > exynos_defconfig) in the kernel tree in the long-term. > > > > Why? I don't have any idea why we should use only multi_v7_defconfig for each > hardware platform. In my understanding, multi_v7_defconfig can be used for one > kernel image can support all of the platforms but it doesn't mean it should be In my long-term "plan" both configs should be available but one should be generated from the other. Either way should be okay for me: multi -> single platform or single platforms(s) -> multi. [ Please note that if you take multi_v7_defconfig and disable support for all archs besides Exynos (trivial operation even when done by hand) you end up with platform specific kernel config. ] Pros: - less code in kernel - concentrated testing efforts - configs don't go out-of-sync with each other - less maintainance burden Cons: - fewer config options may be covered than with two independent configs > used for each platform. And I think, if we cannot maintain each platform's > defconfig in mainline, it will be kept in each SoC vendor and it is not a good It seems that currently in case of our internal kernel trees the custom kernel configs are always used instead of either exynos_defconfig or multi_v7_defconfig. I think that there is a big room for improvement here. > way. I mean both defconfigs has each value in mainline, exynos_defconfig should > be updated though ;) Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Monday, September 01, 2014 10:54:26 AM Simon Horman wrote: > On Fri, Aug 29, 2014 at 08:05:49PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > > Hi, > > > > On Thursday, August 28, 2014 04:00:28 PM Geert Uytterhoeven wrote: > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > > --- > > > Based on next-20140828 > > > For now excluding r8a7740/armadillo, as it fails to boot on armadillo > > > > > > arch/arm/configs/multi_v7_defconfig | 51 +++++++++++++++++++++++++++++++++++-- > > > 1 file changed, 49 insertions(+), 2 deletions(-) > > > > I've been looking lately into making it possible to easily go > > from multi_v7_defconfig config to a single platform one (in my > > case Exynos one) and removing the need to keep the latter (i.e. > > exynos_defconfig) in the kernel tree in the long-term. > > > > Because of this I've noticed that some config options for platform > > specific hardware that are selected in multi_v7_defconfig don't > > have proper dependencies. This results in more complex than > > necessary single platform configs (obtained from a multiplatform > > config) and unnecessarily bigger resulting kernel images. > > > > Your patch also adds/uncovers some such config options. > > > > Lets first look at sizes of resulting vmlinux images for single > > platform Exynos config before and after your patch: > > > > $ size vmlinux.* > > text data bss dec hex filename > > 7817317 517188 278992 8613497 836e79 vmlinux.before > > 7978325 527012 279056 8784393 860a09 vmlinux.after > > > > (=> the patch results in 170kB bigger vmlinux size) > > > > and the configs diff later: > > > > --- multi_v7_exynos_only 2014-08-29 12:29:31.881485357 +0200 > > +++ multi_v7_exynos_only_shmobile 2014-08-29 12:36:24.361496247 +0200 > > @@ -70,6 +70,8 @@ > > CONFIG_BRCMSTB_GISB_ARB=y > > CONFIG_VEXPRESS_CONFIG=y > > CONFIG_MTD=y > > +CONFIG_MTD_M25P80=y > > +CONFIG_MTD_SPI_NOR=y > > CONFIG_BLK_DEV_LOOP=y > > CONFIG_ICS932S401=y > > CONFIG_APDS9802ALS=y > > @@ -86,11 +88,13 @@ > > CONFIG_MVMDIO=y > > CONFIG_KS8851=y > > CONFIG_R8169=y > > +CONFIG_SH_ETH=y > > > > This seems to be option for Renesas specific hardware and it has > > a footprint of 23kB. > > > > [ I think that this option should depend on ARCH_SHMOBILE || ARCH_SH. ] > > > > CONFIG_SMSC911X=y > > CONFIG_STMMAC_ETH=y > > CONFIG_AT803X_PHY=y > > CONFIG_MARVELL_PHY=y > > CONFIG_ICPLUS_PHY=y > > +CONFIG_MICREL_PHY=y > > > > This gets selected by CONFIG_SH_ETH and costs us 4kB. > > > > CONFIG_USB_PEGASUS=y > > CONFIG_USB_USBNET=y > > CONFIG_USB_NET_SMSC75XX=y > > @@ -110,6 +114,7 @@ > > CONFIG_SERIAL_8250=y > > CONFIG_SERIAL_8250_CONSOLE=y > > CONFIG_SERIAL_8250_DW=y > > +CONFIG_SERIAL_8250_EM=y > > CONFIG_SERIAL_AMBA_PL011=y > > CONFIG_SERIAL_AMBA_PL011_CONSOLE=y > > CONFIG_SERIAL_SAMSUNG=y > > @@ -122,11 +127,13 @@ > > CONFIG_SERIAL_ST_ASC=y > > CONFIG_SERIAL_ST_ASC_CONSOLE=y > > CONFIG_I2C_CHARDEV=y > > +CONFIG_I2C_MUX=y > > CONFIG_I2C_MUX_PCA954x=y > > CONFIG_I2C_MUX_PINCTRL=y > > CONFIG_I2C_DESIGNWARE_PLATFORM=y > > CONFIG_I2C_NOMADIK=y > > CONFIG_I2C_XILINX=y > > +CONFIG_SPI=y > > CONFIG_SPI_CADENCE=y > > CONFIG_SPI_PL022=y > > CONFIG_SPI_XILINX=y > > @@ -135,6 +142,7 @@ > > CONFIG_PINCTRL_PALMAS=y > > CONFIG_GPIO_SYSFS=y > > CONFIG_GPIO_DWAPB=y > > +CONFIG_GPIO_EM=y > > CONFIG_GPIO_PL061=y > > CONFIG_GPIO_PCA953X=y > > CONFIG_GPIO_PCA953X_IRQ=y > > @@ -173,6 +181,7 @@ > > CONFIG_REGULATOR_VIRTUAL_CONSUMER=y > > CONFIG_REGULATOR_AS3722=y > > CONFIG_REGULATOR_BCM590XX=y > > +CONFIG_REGULATOR_DA9210=y > > CONFIG_REGULATOR_GPIO=y > > CONFIG_REGULATOR_MAX8907=y > > CONFIG_REGULATOR_PALMAS=y > > @@ -187,9 +196,18 @@ > > CONFIG_REGULATOR_VEXPRESS=y > > CONFIG_MEDIA_SUPPORT=y > > CONFIG_MEDIA_CAMERA_SUPPORT=y > > +CONFIG_MEDIA_CONTROLLER=y > > +CONFIG_VIDEO_V4L2_SUBDEV_API=y > > CONFIG_MEDIA_USB_SUPPORT=y > > CONFIG_USB_VIDEO_CLASS=y > > CONFIG_USB_GSPCA=y > > +CONFIG_V4L_PLATFORM_DRIVERS=y > > +CONFIG_SOC_CAMERA=y > > +CONFIG_SOC_CAMERA_PLATFORM=y > > +CONFIG_V4L_MEM2MEM_DRIVERS=y > > +CONFIG_VIDEO_RENESAS_VSP1=y > > > > This seems to be another option for Renesas specific hardware and it has > > a footprint of 23kB. > > > > [ I think that this option should depend on ARCH_SHMOBILE. ] > > > > +# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set > > +CONFIG_VIDEO_ADV7180=y > > CONFIG_DRM=y > > CONFIG_FB=y > > CONFIG_FB_ARMCLCD=y > > @@ -204,6 +222,7 @@ > > CONFIG_SND_SOC=y > > CONFIG_SND_SOC_WM8753=y > > CONFIG_SND_SOC_WM8903=y > > +CONFIG_SND_SIMPLE_CARD=y > > CONFIG_USB=y > > CONFIG_USB_XHCI_HCD=y > > CONFIG_USB_EHCI_HCD=y > > @@ -211,6 +230,7 @@ > > CONFIG_USB_ISP1760_HCD=y > > CONFIG_USB_OHCI_HCD=y > > CONFIG_USB_OHCI_HCD_PLATFORM=y > > +CONFIG_USB_RENESAS_USBHS=y > > > > It seems to be yet another option for Renesas specific hardware and it > > has a footprint of 18kB. > > > > [ I think that this option should depend on ARCH_SHMOBILE || ARCH_SH. ] > > > > CONFIG_USB_STORAGE=y > > CONFIG_USB_CHIPIDEA=y > > CONFIG_USB_CHIPIDEA_HOST=y > > @@ -220,6 +240,8 @@ > > CONFIG_USB_GPIO_VBUS=y > > CONFIG_USB_ISP1301=y > > CONFIG_USB_ULPI=y > > +CONFIG_USB_GADGET=y > > +CONFIG_USB_RENESAS_USBHS_UDC=y > > > > This one depends on CONFIG_USB_RENESAS_USBHS and costs us 3kB. > > > > CONFIG_MMC=y > > CONFIG_MMC_BLOCK_MINORS=16 > > CONFIG_MMC_ARMMMCI=y > > > > In total by fixing the above three options to have correct dependencies > > it is possible to recover 86kB out of 170kB of vmlinux size inrease for > > a single platform only config derived from a multiplatform one. > > > > Simon/Magnus, is it okay to send patches fixing > > > > CONFIG_SH_ETH > > CONFIG_VIDEO_RENESAS_VSP1 > > CONFIG_USB_RENESAS_USBHS > > > > dependencies? > > Hi Bartlomiej, > > In general that seems reasonable to me. > But I would tweak the dependency slightly to: > > ARCH_SHMOBILE || ARCH_SH || COMPILE_TEST Ok. > And in the case of CONFIG_VIDEO_RENESAS_VSP1 and CONFIG_USB_RENESAS_USBHS > I think ARCH_SH could be omitted. I agree w.r.t. CONFIG_VIDEO_RENESAS_VSP1 but CONFIG_USB_RENESAS_USBHS seems to be needed by both ARCH_SHMOBILE: $ git grep renesas_usbhs_platform_info arch/arm/mach-shmobile/ arch/arm/mach-shmobile/board-armadillo800eva.c: struct renesas_usbhs_platform_info info; arch/arm/mach-shmobile/board-bockw.c:static struct renesas_usbhs_platform_info usbhs_info __initdata = { arch/arm/mach-shmobile/board-bockw.c: &usbhs_info, sizeof(struct renesas_usbhs_platform_info)) arch/arm/mach-shmobile/board-kzm9g.c: struct renesas_usbhs_platform_info info; arch/arm/mach-shmobile/board-lager.c: struct renesas_usbhs_platform_info info; arch/arm/mach-shmobile/board-mackerel.c: struct renesas_usbhs_platform_info info; and ARCH_SH: $ git grep renesas_usbhs_platform_info arch/sh/ arch/sh/boards/board-sh7757lcr.c:static struct renesas_usbhs_platform_info usb0_data = { arch/sh/boards/mach-ecovec24/setup.c:static struct renesas_usbhs_platform_info usbhs_info = { Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Mon, Sep 01, 2014 at 02:42:02PM +0200, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, September 01, 2014 10:54:26 AM Simon Horman wrote: > > On Fri, Aug 29, 2014 at 08:05:49PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > > > > Hi, > > > > > > On Thursday, August 28, 2014 04:00:28 PM Geert Uytterhoeven wrote: > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > > > --- > > > > Based on next-20140828 > > > > For now excluding r8a7740/armadillo, as it fails to boot on armadillo > > > > > > > > arch/arm/configs/multi_v7_defconfig | 51 +++++++++++++++++++++++++++++++++++-- > > > > 1 file changed, 49 insertions(+), 2 deletions(-) > > > > > > I've been looking lately into making it possible to easily go > > > from multi_v7_defconfig config to a single platform one (in my > > > case Exynos one) and removing the need to keep the latter (i.e. > > > exynos_defconfig) in the kernel tree in the long-term. > > > > > > Because of this I've noticed that some config options for platform > > > specific hardware that are selected in multi_v7_defconfig don't > > > have proper dependencies. This results in more complex than > > > necessary single platform configs (obtained from a multiplatform > > > config) and unnecessarily bigger resulting kernel images. > > > > > > Your patch also adds/uncovers some such config options. > > > > > > Lets first look at sizes of resulting vmlinux images for single > > > platform Exynos config before and after your patch: > > > > > > $ size vmlinux.* > > > text data bss dec hex filename > > > 7817317 517188 278992 8613497 836e79 vmlinux.before > > > 7978325 527012 279056 8784393 860a09 vmlinux.after > > > > > > (=> the patch results in 170kB bigger vmlinux size) > > > > > > and the configs diff later: > > > > > > --- multi_v7_exynos_only 2014-08-29 12:29:31.881485357 +0200 > > > +++ multi_v7_exynos_only_shmobile 2014-08-29 12:36:24.361496247 +0200 > > > @@ -70,6 +70,8 @@ > > > CONFIG_BRCMSTB_GISB_ARB=y > > > CONFIG_VEXPRESS_CONFIG=y > > > CONFIG_MTD=y > > > +CONFIG_MTD_M25P80=y > > > +CONFIG_MTD_SPI_NOR=y > > > CONFIG_BLK_DEV_LOOP=y > > > CONFIG_ICS932S401=y > > > CONFIG_APDS9802ALS=y > > > @@ -86,11 +88,13 @@ > > > CONFIG_MVMDIO=y > > > CONFIG_KS8851=y > > > CONFIG_R8169=y > > > +CONFIG_SH_ETH=y > > > > > > This seems to be option for Renesas specific hardware and it has > > > a footprint of 23kB. > > > > > > [ I think that this option should depend on ARCH_SHMOBILE || ARCH_SH. ] > > > > > > CONFIG_SMSC911X=y > > > CONFIG_STMMAC_ETH=y > > > CONFIG_AT803X_PHY=y > > > CONFIG_MARVELL_PHY=y > > > CONFIG_ICPLUS_PHY=y > > > +CONFIG_MICREL_PHY=y > > > > > > This gets selected by CONFIG_SH_ETH and costs us 4kB. > > > > > > CONFIG_USB_PEGASUS=y > > > CONFIG_USB_USBNET=y > > > CONFIG_USB_NET_SMSC75XX=y > > > @@ -110,6 +114,7 @@ > > > CONFIG_SERIAL_8250=y > > > CONFIG_SERIAL_8250_CONSOLE=y > > > CONFIG_SERIAL_8250_DW=y > > > +CONFIG_SERIAL_8250_EM=y > > > CONFIG_SERIAL_AMBA_PL011=y > > > CONFIG_SERIAL_AMBA_PL011_CONSOLE=y > > > CONFIG_SERIAL_SAMSUNG=y > > > @@ -122,11 +127,13 @@ > > > CONFIG_SERIAL_ST_ASC=y > > > CONFIG_SERIAL_ST_ASC_CONSOLE=y > > > CONFIG_I2C_CHARDEV=y > > > +CONFIG_I2C_MUX=y > > > CONFIG_I2C_MUX_PCA954x=y > > > CONFIG_I2C_MUX_PINCTRL=y > > > CONFIG_I2C_DESIGNWARE_PLATFORM=y > > > CONFIG_I2C_NOMADIK=y > > > CONFIG_I2C_XILINX=y > > > +CONFIG_SPI=y > > > CONFIG_SPI_CADENCE=y > > > CONFIG_SPI_PL022=y > > > CONFIG_SPI_XILINX=y > > > @@ -135,6 +142,7 @@ > > > CONFIG_PINCTRL_PALMAS=y > > > CONFIG_GPIO_SYSFS=y > > > CONFIG_GPIO_DWAPB=y > > > +CONFIG_GPIO_EM=y > > > CONFIG_GPIO_PL061=y > > > CONFIG_GPIO_PCA953X=y > > > CONFIG_GPIO_PCA953X_IRQ=y > > > @@ -173,6 +181,7 @@ > > > CONFIG_REGULATOR_VIRTUAL_CONSUMER=y > > > CONFIG_REGULATOR_AS3722=y > > > CONFIG_REGULATOR_BCM590XX=y > > > +CONFIG_REGULATOR_DA9210=y > > > CONFIG_REGULATOR_GPIO=y > > > CONFIG_REGULATOR_MAX8907=y > > > CONFIG_REGULATOR_PALMAS=y > > > @@ -187,9 +196,18 @@ > > > CONFIG_REGULATOR_VEXPRESS=y > > > CONFIG_MEDIA_SUPPORT=y > > > CONFIG_MEDIA_CAMERA_SUPPORT=y > > > +CONFIG_MEDIA_CONTROLLER=y > > > +CONFIG_VIDEO_V4L2_SUBDEV_API=y > > > CONFIG_MEDIA_USB_SUPPORT=y > > > CONFIG_USB_VIDEO_CLASS=y > > > CONFIG_USB_GSPCA=y > > > +CONFIG_V4L_PLATFORM_DRIVERS=y > > > +CONFIG_SOC_CAMERA=y > > > +CONFIG_SOC_CAMERA_PLATFORM=y > > > +CONFIG_V4L_MEM2MEM_DRIVERS=y > > > +CONFIG_VIDEO_RENESAS_VSP1=y > > > > > > This seems to be another option for Renesas specific hardware and it has > > > a footprint of 23kB. > > > > > > [ I think that this option should depend on ARCH_SHMOBILE. ] > > > > > > +# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set > > > +CONFIG_VIDEO_ADV7180=y > > > CONFIG_DRM=y > > > CONFIG_FB=y > > > CONFIG_FB_ARMCLCD=y > > > @@ -204,6 +222,7 @@ > > > CONFIG_SND_SOC=y > > > CONFIG_SND_SOC_WM8753=y > > > CONFIG_SND_SOC_WM8903=y > > > +CONFIG_SND_SIMPLE_CARD=y > > > CONFIG_USB=y > > > CONFIG_USB_XHCI_HCD=y > > > CONFIG_USB_EHCI_HCD=y > > > @@ -211,6 +230,7 @@ > > > CONFIG_USB_ISP1760_HCD=y > > > CONFIG_USB_OHCI_HCD=y > > > CONFIG_USB_OHCI_HCD_PLATFORM=y > > > +CONFIG_USB_RENESAS_USBHS=y > > > > > > It seems to be yet another option for Renesas specific hardware and it > > > has a footprint of 18kB. > > > > > > [ I think that this option should depend on ARCH_SHMOBILE || ARCH_SH. ] > > > > > > CONFIG_USB_STORAGE=y > > > CONFIG_USB_CHIPIDEA=y > > > CONFIG_USB_CHIPIDEA_HOST=y > > > @@ -220,6 +240,8 @@ > > > CONFIG_USB_GPIO_VBUS=y > > > CONFIG_USB_ISP1301=y > > > CONFIG_USB_ULPI=y > > > +CONFIG_USB_GADGET=y > > > +CONFIG_USB_RENESAS_USBHS_UDC=y > > > > > > This one depends on CONFIG_USB_RENESAS_USBHS and costs us 3kB. > > > > > > CONFIG_MMC=y > > > CONFIG_MMC_BLOCK_MINORS=16 > > > CONFIG_MMC_ARMMMCI=y > > > > > > In total by fixing the above three options to have correct dependencies > > > it is possible to recover 86kB out of 170kB of vmlinux size inrease for > > > a single platform only config derived from a multiplatform one. > > > > > > Simon/Magnus, is it okay to send patches fixing > > > > > > CONFIG_SH_ETH > > > CONFIG_VIDEO_RENESAS_VSP1 > > > CONFIG_USB_RENESAS_USBHS > > > > > > dependencies? > > > > Hi Bartlomiej, > > > > In general that seems reasonable to me. > > But I would tweak the dependency slightly to: > > > > ARCH_SHMOBILE || ARCH_SH || COMPILE_TEST > > Ok. > > > And in the case of CONFIG_VIDEO_RENESAS_VSP1 and CONFIG_USB_RENESAS_USBHS > > I think ARCH_SH could be omitted. > > I agree w.r.t. CONFIG_VIDEO_RENESAS_VSP1 but CONFIG_USB_RENESAS_USBHS > seems to be needed by both ARCH_SHMOBILE: Indeed it does. > > $ git grep renesas_usbhs_platform_info arch/arm/mach-shmobile/ > arch/arm/mach-shmobile/board-armadillo800eva.c: struct renesas_usbhs_platform_info info; > arch/arm/mach-shmobile/board-bockw.c:static struct renesas_usbhs_platform_info usbhs_info __initdata = { > arch/arm/mach-shmobile/board-bockw.c: &usbhs_info, sizeof(struct renesas_usbhs_platform_info)) > arch/arm/mach-shmobile/board-kzm9g.c: struct renesas_usbhs_platform_info info; > arch/arm/mach-shmobile/board-lager.c: struct renesas_usbhs_platform_info info; > arch/arm/mach-shmobile/board-mackerel.c: struct renesas_usbhs_platform_info info; > > and ARCH_SH: > > $ git grep renesas_usbhs_platform_info arch/sh/ > arch/sh/boards/board-sh7757lcr.c:static struct renesas_usbhs_platform_info usb0_data = { > arch/sh/boards/mach-ecovec24/setup.c:static struct renesas_usbhs_platform_info usbhs_info = { > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- multi_v7_exynos_only 2014-08-29 12:29:31.881485357 +0200 +++ multi_v7_exynos_only_shmobile 2014-08-29 12:36:24.361496247 +0200 @@ -70,6 +70,8 @@ CONFIG_BRCMSTB_GISB_ARB=y CONFIG_VEXPRESS_CONFIG=y CONFIG_MTD=y +CONFIG_MTD_M25P80=y +CONFIG_MTD_SPI_NOR=y CONFIG_BLK_DEV_LOOP=y CONFIG_ICS932S401=y CONFIG_APDS9802ALS=y @@ -86,11 +88,13 @@ CONFIG_MVMDIO=y CONFIG_KS8851=y CONFIG_R8169=y +CONFIG_SH_ETH=y This seems to be option for Renesas specific hardware and it has a footprint of 23kB. [ I think that this option should depend on ARCH_SHMOBILE || ARCH_SH. ] CONFIG_SMSC911X=y CONFIG_STMMAC_ETH=y CONFIG_AT803X_PHY=y