arm: omap: reduce zImage size on omap2plus_defconfig

Commit Message

Felipe Balbi Dec. 22, 2014, 6:05 p.m. UTC

By converting a few drivers to modules because they
won't be needed during boot anyways, we can shave off
about 700KiB of text.

Note that while at that, and after discussions with Tony
Lindgren, a few extra drivers were either removed because
they weren't needed, or added because they're useful for
debugging/testing.

Below is output of size for pre and post vmlinux binaries:

   text    data     bss     dec     hex filename
8342992  757876 8411840 17512708        10b3904 vmlinux-post-patch
9069110  800316 8419072 18288498        1170f72 vmlinux-pre-patch

Signed-off-by: Felipe Balbi <[e-mail]>
---
 arch/arm/configs/omap2plus_defconfig | 121 ++++++++++++++++++++++-------------
 1 file changed, 75 insertions(+), 46 deletions(-)

Comments

Felipe Balbi Dec. 22, 2014, 6:11 p.m. UTC | #1

On Mon, Dec 22, 2014 at 12:05:35PM -0600, Felipe Balbi wrote:
> By converting a few drivers to modules because they
> won't be needed during boot anyways, we can shave off
> about 700KiB of text.
> 
> Note that while at that, and after discussions with Tony
> Lindgren, a few extra drivers were either removed because
> they weren't needed, or added because they're useful for
> debugging/testing.
> 
> Below is output of size for pre and post vmlinux binaries:
> 
>    text    data     bss     dec     hex filename
> 8342992  757876 8411840 17512708        10b3904 vmlinux-post-patch
> 9069110  800316 8419072 18288498        1170f72 vmlinux-pre-patch
> 
> Signed-off-by: Felipe Balbi <[e-mail]>

oh yeah, still boots fine with AM437x SK, Beagle Bone Black. Also boots
with Beagle X15, but that still needs a pending CPSW patch [1] for NFS
root.

[1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/121183

> ---
>  arch/arm/configs/omap2plus_defconfig | 121 ++++++++++++++++++++++-------------
>  1 file changed, 75 insertions(+), 46 deletions(-)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> index c2c3a85..a1dc3ed 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -13,7 +13,6 @@ CONFIG_CGROUP_FREEZER=y
>  CONFIG_CGROUP_DEVICE=y
>  CONFIG_CPUSETS=y
>  CONFIG_CGROUP_CPUACCT=y
> -CONFIG_RESOURCE_COUNTERS=y
>  CONFIG_MEMCG=y
>  CONFIG_MEMCG_SWAP=y
>  CONFIG_MEMCG_KMEM=y
> @@ -68,7 +67,6 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
>  CONFIG_CPU_FREQ_GOV_POWERSAVE=y
>  CONFIG_CPU_FREQ_GOV_USERSPACE=y
>  CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> -CONFIG_GENERIC_CPUFREQ_CPU0=y
>  # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
>  CONFIG_CPU_IDLE=y
>  CONFIG_BINFMT_MISC=y
> @@ -103,7 +101,7 @@ CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_DMA_CMA=y
>  CONFIG_OMAP_OCP2SCP=y
> -CONFIG_CONNECTOR=y
> +CONFIG_CONNECTOR=m
>  CONFIG_MTD=y
>  CONFIG_MTD_CMDLINE_PARTS=y
>  CONFIG_MTD_BLOCK=y
> @@ -122,14 +120,13 @@ CONFIG_BLK_DEV_RAM=y
>  CONFIG_BLK_DEV_RAM_SIZE=16384
>  CONFIG_SENSORS_TSL2550=m
>  CONFIG_BMP085_I2C=m
> -CONFIG_SENSORS_LIS3_I2C=m
>  CONFIG_SRAM=y
> +CONFIG_SENSORS_LIS3_I2C=m
>  CONFIG_SCSI=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_SCSI_SCAN_ASYNC=y
> -CONFIG_ATA=y
> -CONFIG_SATA_AHCI_PLATFORM=y
> -CONFIG_MD=y
> +CONFIG_ATA=m
> +CONFIG_SATA_AHCI_PLATFORM=m
>  CONFIG_NETDEVICES=y
>  # CONFIG_NET_VENDOR_ARC is not set
>  # CONFIG_NET_CADENCE is not set
> @@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y
>  # CONFIG_NET_VENDOR_WIZNET is not set
>  CONFIG_AT803X_PHY=y
>  CONFIG_SMSC_PHY=y
> -CONFIG_USB_USBNET=y
> -CONFIG_USB_NET_SMSC95XX=y
> +CONFIG_USB_USBNET=m
> +CONFIG_USB_NET_SMSC95XX=m
>  CONFIG_USB_ALI_M5632=y
>  CONFIG_USB_AN2720=y
>  CONFIG_USB_EPSON2888=y
> @@ -172,18 +169,22 @@ CONFIG_WLCORE_SDIO=m
>  CONFIG_MWIFIEX=m
>  CONFIG_MWIFIEX_SDIO=m
>  CONFIG_MWIFIEX_USB=m
> -CONFIG_INPUT_JOYDEV=y
> -CONFIG_INPUT_EVDEV=y
> -CONFIG_KEYBOARD_GPIO=y
> +CONFIG_INPUT_JOYDEV=m
> +CONFIG_INPUT_EVDEV=m
> +CONFIG_KEYBOARD_ATKBD=m
> +CONFIG_KEYBOARD_GPIO=m
>  CONFIG_KEYBOARD_MATRIX=m
> -CONFIG_KEYBOARD_TWL4030=y
> +CONFIG_KEYBOARD_OMAP4=m
> +CONFIG_KEYBOARD_TWL4030=m
> +# CONFIG_INPUT_MOUSE is not set
>  CONFIG_INPUT_TOUCHSCREEN=y
>  CONFIG_TOUCHSCREEN_ADS7846=m
>  CONFIG_TOUCHSCREEN_EDT_FT5X06=m
>  CONFIG_TOUCHSCREEN_TSC2005=m
>  CONFIG_TOUCHSCREEN_TSC2007=m
>  CONFIG_INPUT_MISC=y
> -CONFIG_INPUT_TWL4030_PWRBUTTON=y
> +CONFIG_INPUT_TWL4030_PWRBUTTON=m
> +CONFIG_SERIO=m
>  # CONFIG_LEGACY_PTYS is not set
>  CONFIG_SERIAL_8250=y
>  CONFIG_SERIAL_8250_CONSOLE=y
> @@ -196,15 +197,16 @@ CONFIG_SERIAL_8250_RSA=y
>  CONFIG_SERIAL_OF_PLATFORM=y
>  CONFIG_SERIAL_OMAP=y
>  CONFIG_SERIAL_OMAP_CONSOLE=y
> -CONFIG_HW_RANDOM=y
>  CONFIG_I2C_CHARDEV=y
>  CONFIG_SPI=y
>  CONFIG_SPI_OMAP24XX=y
> +CONFIG_SPI_TI_QSPI=m
>  CONFIG_PINCTRL_SINGLE=y
>  CONFIG_DEBUG_GPIO=y
>  CONFIG_GPIO_SYSFS=y
> -CONFIG_GPIO_TWL4030=y
> -CONFIG_W1=y
> +CONFIG_GPIO_TWL4030=m
> +CONFIG_W1=m
> +CONFIG_HDQ_MASTER_OMAP=m
>  CONFIG_BATTERY_BQ27x00=m
>  CONFIG_CHARGER_ISP1704=m
>  CONFIG_CHARGER_TWL4030=m
> @@ -213,20 +215,21 @@ CONFIG_CHARGER_BQ24190=m
>  CONFIG_CHARGER_BQ24735=m
>  CONFIG_POWER_RESET=y
>  CONFIG_POWER_AVS=y
> +CONFIG_HWMON=m
>  CONFIG_SENSORS_LM75=m
> -CONFIG_THERMAL=y
> +CONFIG_SENSORS_TMP102=m
> +CONFIG_THERMAL=m
>  CONFIG_THERMAL_GOV_FAIR_SHARE=y
>  CONFIG_THERMAL_GOV_USER_SPACE=y
>  CONFIG_CPU_THERMAL=y
> -CONFIG_TI_SOC_THERMAL=y
> +CONFIG_TI_SOC_THERMAL=m
>  CONFIG_TI_THERMAL=y
>  CONFIG_OMAP4_THERMAL=y
>  CONFIG_OMAP5_THERMAL=y
>  CONFIG_DRA752_THERMAL=y
>  CONFIG_WATCHDOG=y
> -CONFIG_OMAP_WATCHDOG=y
> -CONFIG_TWL4030_WATCHDOG=y
> -CONFIG_MFD_SYSCON=y
> +CONFIG_OMAP_WATCHDOG=m
> +CONFIG_TWL4030_WATCHDOG=m
>  CONFIG_MFD_PALMAS=y
>  CONFIG_MFD_TPS65217=y
>  CONFIG_MFD_TPS65218=y
> @@ -289,51 +292,77 @@ CONFIG_SND_OMAP_SOC=m
>  CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
>  CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
>  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
> -CONFIG_USB=y
> +CONFIG_HID_GENERIC=m
> +CONFIG_USB_HIDDEV=y
> +CONFIG_USB_KBD=m
> +CONFIG_USB_MOUSE=m
> +CONFIG_USB=m
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> -CONFIG_USB_MON=y
> +CONFIG_USB_MON=m
>  CONFIG_USB_XHCI_HCD=m
> -CONFIG_USB_WDM=y
> -CONFIG_USB_STORAGE=y
> +CONFIG_USB_WDM=m
> +CONFIG_USB_STORAGE=m
> +CONFIG_USB_MUSB_HDRC=m
> +CONFIG_USB_MUSB_OMAP2PLUS=m
> +CONFIG_USB_MUSB_AM35X=m
> +CONFIG_USB_MUSB_DSPS=m
>  CONFIG_USB_DWC3=m
> -CONFIG_USB_TEST=y
> +CONFIG_USB_TEST=m
>  CONFIG_AM335X_PHY_USB=y
> -CONFIG_USB_GADGET=y
> +CONFIG_USB_GADGET=m
>  CONFIG_USB_GADGET_DEBUG=y
>  CONFIG_USB_GADGET_DEBUG_FILES=y
>  CONFIG_USB_GADGET_DEBUG_FS=y
> +CONFIG_USB_CONFIGFS=m
> +CONFIG_USB_CONFIGFS_SERIAL=y
> +CONFIG_USB_CONFIGFS_ACM=y
> +CONFIG_USB_CONFIGFS_OBEX=y
> +CONFIG_USB_CONFIGFS_NCM=y
> +CONFIG_USB_CONFIGFS_ECM=y
> +CONFIG_USB_CONFIGFS_ECM_SUBSET=y
> +CONFIG_USB_CONFIGFS_RNDIS=y
> +CONFIG_USB_CONFIGFS_EEM=y
> +CONFIG_USB_CONFIGFS_MASS_STORAGE=y
> +CONFIG_USB_CONFIGFS_F_LB_SS=y
> +CONFIG_USB_CONFIGFS_F_FS=y
> +CONFIG_USB_CONFIGFS_F_UAC1=y
> +CONFIG_USB_CONFIGFS_F_UAC2=y
> +CONFIG_USB_CONFIGFS_F_MIDI=y
> +CONFIG_USB_CONFIGFS_F_HID=y
>  CONFIG_USB_ZERO=m
>  CONFIG_MMC=y
>  CONFIG_SDIO_UART=y
>  CONFIG_MMC_OMAP=y
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_NEW_LEDS=y
> -CONFIG_LEDS_CLASS=y
> -CONFIG_LEDS_GPIO=y
> +CONFIG_LEDS_CLASS=m
> +CONFIG_LEDS_GPIO=m
>  CONFIG_LEDS_TRIGGERS=y
> -CONFIG_LEDS_TRIGGER_TIMER=y
> -CONFIG_LEDS_TRIGGER_ONESHOT=y
> -CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> -CONFIG_LEDS_TRIGGER_BACKLIGHT=y
> +CONFIG_LEDS_TRIGGER_TIMER=m
> +CONFIG_LEDS_TRIGGER_ONESHOT=m
> +CONFIG_LEDS_TRIGGER_HEARTBEAT=m
> +CONFIG_LEDS_TRIGGER_BACKLIGHT=m
>  CONFIG_LEDS_TRIGGER_CPU=y
> -CONFIG_LEDS_TRIGGER_GPIO=y
> -CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
> +CONFIG_LEDS_TRIGGER_GPIO=m
> +CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
>  CONFIG_RTC_CLASS=y
>  CONFIG_RTC_DRV_TWL92330=y
> -CONFIG_RTC_DRV_TWL4030=y
> -CONFIG_RTC_DRV_OMAP=y
> +CONFIG_RTC_DRV_TWL4030=m
> +CONFIG_RTC_DRV_OMAP=m
>  CONFIG_DMADEVICES=y
>  CONFIG_TI_EDMA=y
>  CONFIG_DMA_OMAP=y
> -CONFIG_EXTCON=y
> -CONFIG_EXTCON_PALMAS=y
> +# CONFIG_IOMMU_SUPPORT is not set
> +CONFIG_EXTCON=m
> +CONFIG_EXTCON_PALMAS=m
> +CONFIG_TI_EMIF=m
>  CONFIG_PWM=y
> -CONFIG_PWM_TIECAP=y
> -CONFIG_PWM_TIEHRPWM=y
> -CONFIG_PWM_TWL=y
> -CONFIG_PWM_TWL_LED=y
> -CONFIG_OMAP_USB2=y
> -CONFIG_TI_PIPE3=y
> +CONFIG_PWM_TIECAP=m
> +CONFIG_PWM_TIEHRPWM=m
> +CONFIG_PWM_TWL=m
> +CONFIG_PWM_TWL_LED=m
> +CONFIG_OMAP_USB2=m
> +CONFIG_TI_PIPE3=m
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT3_FS=y
>  # CONFIG_EXT3_FS_XATTR is not set
> -- 
> 2.2.0
>

Igor Grinberg Dec. 23, 2014, 7:30 a.m. UTC | #2

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

>  CONFIG_SCSI_SCAN_ASYNC=y
> -CONFIG_ATA=y
> -CONFIG_SATA_AHCI_PLATFORM=y
> -CONFIG_MD=y
> +CONFIG_ATA=m
> +CONFIG_SATA_AHCI_PLATFORM=m

Isn't this needed for the rootfs on SATA devices?

>  CONFIG_NETDEVICES=y
>  # CONFIG_NET_VENDOR_ARC is not set
>  # CONFIG_NET_CADENCE is not set
> @@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y
>  # CONFIG_NET_VENDOR_WIZNET is not set
>  CONFIG_AT803X_PHY=y
>  CONFIG_SMSC_PHY=y
> -CONFIG_USB_USBNET=y
> -CONFIG_USB_NET_SMSC95XX=y
> +CONFIG_USB_USBNET=m
> +CONFIG_USB_NET_SMSC95XX=m

What about the NFS root for boards with only USB eth?

[...]

>  CONFIG_DEBUG_GPIO=y
>  CONFIG_GPIO_SYSFS=y
> -CONFIG_GPIO_TWL4030=y
> -CONFIG_W1=y
> +CONFIG_GPIO_TWL4030=m

w/o this devices wired to twl gpios will not come up and likely
will miss the enumeration...

> -CONFIG_USB=y
> +CONFIG_HID_GENERIC=m
> +CONFIG_USB_HIDDEV=y
> +CONFIG_USB_KBD=m
> +CONFIG_USB_MOUSE=m
> +CONFIG_USB=m

So, you don't consider USB a valid rootfs storage option?

>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> -CONFIG_USB_MON=y
> +CONFIG_USB_MON=m
>  CONFIG_USB_XHCI_HCD=m
> -CONFIG_USB_WDM=y
> -CONFIG_USB_STORAGE=y
> +CONFIG_USB_WDM=m
> +CONFIG_USB_STORAGE=m
> +CONFIG_USB_MUSB_HDRC=m
> +CONFIG_USB_MUSB_OMAP2PLUS=m
> +CONFIG_USB_MUSB_AM35X=m
> +CONFIG_USB_MUSB_DSPS=m

[...]

Felipe Balbi Dec. 23, 2014, 4:19 p.m. UTC | #3

On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
> Hi Felipe,
> 
> On 12/22/14 20:05, Felipe Balbi wrote:
> 
> [...]
> 
> >  CONFIG_SCSI_SCAN_ASYNC=y
> > -CONFIG_ATA=y
> > -CONFIG_SATA_AHCI_PLATFORM=y
> > -CONFIG_MD=y
> > +CONFIG_ATA=m
> > +CONFIG_SATA_AHCI_PLATFORM=m
> 
> Isn't this needed for the rootfs on SATA devices?

there's no known boards with rootfs on SATA. Until then, we can reduce
the size.

> >  CONFIG_NETDEVICES=y
> >  # CONFIG_NET_VENDOR_ARC is not set
> >  # CONFIG_NET_CADENCE is not set
> > @@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y
> >  # CONFIG_NET_VENDOR_WIZNET is not set
> >  CONFIG_AT803X_PHY=y
> >  CONFIG_SMSC_PHY=y
> > -CONFIG_USB_USBNET=y
> > -CONFIG_USB_NET_SMSC95XX=y
> > +CONFIG_USB_USBNET=m
> > +CONFIG_USB_NET_SMSC95XX=m
> 
> What about the NFS root for boards with only USB eth?

USB is a module already and it breaks PM when enabled.

> >  CONFIG_DEBUG_GPIO=y
> >  CONFIG_GPIO_SYSFS=y
> > -CONFIG_GPIO_TWL4030=y
> > -CONFIG_W1=y
> > +CONFIG_GPIO_TWL4030=m
> 
> w/o this devices wired to twl gpios will not come up and likely
> will miss the enumeration...

for example ?

> > -CONFIG_USB=y
> > +CONFIG_HID_GENERIC=m
> > +CONFIG_USB_HIDDEV=y
> > +CONFIG_USB_KBD=m
> > +CONFIG_USB_MOUSE=m
> > +CONFIG_USB=m
> 
> So, you don't consider USB a valid rootfs storage option?

read the original defconfig. This is *only* for usbcore.ko, EHCI is
disabled, XHCI is a module, MUSB is disabled. What will you use for
rootfs ?

Tony Lindgren Dec. 23, 2014, 4:56 p.m. UTC | #4

* Felipe Balbi <[e-mail]> [141223 08:22]:
> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
> > On 12/22/14 20:05, Felipe Balbi wrote:
> > >  CONFIG_DEBUG_GPIO=y
> > >  CONFIG_GPIO_SYSFS=y
> > > -CONFIG_GPIO_TWL4030=y
> > > -CONFIG_W1=y
> > > +CONFIG_GPIO_TWL4030=m
> > 
> > w/o this devices wired to twl gpios will not come up and likely
> > will miss the enumeration...
> 
> for example ?

The TWL4030 part needs to be checked for the legacy booting to
make sure the board-*.c file *_twl_gpio_setup() callbacks still
work properly. Or you may want to leave it for later.

Regards,

Tony

Igor Grinberg Dec. 24, 2014, 11:53 a.m. UTC | #5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/23/14 18:19, Felipe Balbi wrote:
> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
>> Hi Felipe,
>>
>> On 12/22/14 20:05, Felipe Balbi wrote:
>>
>> [...]
>>
>>>  CONFIG_SCSI_SCAN_ASYNC=y
>>> -CONFIG_ATA=y
>>> -CONFIG_SATA_AHCI_PLATFORM=y
>>> -CONFIG_MD=y
>>> +CONFIG_ATA=m
>>> +CONFIG_SATA_AHCI_PLATFORM=m
>>
>> Isn't this needed for the rootfs on SATA devices?
> 
> there's no known boards with rootfs on SATA. Until then, we can reduce
> the size.

What makes you say so?
The decision for rootfs on SATA is taken dynamically.
OMAP5 boards (specifically cm-t54) can have rootfs on SATA...

> 
>>>  CONFIG_NETDEVICES=y
>>>  # CONFIG_NET_VENDOR_ARC is not set
>>>  # CONFIG_NET_CADENCE is not set
>>> @@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y
>>>  # CONFIG_NET_VENDOR_WIZNET is not set
>>>  CONFIG_AT803X_PHY=y
>>>  CONFIG_SMSC_PHY=y
>>> -CONFIG_USB_USBNET=y
>>> -CONFIG_USB_NET_SMSC95XX=y
>>> +CONFIG_USB_USBNET=m
>>> +CONFIG_USB_NET_SMSC95XX=m
>>
>> What about the NFS root for boards with only USB eth?
> 
> USB is a module already and it breaks PM when enabled.

Well, USB is not a module currently, but after reading below
I understand you mean HCDs are either disabled or modules.
Ok that's fine with me.

[...]

>>> -CONFIG_USB=y
>>> +CONFIG_HID_GENERIC=m
>>> +CONFIG_USB_HIDDEV=y
>>> +CONFIG_USB_KBD=m
>>> +CONFIG_USB_MOUSE=m
>>> +CONFIG_USB=m
>>
>> So, you don't consider USB a valid rootfs storage option?
> 
> read the original defconfig. This is *only* for usbcore.ko, EHCI is
> disabled, XHCI is a module, MUSB is disabled. What will you use for
> rootfs ?

Yes, thanks for pointing. Now I see indeed this is a sensible thing
to do and probably should have been done a while ago.

Might be worth addressing/explaining this in the commit message.

- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUmqlKAAoJEBDE8YO64EfaifUQAIdwJFKPozpzVeKJjIYKQgzy
4axv2/Z2TBybF6dlxykrjWwUIX8e24bAtG8uyhnQ/l6NPWVqNqwM/DHALyPBgjMV
EXciALKHyx6DiHoeoTEhhCCocekI/fM9o0mqQHpqzp2M+/UAnHq2Px0pK6Cfk84y
RoyrunlOKOe1rZSbcgZKoZDuMV0qYK2ULpMl3c7QL5sPIGrkWIGe2eTil3/m6jvu
qDaVzGxsBmmCFVxMKv/cXysBd88cswg8sd2ptX7skgptB7lpSKRiAT69c3MXaJyM
zsbE4AE9fiYb0/aZO3hmmWlNp6OM1hxY/8IjL92Sydys/bXxDHQj1fePr9ofsFYM
vSohR6IOopv1xwr6PIKyL+brWJ0p07qKNWA5vrG21D/U0B6H/IPcSbneQtHnMkJl
jf6GccX5gG49MSTDWryFOtErsNXRf6Q5zaZGYTpEsDMXhCKTYJgBhoFX5i3fW4wH
kV/doXku38SAmwRBU0oLjNs07y1I0ijgBHLTtx3XZSd7fkM3CAWsToDapz7df+bx
FAi0+DZk3DVNhJoAeyaRauZQlLU//3McM2zFX8/11K9BP76n6OTanYnjVoJq0SNo
JIjEjmFMFtIF7Zke4JpUCkYlpcW17gQLfUCrcIW1WUq6i0TAGyILmDvZPgMp6+yk
bqMgzSs8ZRXyjqm6Uj7O
=UcBr
-----END PGP SIGNATURE-----

Felipe Balbi Dec. 24, 2014, 3:49 p.m. UTC | #6

Hi,

On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 12/23/14 18:19, Felipe Balbi wrote:
> > On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
> >> Hi Felipe,
> >>
> >> On 12/22/14 20:05, Felipe Balbi wrote:
> >>
> >> [...]
> >>
> >>>  CONFIG_SCSI_SCAN_ASYNC=y
> >>> -CONFIG_ATA=y
> >>> -CONFIG_SATA_AHCI_PLATFORM=y
> >>> -CONFIG_MD=y
> >>> +CONFIG_ATA=m
> >>> +CONFIG_SATA_AHCI_PLATFORM=m
> >>
> >> Isn't this needed for the rootfs on SATA devices?
> > 
> > there's no known boards with rootfs on SATA. Until then, we can reduce
> > the size.
> 
> What makes you say so?
> The decision for rootfs on SATA is taken dynamically.
> OMAP5 boards (specifically cm-t54) can have rootfs on SATA...

I'll leave the decision to Tony. Even though they _can_, they really
don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
annoying to find that special device which works (e.g it can't negotiate
lower speeds with SATA III devices and it won't support SATA I).

As of today, we don't know of anybody really shipping anything with
rootfs on SATA and distros would rather ship initiramfs than a giant
zImage anyway.

Tony, your call.

> >>> -CONFIG_USB=y
> >>> +CONFIG_HID_GENERIC=m
> >>> +CONFIG_USB_HIDDEV=y
> >>> +CONFIG_USB_KBD=m
> >>> +CONFIG_USB_MOUSE=m
> >>> +CONFIG_USB=m
> >>
> >> So, you don't consider USB a valid rootfs storage option?
> > 
> > read the original defconfig. This is *only* for usbcore.ko, EHCI is
> > disabled, XHCI is a module, MUSB is disabled. What will you use for
> > rootfs ?
> 
> Yes, thanks for pointing. Now I see indeed this is a sensible thing
> to do and probably should have been done a while ago.
> 
> Might be worth addressing/explaining this in the commit message.

right, I'll look at it after holiday season.

Tony Lindgren Dec. 24, 2014, 7:04 p.m. UTC | #7

* Felipe Balbi <[e-mail]> [141224 07:52]:
> Hi,
> 
> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 12/23/14 18:19, Felipe Balbi wrote:
> > > On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
> > >> Hi Felipe,
> > >>
> > >> On 12/22/14 20:05, Felipe Balbi wrote:
> > >>
> > >> [...]
> > >>
> > >>>  CONFIG_SCSI_SCAN_ASYNC=y
> > >>> -CONFIG_ATA=y
> > >>> -CONFIG_SATA_AHCI_PLATFORM=y
> > >>> -CONFIG_MD=y
> > >>> +CONFIG_ATA=m
> > >>> +CONFIG_SATA_AHCI_PLATFORM=m
> > >>
> > >> Isn't this needed for the rootfs on SATA devices?
> > > 
> > > there's no known boards with rootfs on SATA. Until then, we can reduce
> > > the size.
> > 
> > What makes you say so?
> > The decision for rootfs on SATA is taken dynamically.
> > OMAP5 boards (specifically cm-t54) can have rootfs on SATA...
> 
> I'll leave the decision to Tony. Even though they _can_, they really
> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
> annoying to find that special device which works (e.g it can't negotiate
> lower speeds with SATA III devices and it won't support SATA I).
> 
> As of today, we don't know of anybody really shipping anything with
> rootfs on SATA and distros would rather ship initiramfs than a giant
> zImage anyway.
> 
> Tony, your call.

I think we should move omap2plus_defconfig to be mostly modular and
usable for distros as a base. Most distros prefer to build almost
everything as loadable modules. And my preference is that we should
only keep the minimum rootfs for devices and serial support as
built-in and rely on initramfs for most drivers. And slowly move
also the remaining built-in drivers to be loadable modules.

The reasons for having drivers as loadable modules are many. It
allows distros to use the same kernel for all the devices without
bloating the kernel. It makes developing drivers easier as just the
module needs to be reloaded. And loadable modules protect us from
cross-framework spaghetti calls in the kernel as the interfaces are 
clearly defined.

Are there people really using SATA as rootfs right now on omaps?

If it's only something that will be more widely used in the future,
then I suggest we make it into a loadable module, and presume
initramfs and loadable module also for any new devices. The same
way x86 has been doing with distros for years.

Regards,

Tony

Igor Grinberg Dec. 25, 2014, 10:13 a.m. UTC | #8

Hi Tony,

On 12/24/14 21:04, Tony Lindgren wrote:
> * Felipe Balbi <[e-mail]> [141224 07:52]:
>> Hi,
>>
>> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 12/23/14 18:19, Felipe Balbi wrote:
>>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
>>>>> Hi Felipe,
>>>>>
>>>>> On 12/22/14 20:05, Felipe Balbi wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>  CONFIG_SCSI_SCAN_ASYNC=y
>>>>>> -CONFIG_ATA=y
>>>>>> -CONFIG_SATA_AHCI_PLATFORM=y
>>>>>> -CONFIG_MD=y
>>>>>> +CONFIG_ATA=m
>>>>>> +CONFIG_SATA_AHCI_PLATFORM=m
>>>>>
>>>>> Isn't this needed for the rootfs on SATA devices?
>>>>
>>>> there's no known boards with rootfs on SATA. Until then, we can reduce
>>>> the size.
>>>
>>> What makes you say so?
>>> The decision for rootfs on SATA is taken dynamically.
>>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA...
>>
>> I'll leave the decision to Tony. Even though they _can_, they really
>> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
>> annoying to find that special device which works (e.g it can't negotiate
>> lower speeds with SATA III devices and it won't support SATA I).

Yet, it is not that buggy and at least until now, I di not get any
reports about badly working SATA from customers...

>>
>> As of today, we don't know of anybody really shipping anything with
>> rootfs on SATA and distros would rather ship initiramfs than a giant
>> zImage anyway.

So, you just continue to ignore what I'm saying... even after I point
to a device...

Is it SATA that makes it so giant?
Because I find it worth having in SATA than spare some more k's...

>>
>> Tony, your call.
> 
> I think we should move omap2plus_defconfig to be mostly modular and
> usable for distros as a base. Most distros prefer to build almost
> everything as loadable modules. And my preference is that we should
> only keep the minimum rootfs for devices and serial support as
> built-in and rely on initramfs for most drivers. And slowly move
> also the remaining built-in drivers to be loadable modules.
> 
> The reasons for having drivers as loadable modules are many. It
> allows distros to use the same kernel for all the devices without
> bloating the kernel. It makes developing drivers easier as just the
> module needs to be reloaded. And loadable modules protect us from
> cross-framework spaghetti calls in the kernel as the interfaces are 
> clearly defined.
> 
> Are there people really using SATA as rootfs right now on omaps?

Yes. That is exactly my point.

> 
> If it's only something that will be more widely used in the future,
> then I suggest we make it into a loadable module, and presume
> initramfs and loadable module also for any new devices. The same
> way x86 has been doing with distros for years.

The difference from x86 is that we're in embedded here and
although initramfs is a kind of option, but it means, you need to
load even more data during the boot process... it is annoying and
I would not want to use it on embedded.
(BTW, x86_64_defconfig has it compiled in...)

We can also, split the defconfig as it was some time ago... but I
would not want to go that direction...

If we go the initramfs way, then why not also load MMC from it?
That will also reduce kernel size... (but add initramfs size)

I'm sure you will find making the MMC a loadable module inconvenient.
That how I find making the SATA a loadable module...

Right now, we tell our customers that they can use mainline with
omap2plus_defconfig.
If you decide to drop SATA, we will not be able to do that anymore.

Anyway, like Felipe said, it is your call.
I will not interfere anymore...

Felipe Balbi Dec. 26, 2014, 4:37 a.m. UTC | #9

Hi,

On Wed, Dec 24, 2014 at 11:04:01AM -0800, Tony Lindgren wrote:
> * Felipe Balbi <[e-mail]> [141224 07:52]:
> > Hi,
> > 
> > On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > On 12/23/14 18:19, Felipe Balbi wrote:
> > > > On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
> > > >> Hi Felipe,
> > > >>
> > > >> On 12/22/14 20:05, Felipe Balbi wrote:
> > > >>
> > > >> [...]
> > > >>
> > > >>>  CONFIG_SCSI_SCAN_ASYNC=y
> > > >>> -CONFIG_ATA=y
> > > >>> -CONFIG_SATA_AHCI_PLATFORM=y
> > > >>> -CONFIG_MD=y
> > > >>> +CONFIG_ATA=m
> > > >>> +CONFIG_SATA_AHCI_PLATFORM=m
> > > >>
> > > >> Isn't this needed for the rootfs on SATA devices?
> > > > 
> > > > there's no known boards with rootfs on SATA. Until then, we can reduce
> > > > the size.
> > > 
> > > What makes you say so?
> > > The decision for rootfs on SATA is taken dynamically.
> > > OMAP5 boards (specifically cm-t54) can have rootfs on SATA...
> > 
> > I'll leave the decision to Tony. Even though they _can_, they really
> > don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
> > annoying to find that special device which works (e.g it can't negotiate
> > lower speeds with SATA III devices and it won't support SATA I).
> > 
> > As of today, we don't know of anybody really shipping anything with
> > rootfs on SATA and distros would rather ship initiramfs than a giant
> > zImage anyway.
> > 
> > Tony, your call.
> 
> I think we should move omap2plus_defconfig to be mostly modular and
> usable for distros as a base. Most distros prefer to build almost
> everything as loadable modules. And my preference is that we should
> only keep the minimum rootfs for devices and serial support as
> built-in and rely on initramfs for most drivers. And slowly move
> also the remaining built-in drivers to be loadable modules.
> 
> The reasons for having drivers as loadable modules are many. It
> allows distros to use the same kernel for all the devices without
> bloating the kernel. It makes developing drivers easier as just the
> module needs to be reloaded. And loadable modules protect us from
> cross-framework spaghetti calls in the kernel as the interfaces are 
> clearly defined.
> 
> Are there people really using SATA as rootfs right now on omaps?

not that we know :-) The only platforms available today with SATA are
OMAP5432 uEVM and DRA7x EVM, the latter being mostly used by TIers as of
now (at least from mainline point of view).

> If it's only something that will be more widely used in the future,
> then I suggest we make it into a loadable module, and presume
> initramfs and loadable module also for any new devices. The same
> way x86 has been doing with distros for years.

alright, as a module it shall remain.

Felipe Balbi Dec. 26, 2014, 4:42 a.m. UTC | #10

Hi,

On Thu, Dec 25, 2014 at 12:13:07PM +0200, Igor Grinberg wrote:
> Hi Tony,
> 
> On 12/24/14 21:04, Tony Lindgren wrote:
> > * Felipe Balbi <[e-mail]> [141224 07:52]:
> >> Hi,
> >>
> >> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> On 12/23/14 18:19, Felipe Balbi wrote:
> >>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
> >>>>> Hi Felipe,
> >>>>>
> >>>>> On 12/22/14 20:05, Felipe Balbi wrote:
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>>  CONFIG_SCSI_SCAN_ASYNC=y
> >>>>>> -CONFIG_ATA=y
> >>>>>> -CONFIG_SATA_AHCI_PLATFORM=y
> >>>>>> -CONFIG_MD=y
> >>>>>> +CONFIG_ATA=m
> >>>>>> +CONFIG_SATA_AHCI_PLATFORM=m
> >>>>>
> >>>>> Isn't this needed for the rootfs on SATA devices?
> >>>>
> >>>> there's no known boards with rootfs on SATA. Until then, we can reduce
> >>>> the size.
> >>>
> >>> What makes you say so?
> >>> The decision for rootfs on SATA is taken dynamically.
> >>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA...
> >>
> >> I'll leave the decision to Tony. Even though they _can_, they really
> >> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
> >> annoying to find that special device which works (e.g it can't negotiate
> >> lower speeds with SATA III devices and it won't support SATA I).
> 
> Yet, it is not that buggy and at least until now, I di not get any
> reports about badly working SATA from customers...
> 
> >>
> >> As of today, we don't know of anybody really shipping anything with
> >> rootfs on SATA and distros would rather ship initiramfs than a giant
> >> zImage anyway.
> 
> So, you just continue to ignore what I'm saying... even after I point
> to a device...

you pointed a device which *can* have rootfs on SATA, not one which
*has* rootfs on SATA, there's a very big difference there.

> Is it SATA that makes it so giant?
> Because I find it worth having in SATA than spare some more k's...

that's your point of view. As Tony mentioned, we have a very standard
way of dealing with this which is initramfs and x86 has been using that
for the past 15+ years.

> >> Tony, your call.
> > 
> > I think we should move omap2plus_defconfig to be mostly modular and
> > usable for distros as a base. Most distros prefer to build almost
> > everything as loadable modules. And my preference is that we should
> > only keep the minimum rootfs for devices and serial support as
> > built-in and rely on initramfs for most drivers. And slowly move
> > also the remaining built-in drivers to be loadable modules.
> > 
> > The reasons for having drivers as loadable modules are many. It
> > allows distros to use the same kernel for all the devices without
> > bloating the kernel. It makes developing drivers easier as just the
> > module needs to be reloaded. And loadable modules protect us from
> > cross-framework spaghetti calls in the kernel as the interfaces are 
> > clearly defined.
> > 
> > Are there people really using SATA as rootfs right now on omaps?
> 
> Yes. That is exactly my point.

read your email, you said it *CAN* have rootfs on SATA.

> > If it's only something that will be more widely used in the future,
> > then I suggest we make it into a loadable module, and presume
> > initramfs and loadable module also for any new devices. The same
> > way x86 has been doing with distros for years.
> 
> The difference from x86 is that we're in embedded here and

bullshit, you would never ship a product with omap2plus_defconfig. You'd
build your own at which point you would switch SATA to built-in.

> although initramfs is a kind of option, but it means, you need to
> load even more data during the boot process... it is annoying and
> I would not want to use it on embedded.

make your own defconfig.

> (BTW, x86_64_defconfig has it compiled in...)
> 
> We can also, split the defconfig as it was some time ago... but I
> would not want to go that direction...
> 
> If we go the initramfs way, then why not also load MMC from it?
> That will also reduce kernel size... (but add initramfs size)

I'm fine with that. The difference is that people have been relying on
MMC built-in for the past 10+ years, since the old OMAP1 MMC driver,
changing that now is likely to cause some "my board won't boot anymore"
bug reports.

> I'm sure you will find making the MMC a loadable module inconvenient.
> That how I find making the SATA a loadable module...
> 
> Right now, we tell our customers that they can use mainline with
> omap2plus_defconfig.

that's the worst thing you can do. You should at a minimum provide your
customers with a more minimal rootfs. Why would you have your customers
build MUSB on an OMAP5 board ? Why would they build 5 different
network device drivers ? Why would they build almost every single PMIC
we ever used ? The list goes on and on.

Igor Grinberg Dec. 26, 2014, 11:56 a.m. UTC | #11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/26/14 06:42, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Dec 25, 2014 at 12:13:07PM +0200, Igor Grinberg wrote:
>> Hi Tony,
>>
>> On 12/24/14 21:04, Tony Lindgren wrote:
>>> * Felipe Balbi <[e-mail]> [141224 07:52]:
>>>> Hi,
>>>>
>>>> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 12/23/14 18:19, Felipe Balbi wrote:
>>>>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
>>>>>>> Hi Felipe,
>>>>>>>
>>>>>>> On 12/22/14 20:05, Felipe Balbi wrote:
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>>  CONFIG_SCSI_SCAN_ASYNC=y
>>>>>>>> -CONFIG_ATA=y
>>>>>>>> -CONFIG_SATA_AHCI_PLATFORM=y
>>>>>>>> -CONFIG_MD=y
>>>>>>>> +CONFIG_ATA=m
>>>>>>>> +CONFIG_SATA_AHCI_PLATFORM=m
>>>>>>>
>>>>>>> Isn't this needed for the rootfs on SATA devices?
>>>>>>
>>>>>> there's no known boards with rootfs on SATA. Until then, we can reduce
>>>>>> the size.
>>>>>
>>>>> What makes you say so?
>>>>> The decision for rootfs on SATA is taken dynamically.
>>>>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA...
>>>>
>>>> I'll leave the decision to Tony. Even though they _can_, they really
>>>> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
>>>> annoying to find that special device which works (e.g it can't negotiate
>>>> lower speeds with SATA III devices and it won't support SATA I).
>>
>> Yet, it is not that buggy and at least until now, I di not get any
>> reports about badly working SATA from customers...
>>
>>>>
>>>> As of today, we don't know of anybody really shipping anything with
>>>> rootfs on SATA and distros would rather ship initiramfs than a giant
>>>> zImage anyway.
>>
>> So, you just continue to ignore what I'm saying... even after I point
>> to a device...
> 
> you pointed a device which *can* have rootfs on SATA, not one which
> *has* rootfs on SATA, there's a very big difference there.

Yeah, I thought you will parse me in that way...

> 
>> Is it SATA that makes it so giant?
>> Because I find it worth having in SATA than spare some more k's...
> 
> that's your point of view. As Tony mentioned, we have a very standard
> way of dealing with this which is initramfs and x86 has been using that
> for the past 15+ years.

may be, but no... x86 has SATA built in...

> 
>>>> Tony, your call.
>>>
>>> I think we should move omap2plus_defconfig to be mostly modular and
>>> usable for distros as a base. Most distros prefer to build almost
>>> everything as loadable modules. And my preference is that we should
>>> only keep the minimum rootfs for devices and serial support as
>>> built-in and rely on initramfs for most drivers. And slowly move
>>> also the remaining built-in drivers to be loadable modules.
>>>
>>> The reasons for having drivers as loadable modules are many. It
>>> allows distros to use the same kernel for all the devices without
>>> bloating the kernel. It makes developing drivers easier as just the
>>> module needs to be reloaded. And loadable modules protect us from
>>> cross-framework spaghetti calls in the kernel as the interfaces are 
>>> clearly defined.
>>>
>>> Are there people really using SATA as rootfs right now on omaps?
>>
>> Yes. That is exactly my point.
> 
> read your email, you said it *CAN* have rootfs on SATA.

yep, it also *CAN* have rootfs on MMC and NFS and ...

> 
>>> If it's only something that will be more widely used in the future,
>>> then I suggest we make it into a loadable module, and presume
>>> initramfs and loadable module also for any new devices. The same
>>> way x86 has been doing with distros for years.
>>
>> The difference from x86 is that we're in embedded here and
> 
> bullshit, you would never ship a product with omap2plus_defconfig. You'd
> build your own at which point you would switch SATA to built-in.

Yep, that is one of the options indeed, but I'm not asking you to
deal with my problems, right?
I'm feeling like you are trying to insult me.
Are you angry with me? Why?
Is it because I have a different opinion?

> 
>> although initramfs is a kind of option, but it means, you need to
>> load even more data during the boot process... it is annoying and
>> I would not want to use it on embedded.
> 
> make your own defconfig.

This sounds like: mind your own business...
Is that what you want to say?

> 
>> (BTW, x86_64_defconfig has it compiled in...)
>>
>> We can also, split the defconfig as it was some time ago... but I
>> would not want to go that direction...
>>
>> If we go the initramfs way, then why not also load MMC from it?
>> That will also reduce kernel size... (but add initramfs size)
> 
> I'm fine with that. The difference is that people have been relying on
> MMC built-in for the past 10+ years, since the old OMAP1 MMC driver,
> changing that now is likely to cause some "my board won't boot anymore"
> bug reports.

Yep. So there are exceptions, right?

> 
>> I'm sure you will find making the MMC a loadable module inconvenient.
>> That how I find making the SATA a loadable module...
>>
>> Right now, we tell our customers that they can use mainline with
>> omap2plus_defconfig.
> 
> that's the worst thing you can do.

Hmmm... Interesting, so people should not use mainline.

> You should at a minimum provide your
> customers with a more minimal rootfs. Why would you have your customers
> build MUSB on an OMAP5 board ? Why would they build 5 different
> network device drivers ? Why would they build almost every single PMIC
> we ever used ? The list goes on and on.

That is their decision to make. I'm just saying that they can use it.


- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUnUzqAAoJEBDE8YO64EfawVsP/RBnEcOMVLjocMKwB/wVDrAf
PamLBOMHtFNZrqMntL13N25a799h2FS5lYn+jYBw7AkXcdfJUgJeHjivukJMwPdm
RArMzY03HtwXqfH1pn8zpopxbuFgSGRcS6O0k8xAV21iLgSFvLuZTIJK5/9RH3Oi
rznIgrxg1yDpGttm2Btq+55IIVhStf2IwPSqEidK/73Rjx08a2j+bkSXnlYVnhyx
ZNfumCpcHoAFLX3SQIbAKSpWNO0jMvqJ2dqN+wNb0A/RtoWWf26ITdVEXEpt0HE7
g1r7xvcEVZsXaeN2rMQsfNaZk9zGHOM50v3G6n/LMkyCa0oWO2CPPwTeCPoDdzgZ
5HAjHOXSnYV3QcMj9cklI09vYIKRPvASNyGcEft/HsYv98TmbNU5YGdTHwW66aDK
5VKKKLBwuGOJC5k+fQdEO38oqrEuxWfHRolSCoOmZXfaTPYAAGzU9s4NL9OisgPa
pqyOIqU4/WexWzFyhKE28ebJmtsNtlAyNiXPV/4s0y4hf0E0Se1Z2DhhOSI9BZK+
P6ce+pqrDZgJlGMN13PR4p6vxCEIW6+xZu8sUTHEMs8EhplQRrduSud6OY60ocjm
5F/f2LicydOu7w1OyO3HoENhdZ1EuSTp1njlJ5DkGhHNtw10rFr+5sSUcooPFQwg
9eozH1HMbeJS4CRgV5iT
=VLzg
-----END PGP SIGNATURE-----

Igor Grinberg Dec. 26, 2014, 12:08 p.m. UTC | #12

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/26/14 06:37, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Dec 24, 2014 at 11:04:01AM -0800, Tony Lindgren wrote:
>> * Felipe Balbi <[e-mail]> [141224 07:52]:
>>> Hi,
>>>
>>> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 12/23/14 18:19, Felipe Balbi wrote:
>>>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
>>>>>> Hi Felipe,
>>>>>>
>>>>>> On 12/22/14 20:05, Felipe Balbi wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>  CONFIG_SCSI_SCAN_ASYNC=y
>>>>>>> -CONFIG_ATA=y
>>>>>>> -CONFIG_SATA_AHCI_PLATFORM=y
>>>>>>> -CONFIG_MD=y
>>>>>>> +CONFIG_ATA=m
>>>>>>> +CONFIG_SATA_AHCI_PLATFORM=m
>>>>>>
>>>>>> Isn't this needed for the rootfs on SATA devices?
>>>>>
>>>>> there's no known boards with rootfs on SATA. Until then, we can reduce
>>>>> the size.
>>>>
>>>> What makes you say so?
>>>> The decision for rootfs on SATA is taken dynamically.
>>>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA...
>>>
>>> I'll leave the decision to Tony. Even though they _can_, they really
>>> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
>>> annoying to find that special device which works (e.g it can't negotiate
>>> lower speeds with SATA III devices and it won't support SATA I).
>>>
>>> As of today, we don't know of anybody really shipping anything with
>>> rootfs on SATA and distros would rather ship initiramfs than a giant
>>> zImage anyway.
>>>
>>> Tony, your call.
>>
>> I think we should move omap2plus_defconfig to be mostly modular and
>> usable for distros as a base. Most distros prefer to build almost
>> everything as loadable modules. And my preference is that we should
>> only keep the minimum rootfs for devices and serial support as
>> built-in and rely on initramfs for most drivers. And slowly move
>> also the remaining built-in drivers to be loadable modules.
>>
>> The reasons for having drivers as loadable modules are many. It
>> allows distros to use the same kernel for all the devices without
>> bloating the kernel. It makes developing drivers easier as just the
>> module needs to be reloaded. And loadable modules protect us from
>> cross-framework spaghetti calls in the kernel as the interfaces are 
>> clearly defined.
>>
>> Are there people really using SATA as rootfs right now on omaps?
> 
> not that we know :-) The only platforms available today with SATA are
> OMAP5432 uEVM and DRA7x EVM,

I'm sorry... that is not true.

> the latter being mostly used by TIers as of
> now (at least from mainline point of view).

the keyword is mostly... And I'm also not sure this is true these days...

But, really, don't mind me. We will find our solutions (we always did).
I mean, Felipe wants it out so badly...
Who am I to say anything...

> 
>> If it's only something that will be more widely used in the future,
>> then I suggest we make it into a loadable module, and presume
>> initramfs and loadable module also for any new devices. The same
>> way x86 has been doing with distros for years.
> 
> alright, as a module it shall remain.
> 

- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUnU+qAAoJEBDE8YO64Efa8IgP/jQlP5nHLK8aWXpNIrRH3dri
IzIDvWqUC+zYqIgg1JcPmxgfZ+5vhYgjCVx+q0m/81qk164QK4zGs6gDr8sDjK8O
Q8rqujAbVFO2nmJHmq8VhTpapqTDtG5sH/HvtaWPtBxmBoA5yLdA8KObV9Gf2871
GvlP1WS/CUu6ClzEERsdWJkfpkqrJ1My1Ox7zCkL80uqM5z6jmje2sam4AiuGWSK
Kb/Kdkmqae1lizjSnyW0ZckTyCuLUPdzvV+OCq3JrDDJV9W3hrA0KmYKUe4gO0JI
Z2PNMKvbBuA9miY0IPsbILYkQ01OoKOwZXfDrhhK0k5FLPxSujc9NbfwqByTK2gi
Ca5zZKoTaUN8A2YoxdNv+m9gILnlgDCtRjvc6elEYZBLZd+03TsxgWAB+aYfx03d
1W5+qp8jSGBRzsDg5o8ir6mS8xYM3Hpy7xDPT46BqjKzczMCdeXH5MqibL34kqtC
mMhMw1UzZ5qGOyHXqYE9bosgfpbf+WxmVta7/RRgaJJwo7N41pf1sDyoJjczAfPo
cAQNeIwPd1DxiS2nO46i4w8FUq10Lf3I7mXxabXIsU3YD81QpjxL5arlFXlPfDVg
Ki8GW1yE81RepD5xuhhz3/U9pKvozSewH5BlHBo6h9rSBkyyBPs2NbxSxjSNct1H
MKEG/rYHptCRIntrZ8pm
=w62Y
-----END PGP SIGNATURE-----

[e-mail] Dec. 26, 2014, 1:04 p.m. UTC | #13

On 12/25/2014 12:13 PM, Igor Grinberg wrote:
> Hi Tony,
> 
> On 12/24/14 21:04, Tony Lindgren wrote:
>> * Felipe Balbi <[e-mail]> [141224 07:52]:
>>> Hi,
>>>
>>> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 12/23/14 18:19, Felipe Balbi wrote:
>>>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
>>>>>> Hi Felipe,
>>>>>>
>>>>>> On 12/22/14 20:05, Felipe Balbi wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>   CONFIG_SCSI_SCAN_ASYNC=y
>>>>>>> -CONFIG_ATA=y
>>>>>>> -CONFIG_SATA_AHCI_PLATFORM=y
>>>>>>> -CONFIG_MD=y
>>>>>>> +CONFIG_ATA=m
>>>>>>> +CONFIG_SATA_AHCI_PLATFORM=m
>>>>>>
>>>>>> Isn't this needed for the rootfs on SATA devices?
>>>>>
>>>>> there's no known boards with rootfs on SATA. Until then, we can reduce
>>>>> the size.
>>>>
>>>> What makes you say so?
>>>> The decision for rootfs on SATA is taken dynamically.
>>>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA...
>>>
>>> I'll leave the decision to Tony. Even though they _can_, they really
>>> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
>>> annoying to find that special device which works (e.g it can't negotiate
>>> lower speeds with SATA III devices and it won't support SATA I).
> 
> Yet, it is not that buggy and at least until now, I di not get any
> reports about badly working SATA from customers...
> 
>>>
>>> As of today, we don't know of anybody really shipping anything with
>>> rootfs on SATA and distros would rather ship initiramfs than a giant
>>> zImage anyway.
> 
> So, you just continue to ignore what I'm saying... even after I point
> to a device...
> 
> Is it SATA that makes it so giant?
> Because I find it worth having in SATA than spare some more k's...
> 

SATA code occupies ~179Kbytes - checked on 3.19-rc1
CONFIG_ATA=y
CONFIG_SATA_AHCI_PLATFORM=y
CONFIG_MD=y (seems it will give +-0K)

>>>
>>> Tony, your call

May be it will be good thing to split this patch. That way more information
will be stored in commit log about which set of options gives us what benefits.
And also, It will allow to continue with agreed changes.
?

>>
>> I think we should move omap2plus_defconfig to be mostly modular and
>> usable for distros as a base. Most distros prefer to build almost
>> everything as loadable modules. And my preference is that we should
>> only keep the minimum rootfs for devices and serial support as
>> built-in and rely on initramfs for most drivers. And slowly move
>> also the remaining built-in drivers to be loadable modules.
>>
>> The reasons for having drivers as loadable modules are many. It
>> allows distros to use the same kernel for all the devices without
>> bloating the kernel. It makes developing drivers easier as just the
>> module needs to be reloaded. And loadable modules protect us from
>> cross-framework spaghetti calls in the kernel as the interfaces are
>> clearly defined.
>>
>> Are there people really using SATA as rootfs right now on omaps?
> 
> Yes. That is exactly my point.
> 

From my side I'd like to note that I know about few ongoing projects on DRA7x EVM
where SATA is used as rootfs - now It is the fast possible way to start Android.

Javier Martinez Canillas Dec. 26, 2014, 1:42 p.m. UTC | #14

Hello all,

On Fri, Dec 26, 2014 at 12:56 PM, Igor Grinberg <[e-mail]> wrote:
>>>>> Tony, your call.
>>>>
>>>> I think we should move omap2plus_defconfig to be mostly modular and
>>>> usable for distros as a base. Most distros prefer to build almost
>>>> everything as loadable modules. And my preference is that we should
>>>> only keep the minimum rootfs for devices and serial support as
>>>> built-in and rely on initramfs for most drivers. And slowly move
>>>> also the remaining built-in drivers to be loadable modules.
>>>>
>>>> The reasons for having drivers as loadable modules are many. It
>>>> allows distros to use the same kernel for all the devices without
>>>> bloating the kernel. It makes developing drivers easier as just the
>>>> module needs to be reloaded. And loadable modules protect us from
>>>> cross-framework spaghetti calls in the kernel as the interfaces are
>>>> clearly defined.
>>>>

I do agree with Tony and Felipe that we should try to build as much
stuff as possible as a module instead of built-in to match what
distros do and what has been done for x86 for years.

However, if that's the case I wonder what's the point of having both
an omap2plus_defconfig and a multi_v7_defconfig? Would it make sense
to get rid of the SoC specific configs then and just use the single
ARMv7 defconfig for all SoCs with most of the options enabled as a
module?

FYI, some time ago I posted a patch to enable SBS-compliant batteries
support as a module for Exynos defconfig and was told to re-spin the
patch and enabling it as built-in instead since the most popular use
case for exynos_defconfig was development and people usually just copy
the kernel binary and not the modules [0].

So it seems that each ARM SoC community has a different opinion about
how things should be configured and do it differently.

>>
>> bullshit, you would never ship a product with omap2plus_defconfig. You'd
>> build your own at which point you would switch SATA to built-in.
>

There are different opinions but let please try to keep the discussion
constructive and use a polite tone.

>>>
>>> Right now, we tell our customers that they can use mainline with
>>> omap2plus_defconfig.
>>
>> that's the worst thing you can do.
>

I'm confused, Felipe said that customers should not base their config
from omap2plus_defconfig but AFAUI Tony's argument is exactly the
opposite, that everything should be configured as a module so distros
can use omap2plus_defconfig as a base. So, is or is not expected that
people will use omap2plus_defconfig as a base for their own config?

I think the problem is that there isn't an agreement about what is the
purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7
defconfigs (or at least is not well documented since I could not find
it). So, IMHO this concern should be raised to the ARM SoC maintainers
and there should be an agreement in the ARM community as a whole about
how things should be configured on each defconfig, and all SoCs should
follow the agreed rule.

Otherwise it seems that the motivation for each kconfig symbol enabled
is just to make the workflow of the developer posting the patches
easier and wins whoever shouts louder.

Thanks a lot and best regards,
Javier

[0]: http://www.spinics.net/lists/arm-kernel/msg353808.html

Felipe Balbi Dec. 26, 2014, 3:09 p.m. UTC | #15

Hi,

On Fri, Dec 26, 2014 at 01:56:26PM +0200, Igor Grinberg wrote:
> >>>> Tony, your call.
> >>>
> >>> I think we should move omap2plus_defconfig to be mostly modular and
> >>> usable for distros as a base. Most distros prefer to build almost
> >>> everything as loadable modules. And my preference is that we should
> >>> only keep the minimum rootfs for devices and serial support as
> >>> built-in and rely on initramfs for most drivers. And slowly move
> >>> also the remaining built-in drivers to be loadable modules.
> >>>
> >>> The reasons for having drivers as loadable modules are many. It
> >>> allows distros to use the same kernel for all the devices without
> >>> bloating the kernel. It makes developing drivers easier as just the
> >>> module needs to be reloaded. And loadable modules protect us from
> >>> cross-framework spaghetti calls in the kernel as the interfaces are 
> >>> clearly defined.
> >>>
> >>> Are there people really using SATA as rootfs right now on omaps?
> >>
> >> Yes. That is exactly my point.
> > 
> > read your email, you said it *CAN* have rootfs on SATA.
> 
> yep, it also *CAN* have rootfs on MMC and NFS and ...

those we *know* people are using as rootfs. We know of several users who
are actually using it :-)

> >>> If it's only something that will be more widely used in the future,
> >>> then I suggest we make it into a loadable module, and presume
> >>> initramfs and loadable module also for any new devices. The same
> >>> way x86 has been doing with distros for years.
> >>
> >> The difference from x86 is that we're in embedded here and
> > 
> > bullshit, you would never ship a product with omap2plus_defconfig. You'd
> > build your own at which point you would switch SATA to built-in.
> 
> Yep, that is one of the options indeed, but I'm not asking you to
> deal with my problems, right?
> I'm feeling like you are trying to insult me.
> Are you angry with me? Why?
> Is it because I have a different opinion?

heh, cute :-)

> >> although initramfs is a kind of option, but it means, you need to
> >> load even more data during the boot process... it is annoying and
> >> I would not want to use it on embedded.
> > 
> > make your own defconfig.
> 
> This sounds like: mind your own business...
> Is that what you want to say?

nope, not really. Just saying that if you're really concerned about
being embedded and that initramfs takes that much more time to load,
you'd just make your own defconfig and maintain it out-of-tree.

RMK does that for quite a few boards, I do it for my boards and also for
my x86 desktops/laptops.

It's not really rocket science.

> >> (BTW, x86_64_defconfig has it compiled in...)
> >>
> >> We can also, split the defconfig as it was some time ago... but I
> >> would not want to go that direction...
> >>
> >> If we go the initramfs way, then why not also load MMC from it?
> >> That will also reduce kernel size... (but add initramfs size)
> > 
> > I'm fine with that. The difference is that people have been relying on
> > MMC built-in for the past 10+ years, since the old OMAP1 MMC driver,
> > changing that now is likely to cause some "my board won't boot anymore"
> > bug reports.
> 
> Yep. So there are exceptions, right?

never claimed the contrary.

> >> I'm sure you will find making the MMC a loadable module inconvenient.
> >> That how I find making the SATA a loadable module...
> >>
> >> Right now, we tell our customers that they can use mainline with
> >> omap2plus_defconfig.
> > 
> > that's the worst thing you can do.
> 
> Hmmm... Interesting, so people should not use mainline.

now you're reading what you want to read ;-) Using my statements out of
context.

It's clear (actually s/rootfs/defconfig below) that I meant defconfig.

> > You should at a minimum provide your
> > customers with a more minimal rootfs. Why would you have your customers

oh wait, not rootfs, defconfig.

> > build MUSB on an OMAP5 board ? Why would they build 5 different
> > network device drivers ? Why would they build almost every single PMIC
> > we ever used ? The list goes on and on.
> 
> That is their decision to make. I'm just saying that they can use it.

right, and they can switch SATA to built-in if they want to ship an
initramfs-less product, don't you think ?

Or they can append initramfs to the kernel image and not even have a
root filesystem anywhere (been there, done that), but that's not
relevant to this discussion.

Anyway, I'll leave it to Tony.

Felipe Balbi Dec. 26, 2014, 3:19 p.m. UTC | #16

Hi,

On Fri, Dec 26, 2014 at 02:42:07PM +0100, Javier Martinez Canillas wrote:
> Hello all,
> 
> On Fri, Dec 26, 2014 at 12:56 PM, Igor Grinberg <[e-mail]> wrote:
> >>>>> Tony, your call.
> >>>>
> >>>> I think we should move omap2plus_defconfig to be mostly modular and
> >>>> usable for distros as a base. Most distros prefer to build almost
> >>>> everything as loadable modules. And my preference is that we should
> >>>> only keep the minimum rootfs for devices and serial support as
> >>>> built-in and rely on initramfs for most drivers. And slowly move
> >>>> also the remaining built-in drivers to be loadable modules.
> >>>>
> >>>> The reasons for having drivers as loadable modules are many. It
> >>>> allows distros to use the same kernel for all the devices without
> >>>> bloating the kernel. It makes developing drivers easier as just the
> >>>> module needs to be reloaded. And loadable modules protect us from
> >>>> cross-framework spaghetti calls in the kernel as the interfaces are
> >>>> clearly defined.
> >>>>
> 
> I do agree with Tony and Felipe that we should try to build as much
> stuff as possible as a module instead of built-in to match what
> distros do and what has been done for x86 for years.
> 
> However, if that's the case I wonder what's the point of having both
> an omap2plus_defconfig and a multi_v7_defconfig? Would it make sense

I wonder the same thing, but look at multi_v7_defconfig today. Almost
everything is built-in, which makes the kernel image enormous (5.5MiB).

> to get rid of the SoC specific configs then and just use the single
> ARMv7 defconfig for all SoCs with most of the options enabled as a
> module?

if people accept switching some of those as modules, sure. I don't mind
that at all. I'll still continue to maintain my out-of-tree defconfigs
for my boards anyway. It's also very good to have a generic defconfig
which will just work with everything I have.

> FYI, some time ago I posted a patch to enable SBS-compliant batteries
> support as a module for Exynos defconfig and was told to re-spin the
> patch and enabling it as built-in instead since the most popular use
> case for exynos_defconfig was development and people usually just copy
> the kernel binary and not the modules [0].

lol, that's the reason why I don't use multi_v7_defconfig.

> So it seems that each ARM SoC community has a different opinion about
> how things should be configured and do it differently.

I wouldn't be surprised.

> >> bullshit, you would never ship a product with omap2plus_defconfig. You'd
> >> build your own at which point you would switch SATA to built-in.
> >
> 
> There are different opinions but let please try to keep the discussion
> constructive and use a polite tone.
> 
> >>>
> >>> Right now, we tell our customers that they can use mainline with
> >>> omap2plus_defconfig.
> >>
> >> that's the worst thing you can do.
> >
> 
> I'm confused, Felipe said that customers should not base their config
> from omap2plus_defconfig but AFAUI Tony's argument is exactly the
> opposite, that everything should be configured as a module so distros

basing on omap2plus_defconfig is never an issue. Claiming that you're
concerned about the extra KiBs for loading initramfs and then saying you
ship embedded products with omap2plus_defconfig is BS.

> can use omap2plus_defconfig as a base. So, is or is not expected that
> people will use omap2plus_defconfig as a base for their own config?

I never claimed that people should not use it as a *base*, rather it
should not be used to build a product's kernel/modules. Imagine you
shipping an embedded product based off of OMAP5 and you add CPSW, QSPI,
MUSB, a ton of touchscreen drivers you don't use, several PMIC drivers
built-in, etc. It's a waste of space and just bloats that product's
zImage.

> I think the problem is that there isn't an agreement about what is the
> purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7
> defconfigs (or at least is not well documented since I could not find
> it). So, IMHO this concern should be raised to the ARM SoC maintainers
> and there should be an agreement in the ARM community as a whole about
> how things should be configured on each defconfig, and all SoCs should
> follow the agreed rule.

OTOH, the OMAP defconfig is part of the OMAP port and Tony will have the
final saying about it, right ?

> Otherwise it seems that the motivation for each kconfig symbol enabled
> is just to make the workflow of the developer posting the patches
> easier and wins whoever shouts louder.

it is just to make things easier. In fact, I only enabled AM437x SK's
drivers on o2+_dc because I got tired of people telling me that board
"doesn't work with mainline" and being completely reluctant to change
their defconfig. At that point I talked to Tony and he said "as long as
things are added as modules, I don't mind".

cheers

Felipe Balbi Dec. 26, 2014, 3:24 p.m. UTC | #17

Hi,

On Fri, Dec 26, 2014 at 02:08:10PM +0200, Igor Grinberg wrote:
> >> I think we should move omap2plus_defconfig to be mostly modular and
> >> usable for distros as a base. Most distros prefer to build almost
> >> everything as loadable modules. And my preference is that we should
> >> only keep the minimum rootfs for devices and serial support as
> >> built-in and rely on initramfs for most drivers. And slowly move
> >> also the remaining built-in drivers to be loadable modules.
> >>
> >> The reasons for having drivers as loadable modules are many. It
> >> allows distros to use the same kernel for all the devices without
> >> bloating the kernel. It makes developing drivers easier as just the
> >> module needs to be reloaded. And loadable modules protect us from
> >> cross-framework spaghetti calls in the kernel as the interfaces are 
> >> clearly defined.
> >>
> >> Are there people really using SATA as rootfs right now on omaps?
> > 
> > not that we know :-) The only platforms available today with SATA are
> > OMAP5432 uEVM and DRA7x EVM,
> 
> I'm sorry... that is not true.

That's not what you have said thus far. So far you only said it *can*
have, you have not explicitly said a customer really *is* using rootfs
on SATA.

Personally, I really don't care. It's just a defconfig patch and
kernel configuration is very, very easy to change at any time. You can
even have an out of tree config fragment just turning SATA=y again.

Have a look at scripts/kconfig/merge_config.sh

> > the latter being mostly used by TIers as of
> > now (at least from mainline point of view).
> 
> the keyword is mostly... And I'm also not sure this is true these days...
> 
> But, really, don't mind me. We will find our solutions (we always did).
> I mean, Felipe wants it out so badly...
> Who am I to say anything...

cute :-)

Felipe Balbi Dec. 26, 2014, 3:26 p.m. UTC | #18

Hi,

On Fri, Dec 26, 2014 at 03:04:00PM +0200, [e-mail] wrote:
> >>>
> >>> Tony, your call
> 
> May be it will be good thing to split this patch. That way more
> information will be stored in commit log about which set of options
> gives us what benefits.  And also, It will allow to continue with
> agreed changes.  ?

can be done, but then again, it's just a defconfig change. Tony, your
call.

> >> I think we should move omap2plus_defconfig to be mostly modular and
> >> usable for distros as a base. Most distros prefer to build almost
> >> everything as loadable modules. And my preference is that we should
> >> only keep the minimum rootfs for devices and serial support as
> >> built-in and rely on initramfs for most drivers. And slowly move
> >> also the remaining built-in drivers to be loadable modules.
> >>
> >> The reasons for having drivers as loadable modules are many. It
> >> allows distros to use the same kernel for all the devices without
> >> bloating the kernel. It makes developing drivers easier as just the
> >> module needs to be reloaded. And loadable modules protect us from
> >> cross-framework spaghetti calls in the kernel as the interfaces are
> >> clearly defined.
> >>
> >> Are there people really using SATA as rootfs right now on omaps?
> > 
> > Yes. That is exactly my point.
> > 
> 
> From my side I'd like to note that I know about few ongoing projects
> on DRA7x EVM where SATA is used as rootfs - now It is the fast
> possible way to start Android.

now this is something different. This is evidence that there are people
relying on SATA on rootfs. I'll leave to Tony again.

Tony Lindgren Dec. 26, 2014, 4:13 p.m. UTC | #19

* Felipe Balbi <[e-mail]> [141226 07:29]:
> On Fri, Dec 26, 2014 at 03:04:00PM +0200, [e-mail] wrote:
> > >>>
> > >>> Tony, your call
> > 
> > May be it will be good thing to split this patch. That way more
> > information will be stored in commit log about which set of options
> > gives us what benefits.  And also, It will allow to continue with
> > agreed changes.  ?
> 
> can be done, but then again, it's just a defconfig change. Tony, your
> call.
> 
> > >> I think we should move omap2plus_defconfig to be mostly modular and
> > >> usable for distros as a base. Most distros prefer to build almost
> > >> everything as loadable modules. And my preference is that we should
> > >> only keep the minimum rootfs for devices and serial support as
> > >> built-in and rely on initramfs for most drivers. And slowly move
> > >> also the remaining built-in drivers to be loadable modules.
> > >>
> > >> The reasons for having drivers as loadable modules are many. It
> > >> allows distros to use the same kernel for all the devices without
> > >> bloating the kernel. It makes developing drivers easier as just the
> > >> module needs to be reloaded. And loadable modules protect us from
> > >> cross-framework spaghetti calls in the kernel as the interfaces are
> > >> clearly defined.
> > >>
> > >> Are there people really using SATA as rootfs right now on omaps?
> > > 
> > > Yes. That is exactly my point.
> > > 
> > 
> > From my side I'd like to note that I know about few ongoing projects
> > on DRA7x EVM where SATA is used as rootfs - now It is the fast
> > possible way to start Android.
> 
> now this is something different. This is evidence that there are people
> relying on SATA on rootfs. I'll leave to Tony again.

OK sounds like people are really using SATA as rootfs, so we might as
well keep it built in then. And it does not affect the PM on the devices
that do have PM working, that has been a problem with having some
drivers built-in.

We can still work towards making the current rootfs device drivers
into loadable modules in the long term :)

Regards,

Tony

Igor Grinberg Dec. 26, 2014, 4:43 p.m. UTC | #20

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/26/14 17:09, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Dec 26, 2014 at 01:56:26PM +0200, Igor Grinberg wrote:
>>>>>> Tony, your call.
>>>>>
>>>>> I think we should move omap2plus_defconfig to be mostly modular and
>>>>> usable for distros as a base. Most distros prefer to build almost
>>>>> everything as loadable modules. And my preference is that we should
>>>>> only keep the minimum rootfs for devices and serial support as
>>>>> built-in and rely on initramfs for most drivers. And slowly move
>>>>> also the remaining built-in drivers to be loadable modules.
>>>>>
>>>>> The reasons for having drivers as loadable modules are many. It
>>>>> allows distros to use the same kernel for all the devices without
>>>>> bloating the kernel. It makes developing drivers easier as just the
>>>>> module needs to be reloaded. And loadable modules protect us from
>>>>> cross-framework spaghetti calls in the kernel as the interfaces are 
>>>>> clearly defined.
>>>>>
>>>>> Are there people really using SATA as rootfs right now on omaps?
>>>>
>>>> Yes. That is exactly my point.
>>>
>>> read your email, you said it *CAN* have rootfs on SATA.
>>
>> yep, it also *CAN* have rootfs on MMC and NFS and ...
> 
> those we *know* people are using as rootfs. We know of several users who
> are actually using it :-)

I think we've had enough of the *can* or *cannot* stuff...
So, just accept that people are using SATA as rootfs and will be using
it in the future products too.

> 
>>>>> If it's only something that will be more widely used in the future,
>>>>> then I suggest we make it into a loadable module, and presume
>>>>> initramfs and loadable module also for any new devices. The same
>>>>> way x86 has been doing with distros for years.
>>>>
>>>> The difference from x86 is that we're in embedded here and
>>>
>>> bullshit, you would never ship a product with omap2plus_defconfig. You'd
>>> build your own at which point you would switch SATA to built-in.
>>
>> Yep, that is one of the options indeed, but I'm not asking you to
>> deal with my problems, right?
>> I'm feeling like you are trying to insult me.
>> Are you angry with me? Why?
>> Is it because I have a different opinion?
> 
> heh, cute :-)

so this is what it takes to calm you down? good!

> 
>>>> although initramfs is a kind of option, but it means, you need to
>>>> load even more data during the boot process... it is annoying and
>>>> I would not want to use it on embedded.
>>>
>>> make your own defconfig.
>>
>> This sounds like: mind your own business...
>> Is that what you want to say?
> 
> nope, not really.

good!

> Just saying that if you're really concerned about
> being embedded and that initramfs takes that much more time to load,
> you'd just make your own defconfig and maintain it out-of-tree.
> 
> RMK does that for quite a few boards, I do it for my boards and also for
> my x86 desktops/laptops.
> 
> It's not really rocket science.

Yes indeed. We do this *all* the time.
To understand what is this about, first you need to make yourself
familiar with the case.

> 
>>>> (BTW, x86_64_defconfig has it compiled in...)
>>>>
>>>> We can also, split the defconfig as it was some time ago... but I
>>>> would not want to go that direction...
>>>>
>>>> If we go the initramfs way, then why not also load MMC from it?
>>>> That will also reduce kernel size... (but add initramfs size)
>>>
>>> I'm fine with that. The difference is that people have been relying on
>>> MMC built-in for the past 10+ years, since the old OMAP1 MMC driver,
>>> changing that now is likely to cause some "my board won't boot anymore"
>>> bug reports.
>>
>> Yep. So there are exceptions, right?
> 
> never claimed the contrary.

So, those exactly kind of bug reports I'm expecting to get, once you
compile out SATA...

> 
>>>> I'm sure you will find making the MMC a loadable module inconvenient.
>>>> That how I find making the SATA a loadable module...
>>>>
>>>> Right now, we tell our customers that they can use mainline with
>>>> omap2plus_defconfig.
>>>
>>> that's the worst thing you can do.
>>
>> Hmmm... Interesting, so people should not use mainline.
> 
> now you're reading what you want to read ;-) Using my statements out of
> context.

I'm sorry, but you seemed to not care about the context, but just call
stuff a BS or worst thing to do... and that is w/o even understanding
the case.

> 
> It's clear (actually s/rootfs/defconfig below) that I meant defconfig.
> 

Well, no, I'm sorry it is not clear, but I accept the amendment.

>>> You should at a minimum provide your
>>> customers with a more minimal rootfs. Why would you have your customers
> 
> oh wait, not rootfs, defconfig.
> 
>>> build MUSB on an OMAP5 board ? Why would they build 5 different
>>> network device drivers ? Why would they build almost every single PMIC
>>> we ever used ? The list goes on and on.
>>
>> That is their decision to make. I'm just saying that they can use it.
> 
> right, and they can switch SATA to built-in if they want to ship an
> initramfs-less product, don't you think ?

no. It *very* depends on who your customer is and sometimes compiling
kernel with provided defaults is fine, but changing those is not.
You can say, "come on... if they build the kernel, they can also change
the configuration..."
That's what I thought several years ago, but it proved to be wrong...

Now, after all the out-of-tree defconfig proposals, why do you care
about the omap2plus_defconfig providing a smaller (by <200K according
to Grygorii) kernel?

- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUnZBFAAoJEBDE8YO64Efa/RUP/2I4eB9BWP1ysxP/AiyZ8/mb
9ETGguxpGU5JJ65RE0umT3n6H+6g6fQ0Rq67ojeCWYg76jMhLKDpshhVSLO9JKW1
VWh6b6OLHdP46fsdDsNS6ug6FBoEka/30PckBGze913pN1rQwyb4GsRqY7itld/x
2fWcKfoMuwDuXK6c0Cq4trYfYbRr+36X1quPO1KdT1F7TTBLx+WqucxtU7lNyAvi
NVxNs5BU/PGT6j8Dd+qb0uT5C7XGSIQ6mAEeO30aXlysa0oYj8te3cCiU6BWcav7
y8MHyKSHsPdiaD5sFsGzLtF17tXnWC67znI7ajuGncA8wumHLpTPuhl43/YnBH04
NSOiEG2ly5PoqMfV1Ml/hI4blDteABOVYJhysN8bs1SQyaTc/VIh6uiSshRYQNCT
9jaO6utulxF6PM/2tnB9JR9ci19J1Y+VohB1rtmbG/jvpS2QHnQthD2esoVXN0aq
+p0/zlsu7osfXcXpdtcuOmZKUntlT9Bfh7A1ppd7fE0AfZmMu5b7KcXAYbeCsCH0
q3nzN/loAuGjjx/BRbWt44O0VY/9yQVUtm/KKGbglf6piuI0EdlWY9kM5chPMt0h
GAKUvSDgNZoZEECzb4ANZAJup1e+KTN3AaLBM03TgBxDdATJZuuwGydmQKcJliva
ME6omZmsXXph8Le1srIh
=GvGH
-----END PGP SIGNATURE-----

Javier Martinez Canillas Dec. 26, 2014, 7:38 p.m. UTC | #21

Hello Felipe,

On Fri, Dec 26, 2014 at 4:19 PM, Felipe Balbi <[e-mail]> wrote:
>
> I wonder the same thing, but look at multi_v7_defconfig today. Almost
> everything is built-in, which makes the kernel image enormous (5.5MiB).
>
>> to get rid of the SoC specific configs then and just use the single
>> ARMv7 defconfig for all SoCs with most of the options enabled as a
>> module?
>
> if people accept switching some of those as modules, sure. I don't mind
> that at all. I'll still continue to maintain my out-of-tree defconfigs
> for my boards anyway. It's also very good to have a generic defconfig
> which will just work with everything I have.
>
>> FYI, some time ago I posted a patch to enable SBS-compliant batteries
>> support as a module for Exynos defconfig and was told to re-spin the
>> patch and enabling it as built-in instead since the most popular use
>> case for exynos_defconfig was development and people usually just copy
>> the kernel binary and not the modules [0].
>
> lol, that's the reason why I don't use multi_v7_defconfig.
>

Agreed, on its current form I wonder what's the use case for
multi_v7_defconfig. I guess most options will slowly be changed to be
built as a module though to be similar to what distros do.

>> can use omap2plus_defconfig as a base. So, is or is not expected that
>> people will use omap2plus_defconfig as a base for their own config?
>
> I never claimed that people should not use it as a *base*, rather it
> should not be used to build a product's kernel/modules. Imagine you
> shipping an embedded product based off of OMAP5 and you add CPSW, QSPI,
> MUSB, a ton of touchscreen drivers you don't use, several PMIC drivers
> built-in, etc. It's a waste of space and just bloats that product's
> zImage.
>

Got it, thanks for the clarification. I agree that omap2plus_defconfig
is very bloated to be used for products as-is. I also have custom
defconfig to test the OMAP boards I maintain which is basically
omap2plus_defconfig + a merged config fragment (using merge_config.sh)
that disables and enables needed options.

>> I think the problem is that there isn't an agreement about what is the
>> purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7
>> defconfigs (or at least is not well documented since I could not find
>> it). So, IMHO this concern should be raised to the ARM SoC maintainers
>> and there should be an agreement in the ARM community as a whole about
>> how things should be configured on each defconfig, and all SoCs should
>> follow the agreed rule.
>
> OTOH, the OMAP defconfig is part of the OMAP port and Tony will have the
> final saying about it, right ?
>

Sorry, I didn't mean that Tony doesn't have the last word for omap
defconfig. My point was that it should be nice to get a consensus
about this and specially document it to make life easier for everyone.
People posting defconfig changes will know what the rule is and we can
avoid having these kind of discussions which I have had many times in
the past when posting defconfig changes and I'm sure I will have more
in the future again.

But I don't really mind tbh, I will keep maintaining my custom
defconfigs anyways and post wnen I think that enabling a config option
in a mainline defconfig makes sense and will do as a module or
built-in depending of what the SoC maintainer tells me to use.

Best regards,
Javier

Felipe Balbi Dec. 26, 2014, 7:47 p.m. UTC | #22

Hi,

On Fri, Dec 26, 2014 at 08:38:10PM +0100, Javier Martinez Canillas wrote:
> > I wonder the same thing, but look at multi_v7_defconfig today. Almost
> > everything is built-in, which makes the kernel image enormous (5.5MiB).
> >
> >> to get rid of the SoC specific configs then and just use the single
> >> ARMv7 defconfig for all SoCs with most of the options enabled as a
> >> module?
> >
> > if people accept switching some of those as modules, sure. I don't mind
> > that at all. I'll still continue to maintain my out-of-tree defconfigs
> > for my boards anyway. It's also very good to have a generic defconfig
> > which will just work with everything I have.
> >
> >> FYI, some time ago I posted a patch to enable SBS-compliant batteries
> >> support as a module for Exynos defconfig and was told to re-spin the
> >> patch and enabling it as built-in instead since the most popular use
> >> case for exynos_defconfig was development and people usually just copy
> >> the kernel binary and not the modules [0].
> >
> > lol, that's the reason why I don't use multi_v7_defconfig.
> >
> 
> Agreed, on its current form I wonder what's the use case for
> multi_v7_defconfig. I guess most options will slowly be changed to be
> built as a module though to be similar to what distros do.

that's the idea with omap2plus_defconfig, at least. Last I talked with
Tony, the idea was "let's have a defconfig which distros can just use
and almost everything is built as a module".

> >> can use omap2plus_defconfig as a base. So, is or is not expected that
> >> people will use omap2plus_defconfig as a base for their own config?
> >
> > I never claimed that people should not use it as a *base*, rather it
> > should not be used to build a product's kernel/modules. Imagine you
> > shipping an embedded product based off of OMAP5 and you add CPSW, QSPI,
> > MUSB, a ton of touchscreen drivers you don't use, several PMIC drivers
> > built-in, etc. It's a waste of space and just bloats that product's
> > zImage.
> >
> 
> Got it, thanks for the clarification. I agree that omap2plus_defconfig
> is very bloated to be used for products as-is. I also have custom
> defconfig to test the OMAP boards I maintain which is basically
> omap2plus_defconfig + a merged config fragment (using merge_config.sh)
> that disables and enables needed options.

right, I used to that too. But right now I just have a set of
config-$board which I maintain locally. Slowly moving to
omap2plus_defconfig only as I move all my boards to NFS root.

> >> I think the problem is that there isn't an agreement about what is the
> >> purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7
> >> defconfigs (or at least is not well documented since I could not find
> >> it). So, IMHO this concern should be raised to the ARM SoC maintainers
> >> and there should be an agreement in the ARM community as a whole about
> >> how things should be configured on each defconfig, and all SoCs should
> >> follow the agreed rule.
> >
> > OTOH, the OMAP defconfig is part of the OMAP port and Tony will have the
> > final saying about it, right ?
> >
> 
> Sorry, I didn't mean that Tony doesn't have the last word for omap
> defconfig. My point was that it should be nice to get a consensus
> about this and specially document it to make life easier for everyone.

definitely, we need at least some documentation. No questions there.

> People posting defconfig changes will know what the rule is and we can
> avoid having these kind of discussions which I have had many times in
> the past when posting defconfig changes and I'm sure I will have more
> in the future again.

right.

> But I don't really mind tbh, I will keep maintaining my custom
> defconfigs anyways and post wnen I think that enabling a config option
> in a mainline defconfig makes sense and will do as a module or
> built-in depending of what the SoC maintainer tells me to use.

yeah, that's the downside, really. One maintainer prefers small zImage
with several modules (which I very much like the idea) while another
prefers giant zImage with virtually no modules :-)

cheers

Patch

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index c2c3a85..a1dc3ed 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -13,7 +13,6 @@  CONFIG_CGROUP_FREEZER=y
 CONFIG_CGROUP_DEVICE=y
 CONFIG_CPUSETS=y
 CONFIG_CGROUP_CPUACCT=y
-CONFIG_RESOURCE_COUNTERS=y
 CONFIG_MEMCG=y
 CONFIG_MEMCG_SWAP=y
 CONFIG_MEMCG_KMEM=y
@@ -68,7 +67,6 @@  CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
 CONFIG_CPU_FREQ_GOV_POWERSAVE=y
 CONFIG_CPU_FREQ_GOV_USERSPACE=y
 CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
-CONFIG_GENERIC_CPUFREQ_CPU0=y
 # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
 CONFIG_CPU_IDLE=y
 CONFIG_BINFMT_MISC=y
@@ -103,7 +101,7 @@  CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_DMA_CMA=y
 CONFIG_OMAP_OCP2SCP=y
-CONFIG_CONNECTOR=y
+CONFIG_CONNECTOR=m
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_BLOCK=y
@@ -122,14 +120,13 @@  CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=16384
 CONFIG_SENSORS_TSL2550=m
 CONFIG_BMP085_I2C=m
-CONFIG_SENSORS_LIS3_I2C=m
 CONFIG_SRAM=y
+CONFIG_SENSORS_LIS3_I2C=m
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_SCSI_SCAN_ASYNC=y
-CONFIG_ATA=y
-CONFIG_SATA_AHCI_PLATFORM=y
-CONFIG_MD=y
+CONFIG_ATA=m
+CONFIG_SATA_AHCI_PLATFORM=m
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_ARC is not set
 # CONFIG_NET_CADENCE is not set
@@ -154,8 +151,8 @@  CONFIG_TI_CPSW=y
 # CONFIG_NET_VENDOR_WIZNET is not set
 CONFIG_AT803X_PHY=y
 CONFIG_SMSC_PHY=y
-CONFIG_USB_USBNET=y
-CONFIG_USB_NET_SMSC95XX=y
+CONFIG_USB_USBNET=m
+CONFIG_USB_NET_SMSC95XX=m
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y
@@ -172,18 +169,22 @@  CONFIG_WLCORE_SDIO=m
 CONFIG_MWIFIEX=m
 CONFIG_MWIFIEX_SDIO=m
 CONFIG_MWIFIEX_USB=m
-CONFIG_INPUT_JOYDEV=y
-CONFIG_INPUT_EVDEV=y
-CONFIG_KEYBOARD_GPIO=y
+CONFIG_INPUT_JOYDEV=m
+CONFIG_INPUT_EVDEV=m
+CONFIG_KEYBOARD_ATKBD=m
+CONFIG_KEYBOARD_GPIO=m
 CONFIG_KEYBOARD_MATRIX=m
-CONFIG_KEYBOARD_TWL4030=y
+CONFIG_KEYBOARD_OMAP4=m
+CONFIG_KEYBOARD_TWL4030=m
+# CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ADS7846=m
 CONFIG_TOUCHSCREEN_EDT_FT5X06=m
 CONFIG_TOUCHSCREEN_TSC2005=m
 CONFIG_TOUCHSCREEN_TSC2007=m
 CONFIG_INPUT_MISC=y
-CONFIG_INPUT_TWL4030_PWRBUTTON=y
+CONFIG_INPUT_TWL4030_PWRBUTTON=m
+CONFIG_SERIO=m
 # CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
@@ -196,15 +197,16 @@  CONFIG_SERIAL_8250_RSA=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SERIAL_OMAP=y
 CONFIG_SERIAL_OMAP_CONSOLE=y
-CONFIG_HW_RANDOM=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_SPI=y
 CONFIG_SPI_OMAP24XX=y
+CONFIG_SPI_TI_QSPI=m
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
-CONFIG_GPIO_TWL4030=y
-CONFIG_W1=y
+CONFIG_GPIO_TWL4030=m
+CONFIG_W1=m
+CONFIG_HDQ_MASTER_OMAP=m
 CONFIG_BATTERY_BQ27x00=m
 CONFIG_CHARGER_ISP1704=m
 CONFIG_CHARGER_TWL4030=m
@@ -213,20 +215,21 @@  CONFIG_CHARGER_BQ24190=m
 CONFIG_CHARGER_BQ24735=m
 CONFIG_POWER_RESET=y
 CONFIG_POWER_AVS=y
+CONFIG_HWMON=m
 CONFIG_SENSORS_LM75=m
-CONFIG_THERMAL=y
+CONFIG_SENSORS_TMP102=m
+CONFIG_THERMAL=m
 CONFIG_THERMAL_GOV_FAIR_SHARE=y
 CONFIG_THERMAL_GOV_USER_SPACE=y
 CONFIG_CPU_THERMAL=y
-CONFIG_TI_SOC_THERMAL=y
+CONFIG_TI_SOC_THERMAL=m
 CONFIG_TI_THERMAL=y
 CONFIG_OMAP4_THERMAL=y
 CONFIG_OMAP5_THERMAL=y
 CONFIG_DRA752_THERMAL=y
 CONFIG_WATCHDOG=y
-CONFIG_OMAP_WATCHDOG=y
-CONFIG_TWL4030_WATCHDOG=y
-CONFIG_MFD_SYSCON=y
+CONFIG_OMAP_WATCHDOG=m
+CONFIG_TWL4030_WATCHDOG=m
 CONFIG_MFD_PALMAS=y
 CONFIG_MFD_TPS65217=y
 CONFIG_MFD_TPS65218=y
@@ -289,51 +292,77 @@  CONFIG_SND_OMAP_SOC=m
 CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
 CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
 CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
-CONFIG_USB=y
+CONFIG_HID_GENERIC=m
+CONFIG_USB_HIDDEV=y
+CONFIG_USB_KBD=m
+CONFIG_USB_MOUSE=m
+CONFIG_USB=m
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
-CONFIG_USB_MON=y
+CONFIG_USB_MON=m
 CONFIG_USB_XHCI_HCD=m
-CONFIG_USB_WDM=y
-CONFIG_USB_STORAGE=y
+CONFIG_USB_WDM=m
+CONFIG_USB_STORAGE=m
+CONFIG_USB_MUSB_HDRC=m
+CONFIG_USB_MUSB_OMAP2PLUS=m
+CONFIG_USB_MUSB_AM35X=m
+CONFIG_USB_MUSB_DSPS=m
 CONFIG_USB_DWC3=m
-CONFIG_USB_TEST=y
+CONFIG_USB_TEST=m
 CONFIG_AM335X_PHY_USB=y
-CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET=m
 CONFIG_USB_GADGET_DEBUG=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
 CONFIG_USB_GADGET_DEBUG_FS=y
+CONFIG_USB_CONFIGFS=m
+CONFIG_USB_CONFIGFS_SERIAL=y
+CONFIG_USB_CONFIGFS_ACM=y
+CONFIG_USB_CONFIGFS_OBEX=y
+CONFIG_USB_CONFIGFS_NCM=y
+CONFIG_USB_CONFIGFS_ECM=y
+CONFIG_USB_CONFIGFS_ECM_SUBSET=y
+CONFIG_USB_CONFIGFS_RNDIS=y
+CONFIG_USB_CONFIGFS_EEM=y
+CONFIG_USB_CONFIGFS_MASS_STORAGE=y
+CONFIG_USB_CONFIGFS_F_LB_SS=y
+CONFIG_USB_CONFIGFS_F_FS=y
+CONFIG_USB_CONFIGFS_F_UAC1=y
+CONFIG_USB_CONFIGFS_F_UAC2=y
+CONFIG_USB_CONFIGFS_F_MIDI=y
+CONFIG_USB_CONFIGFS_F_HID=y
 CONFIG_USB_ZERO=m
 CONFIG_MMC=y
 CONFIG_SDIO_UART=y
 CONFIG_MMC_OMAP=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NEW_LEDS=y
-CONFIG_LEDS_CLASS=y
-CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_CLASS=m
+CONFIG_LEDS_GPIO=m
 CONFIG_LEDS_TRIGGERS=y
-CONFIG_LEDS_TRIGGER_TIMER=y
-CONFIG_LEDS_TRIGGER_ONESHOT=y
-CONFIG_LEDS_TRIGGER_HEARTBEAT=y
-CONFIG_LEDS_TRIGGER_BACKLIGHT=y
+CONFIG_LEDS_TRIGGER_TIMER=m
+CONFIG_LEDS_TRIGGER_ONESHOT=m
+CONFIG_LEDS_TRIGGER_HEARTBEAT=m
+CONFIG_LEDS_TRIGGER_BACKLIGHT=m
 CONFIG_LEDS_TRIGGER_CPU=y
-CONFIG_LEDS_TRIGGER_GPIO=y
-CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_LEDS_TRIGGER_GPIO=m
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_TWL92330=y
-CONFIG_RTC_DRV_TWL4030=y
-CONFIG_RTC_DRV_OMAP=y
+CONFIG_RTC_DRV_TWL4030=m
+CONFIG_RTC_DRV_OMAP=m
 CONFIG_DMADEVICES=y
 CONFIG_TI_EDMA=y
 CONFIG_DMA_OMAP=y
-CONFIG_EXTCON=y
-CONFIG_EXTCON_PALMAS=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXTCON=m
+CONFIG_EXTCON_PALMAS=m
+CONFIG_TI_EMIF=m
 CONFIG_PWM=y
-CONFIG_PWM_TIECAP=y
-CONFIG_PWM_TIEHRPWM=y
-CONFIG_PWM_TWL=y
-CONFIG_PWM_TWL_LED=y
-CONFIG_OMAP_USB2=y
-CONFIG_TI_PIPE3=y
+CONFIG_PWM_TIECAP=m
+CONFIG_PWM_TIEHRPWM=m
+CONFIG_PWM_TWL=m
+CONFIG_PWM_TWL_LED=m
+CONFIG_OMAP_USB2=m
+CONFIG_TI_PIPE3=m
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set