[PATCH] ARM: multi_v7_defconfig: major refresh

[PATCH] ARM: multi_v7_defconfig: major refresh

[Olof Johansson]

This is a major refresh of the multi_v7_defconfig:

- Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
 * Enable big.LITTLE
 * MCPM
 * CYAPA touchpad
 * Samsung-related MTD/regulator/clk/pinmux drivers
 * Add some of the CrOS EC drivers
- Turn on TPM, HW_RANDOM
- OMAP_USB3 -> TI_PIPE3 option rename
- Enable MCPM/b.L for VEXPRESS
- Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
- CONFIG_LOGO, because penguins.

I took care to keep the new options that have been added for whose the
drivers are not yet in our for-next branch. This was pretty awkward so
we should sort out how to handle those better in the future.

Signed-off-by: Olof Johansson <olof@lixom.net>
---
 arch/arm/configs/multi_v7_defconfig |   74 +++++++++++++++++++++++++++--------
 1 file changed, 58 insertions(+), 16 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 16518a7..c7654cf 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -50,6 +50,7 @@ CONFIG_MACH_SPEAR1310=y
 CONFIG_MACH_SPEAR1340=y
 CONFIG_ARCH_STI=y
 CONFIG_ARCH_EXYNOS=y
+CONFIG_EXYNOS5420_MCPM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_SIRF=y
 CONFIG_ARCH_TEGRA=y
@@ -57,21 +58,23 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_TEGRA_EMC_SCALING_ENABLE=y
 CONFIG_ARCH_U8500=y
 CONFIG_MACH_HREFV60=y
 CONFIG_MACH_SNOWBALL=y
-CONFIG_MACH_UX500_DT=y
 CONFIG_ARCH_VEXPRESS=y
 CONFIG_ARCH_VEXPRESS_CA9X4=y
+CONFIG_ARCH_VEXPRESS_DCSCB=y
+CONFIG_ARCH_VEXPRESS_TC2_PM=y
 CONFIG_ARCH_WM8850=y
 CONFIG_ARCH_ZYNQ=y
-CONFIG_TRUSTED_FOUNDATIONS=y
 CONFIG_PCI=y
 CONFIG_PCI_MSI=y
 CONFIG_PCI_MVEBU=y
 CONFIG_PCI_TEGRA=y
 CONFIG_SMP=y
+CONFIG_BIG_LITTLE=y
+CONFIG_BL_SWITCHER=y
+CONFIG_BL_SWITCHER_DUMMY_IF=y
 CONFIG_NR_CPUS=8
 CONFIG_HIGHPTE=y
 CONFIG_CMA=y
@@ -81,8 +84,10 @@ CONFIG_KEXEC=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_STAT_DETAILS=y
 CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
+CONFIG_ARM_DT_BL_CPUFREQ=y
+CONFIG_ARM_VEXPRESS_SPC_CPUFREQ=y
 CONFIG_CPU_IDLE=y
-CONFIG_NEON=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -100,14 +105,12 @@ CONFIG_IPV6_MIP6=m
 CONFIG_IPV6_TUNNEL=m
 CONFIG_IPV6_MULTIPLE_TABLES=y
 CONFIG_CAN=y
-CONFIG_CAN_RAW=y
-CONFIG_CAN_BCM=y
-CONFIG_CAN_DEV=y
 CONFIG_CAN_MCP251X=y
 CONFIG_CFG80211=m
 CONFIG_MAC80211=m
 CONFIG_RFKILL=y
 CONFIG_RFKILL_INPUT=y
+CONFIG_RFKILL_REGULATOR=y
 CONFIG_RFKILL_GPIO=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
@@ -116,6 +119,7 @@ CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_OMAP_OCP2SCP=y
 CONFIG_MTD=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_ICS932S401=y
 CONFIG_APDS9802ALS=y
@@ -156,10 +160,11 @@ CONFIG_RT2800USB=m
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_TEGRA=y
-CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_ST_KEYSCAN=y
+CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_CROS_EC=y
 CONFIG_MOUSE_PS2_ELANTECH=y
+CONFIG_MOUSE_CYAPA=y
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_STMPE=y
 CONFIG_INPUT_MISC=y
@@ -190,8 +195,15 @@ CONFIG_SERIAL_FSL_LPUART=y
 CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
 CONFIG_SERIAL_ST_ASC=y
 CONFIG_SERIAL_ST_ASC_CONSOLE=y
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_OMAP=m
+CONFIG_HW_RANDOM_OMAP3_ROM=m
+CONFIG_HW_RANDOM_EXYNOS=m
+CONFIG_HW_RANDOM_MSM=m
+CONFIG_TCG_TPM=y
+CONFIG_TCG_TIS_I2C_INFINEON=y
 CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_MUX=y
+CONFIG_I2C_ARB_GPIO_CHALLENGE=y
 CONFIG_I2C_MUX_PCA954x=y
 CONFIG_I2C_MUX_PINCTRL=y
 CONFIG_I2C_CADENCE=y
@@ -199,12 +211,14 @@ CONFIG_I2C_DESIGNWARE_PLATFORM=y
 CONFIG_I2C_EXYNOS5=y
 CONFIG_I2C_MV64XXX=y
 CONFIG_I2C_SIRF=y
-CONFIG_I2C_TEGRA=y
 CONFIG_I2C_ST=y
+CONFIG_I2C_TEGRA=y
+CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SPI=y
 CONFIG_SPI_OMAP24XX=y
 CONFIG_SPI_ORION=y
 CONFIG_SPI_PL022=y
+CONFIG_SPI_S3C64XX=y
 CONFIG_SPI_SIRF=y
 CONFIG_SPI_SUN4I=y
 CONFIG_SPI_SUN6I=y
@@ -214,7 +228,6 @@ CONFIG_SPI_TEGRA20_SLINK=y
 CONFIG_PINCTRL_AS3722=y
 CONFIG_PINCTRL_PALMAS=y
 CONFIG_GPIO_SYSFS=y
-CONFIG_GPIO_GENERIC_PLATFORM=y
 CONFIG_GPIO_DWAPB=y
 CONFIG_GPIO_PCA953X=y
 CONFIG_GPIO_PCA953X_IRQ=y
@@ -233,14 +246,20 @@ CONFIG_THERMAL=y
 CONFIG_ARMADA_THERMAL=y
 CONFIG_ST_THERMAL_SYSCFG=y
 CONFIG_ST_THERMAL_MEMMAP=y
+CONFIG_EXYNOS_THERMAL=y
+CONFIG_EXYNOS_THERMAL_CORE=y
 CONFIG_WATCHDOG=y
+CONFIG_S3C2410_WATCHDOG=y
 CONFIG_ORION_WATCHDOG=y
 CONFIG_SUNXI_WATCHDOG=y
 CONFIG_MFD_AS3722=y
 CONFIG_MFD_BCM590XX=y
 CONFIG_MFD_CROS_EC=y
+CONFIG_MFD_CROS_EC_I2C=y
 CONFIG_MFD_CROS_EC_SPI=y
+CONFIG_MFD_MAX77686=y
 CONFIG_MFD_MAX8907=y
+CONFIG_MFD_MAX8997=y
 CONFIG_MFD_SEC_CORE=y
 CONFIG_MFD_STMPE=y
 CONFIG_MFD_PALMAS=y
@@ -253,6 +272,8 @@ CONFIG_REGULATOR_AS3722=y
 CONFIG_REGULATOR_BCM590XX=y
 CONFIG_REGULATOR_GPIO=y
 CONFIG_REGULATOR_MAX8907=y
+CONFIG_REGULATOR_MAX8997=y
+CONFIG_REGULATOR_MAX77686=y
 CONFIG_REGULATOR_PALMAS=y
 CONFIG_REGULATOR_S2MPS11=y
 CONFIG_REGULATOR_S5M8767=y
@@ -274,13 +295,17 @@ CONFIG_DRM_PANEL_SIMPLE=y
 CONFIG_FB_ARMCLCD=y
 CONFIG_FB_WM8505=y
 CONFIG_FB_SIMPLE=y
+CONFIG_EXYNOS_VIDEO=y
+CONFIG_EXYNOS_MIPI_DSI=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
-CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_PWM=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_LOGO=y
 CONFIG_SOUND=y
 CONFIG_SND=y
 CONFIG_SND_SOC=y
+CONFIG_SND_SOC_SAMSUNG=y
+CONFIG_SND_SOC_SNOW=y
 CONFIG_SND_SOC_TEGRA=y
 CONFIG_SND_SOC_TEGRA_RT5640=y
 CONFIG_SND_SOC_TEGRA_WM8753=y
@@ -293,15 +318,19 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_MVEBU=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_TEGRA=y
+CONFIG_USB_EHCI_EXYNOS=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_ISP1760_HCD=y
 CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_EXYNOS=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_DWC3=y
 CONFIG_USB_CHIPIDEA=y
 CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_HSIC_USB3503=y
 CONFIG_AB8500_USB=y
-CONFIG_OMAP_USB3=y
+CONFIG_TI_PIPE3=y
 CONFIG_SAMSUNG_USB2PHY=y
 CONFIG_SAMSUNG_USB3PHY=y
 CONFIG_USB_GPIO_VBUS=y
@@ -316,18 +345,19 @@ CONFIG_MMC_SDHCI_OF_ARASAN=y
 CONFIG_MMC_SDHCI_ESDHC_IMX=y
 CONFIG_MMC_SDHCI_DOVE=y
 CONFIG_MMC_SDHCI_TEGRA=y
+CONFIG_MMC_SDHCI_S3C=y
 CONFIG_MMC_SDHCI_PXAV3=y
 CONFIG_MMC_SDHCI_SPEAR=y
-CONFIG_MMC_SDHCI_S3C=y
 CONFIG_MMC_SDHCI_S3C_DMA=y
 CONFIG_MMC_SDHCI_BCM_KONA=y
 CONFIG_MMC_SDHCI_ST=y
 CONFIG_MMC_OMAP=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_MMC_MVSDIO=y
-CONFIG_MMC_SUNXI=y
 CONFIG_MMC_DW=y
+CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_EXYNOS=y
+CONFIG_MMC_SUNXI=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_PWM=y
@@ -339,11 +369,14 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_AS3722=y
 CONFIG_RTC_DRV_DS1307=y
 CONFIG_RTC_DRV_MAX8907=y
+CONFIG_RTC_DRV_MAX77686=y
 CONFIG_RTC_DRV_PALMAS=y
 CONFIG_RTC_DRV_TWL4030=y
 CONFIG_RTC_DRV_TPS6586X=y
 CONFIG_RTC_DRV_TPS65910=y
 CONFIG_RTC_DRV_EM3027=y
+CONFIG_RTC_DRV_S5M=y
+CONFIG_RTC_DRV_S3C=y
 CONFIG_RTC_DRV_PL031=y
 CONFIG_RTC_DRV_VT8500=y
 CONFIG_RTC_DRV_SUNXI=y
@@ -369,21 +402,31 @@ CONFIG_KEYBOARD_NVEC=y
 CONFIG_SERIO_NVEC_PS2=y
 CONFIG_NVEC_POWER=y
 CONFIG_QCOM_GSBI=y
+CONFIG_COMMON_CLK_MAX77686=y
 CONFIG_COMMON_CLK_QCOM=y
 CONFIG_MSM_GCC_8660=y
 CONFIG_MSM_MMCC_8960=y
 CONFIG_MSM_MMCC_8974=y
 CONFIG_TEGRA_IOMMU_GART=y
 CONFIG_TEGRA_IOMMU_SMMU=y
+CONFIG_EXYNOS_IOMMU=y
 CONFIG_MEMORY=y
 CONFIG_IIO=y
+CONFIG_EXYNOS_ADC=y
 CONFIG_AK8975=y
 CONFIG_PWM=y
+CONFIG_PWM_SAMSUNG=y
 CONFIG_PWM_TEGRA=y
 CONFIG_PWM_VT8500=y
 CONFIG_OMAP_USB2=y
 CONFIG_PHY_MIPHY365X=y
+CONFIG_PHY_EXYNOS5250_SATA=y
 CONFIG_PHY_SUN4I_USB=y
+CONFIG_PHY_SAMSUNG_USB2=y
+CONFIG_PHY_EXYNOS4210_USB2=y
+CONFIG_PHY_EXYNOS4X12_USB2=y
+CONFIG_PHY_EXYNOS5250_USB2=y
+CONFIG_PHY_EXYNOS5_USBDRD=y
 CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
@@ -398,4 +441,3 @@ CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_LOCKUP_DETECTOR=y
-CONFIG_CRYPTO_DEV_TEGRA_AES=y
-- 
1.7.10.4

[PATCH] ARM: multi_v7_defconfig: major refresh

[Arnd Bergmann]

On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
> This is a major refresh of the multi_v7_defconfig:
> 
> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>  * Enable big.LITTLE
>  * MCPM
>  * CYAPA touchpad
>  * Samsung-related MTD/regulator/clk/pinmux drivers
>  * Add some of the CrOS EC drivers
> - Turn on TPM, HW_RANDOM
> - OMAP_USB3 -> TI_PIPE3 option rename
> - Enable MCPM/b.L for VEXPRESS
> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
> - CONFIG_LOGO, because penguins.
> 
> I took care to keep the new options that have been added for whose the
> drivers are not yet in our for-next branch. This was pretty awkward so
> we should sort out how to handle those better in the future.

Since you've already done all those, how about enabling THUMB2_KERNEL?
For the multi_v7_defconfig, it should actually give some benefits,
since it's rather large, and it would be good to have some more testing
with this option enabled.

I guess the first step would be to enable it and just see if your
boot farm survives the change.

	Arnd

[PATCH] ARM: multi_v7_defconfig: major refresh

[Olof Johansson]

On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
>> This is a major refresh of the multi_v7_defconfig:
>>
>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>>  * Enable big.LITTLE
>>  * MCPM
>>  * CYAPA touchpad
>>  * Samsung-related MTD/regulator/clk/pinmux drivers
>>  * Add some of the CrOS EC drivers
>> - Turn on TPM, HW_RANDOM
>> - OMAP_USB3 -> TI_PIPE3 option rename
>> - Enable MCPM/b.L for VEXPRESS
>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
>> - CONFIG_LOGO, because penguins.
>>
>> I took care to keep the new options that have been added for whose the
>> drivers are not yet in our for-next branch. This was pretty awkward so
>> we should sort out how to handle those better in the future.
>
> Since you've already done all those, how about enabling THUMB2_KERNEL?
> For the multi_v7_defconfig, it should actually give some benefits,
> since it's rather large, and it would be good to have some more testing
> with this option enabled.
>
> I guess the first step would be to enable it and just see if your
> boot farm survives the change.

Good point, I'll definitely give that a go once the current issues are resolved.

Which are: These changes make 5250-based machines (snow and arndale)
break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
might be missing pinctrl setups for it?

Tushar, Kukjin, any chance you can investigate from your end? I'd like
to get this change in since it allows for better multiplatform
coverage, but the Exynos breakage must be fixed...


-Olof

[PATCH] ARM: multi_v7_defconfig: major refresh

[Pawel Moll]

On Tue, 2014-07-22 at 19:01 +0100, Olof Johansson wrote:
> This is a major refresh of the multi_v7_defconfig:
> 
> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>  * Enable big.LITTLE
>  * MCPM
>  * CYAPA touchpad
>  * Samsung-related MTD/regulator/clk/pinmux drivers
>  * Add some of the CrOS EC drivers
> - Turn on TPM, HW_RANDOM
> - OMAP_USB3 -> TI_PIPE3 option rename
> - Enable MCPM/b.L for VEXPRESS
> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
> - CONFIG_LOGO, because penguins.
> 
> I took care to keep the new options that have been added for whose the
> drivers are not yet in our for-next branch. This was pretty awkward so
> we should sort out how to handle those better in the future.
> 
> Signed-off-by: Olof Johansson <olof@lixom.net>

It doesn't apply cleanly on 3.16-rc6, but after manual merge VE still
boots :-) (for what it's worth)

Pawe?

[PATCH] ARM: multi_v7_defconfig: major refresh

[Tushar Behera]

On Wed, Jul 23, 2014 at 1:58 AM, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
>>> This is a major refresh of the multi_v7_defconfig:
>>>
>>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>>>  * Enable big.LITTLE
>>>  * MCPM
>>>  * CYAPA touchpad
>>>  * Samsung-related MTD/regulator/clk/pinmux drivers
>>>  * Add some of the CrOS EC drivers
>>> - Turn on TPM, HW_RANDOM
>>> - OMAP_USB3 -> TI_PIPE3 option rename
>>> - Enable MCPM/b.L for VEXPRESS
>>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
>>> - CONFIG_LOGO, because penguins.
>>>
>>> I took care to keep the new options that have been added for whose the
>>> drivers are not yet in our for-next branch. This was pretty awkward so
>>> we should sort out how to handle those better in the future.
>>
>> Since you've already done all those, how about enabling THUMB2_KERNEL?
>> For the multi_v7_defconfig, it should actually give some benefits,
>> since it's rather large, and it would be good to have some more testing
>> with this option enabled.
>>
>> I guess the first step would be to enable it and just see if your
>> boot farm survives the change.
>
> Good point, I'll definitely give that a go once the current issues are resolved.
>
> Which are: These changes make 5250-based machines (snow and arndale)
> break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
> might be missing pinctrl setups for it?
>
> Tushar, Kukjin, any chance you can investigate from your end? I'd like
> to get this change in since it allows for better multiplatform
> coverage, but the Exynos breakage must be fixed...
>
>
> -Olof

+ Sachin (spk.linux at gmail.com)

We will have to cross-check with exynos_defconfig about the missing
components, if any. We will update after checking.

-- 
Tushar Behera

[PATCH] ARM: multi_v7_defconfig: major refresh

[Sachin Kamat]

On Thu, Jul 31, 2014 at 11:37 AM, Tushar Behera <trblinux@gmail.com> wrote:
> On Wed, Jul 23, 2014 at 1:58 AM, Olof Johansson <olof@lixom.net> wrote:
>> On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
>>>> This is a major refresh of the multi_v7_defconfig:
>>>>
>>>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>>>>  * Enable big.LITTLE
>>>>  * MCPM
>>>>  * CYAPA touchpad
>>>>  * Samsung-related MTD/regulator/clk/pinmux drivers
>>>>  * Add some of the CrOS EC drivers
>>>> - Turn on TPM, HW_RANDOM
>>>> - OMAP_USB3 -> TI_PIPE3 option rename
>>>> - Enable MCPM/b.L for VEXPRESS
>>>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
>>>> - CONFIG_LOGO, because penguins.
>>>>
>>>> I took care to keep the new options that have been added for whose the
>>>> drivers are not yet in our for-next branch. This was pretty awkward so
>>>> we should sort out how to handle those better in the future.
>>>
>>> Since you've already done all those, how about enabling THUMB2_KERNEL?
>>> For the multi_v7_defconfig, it should actually give some benefits,
>>> since it's rather large, and it would be good to have some more testing
>>> with this option enabled.
>>>
>>> I guess the first step would be to enable it and just see if your
>>> boot farm survives the change.
>>
>> Good point, I'll definitely give that a go once the current issues are resolved.
>>
>> Which are: These changes make 5250-based machines (snow and arndale)
>> break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
>> might be missing pinctrl setups for it?

i2c timeout issue should have been fixed with the following patch:
i2c: i2c-s3c2410: Drop class based scanning to improve bootup time
(commit id: 6031d3dfc73b49bede540872e51a70ee0b6786d4) which is
available on Wolfram's I2C tree (should be part of linux-next too). Also
I do not see I2C_S3C2410 enabled in the config.
I do not have access to h/w today. I can verify and check tomorrow or
somebody could test it in the meantime with the above suggestions?

-- 
Regards,
Sachin.

[PATCH] ARM: multi_v7_defconfig: major refresh

[Sachin Kamat]

On Thu, Jul 31, 2014 at 11:56 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
> On Thu, Jul 31, 2014 at 11:37 AM, Tushar Behera <trblinux@gmail.com> wrote:
>> On Wed, Jul 23, 2014 at 1:58 AM, Olof Johansson <olof@lixom.net> wrote:
>>> On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
>>>>> This is a major refresh of the multi_v7_defconfig:
>>>>>
>>>>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>>>>>  * Enable big.LITTLE
>>>>>  * MCPM
>>>>>  * CYAPA touchpad
>>>>>  * Samsung-related MTD/regulator/clk/pinmux drivers
>>>>>  * Add some of the CrOS EC drivers
>>>>> - Turn on TPM, HW_RANDOM
>>>>> - OMAP_USB3 -> TI_PIPE3 option rename
>>>>> - Enable MCPM/b.L for VEXPRESS
>>>>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
>>>>> - CONFIG_LOGO, because penguins.
>>>>>
>>>>> I took care to keep the new options that have been added for whose the
>>>>> drivers are not yet in our for-next branch. This was pretty awkward so
>>>>> we should sort out how to handle those better in the future.
>>>>
>>>> Since you've already done all those, how about enabling THUMB2_KERNEL?
>>>> For the multi_v7_defconfig, it should actually give some benefits,
>>>> since it's rather large, and it would be good to have some more testing
>>>> with this option enabled.
>>>>
>>>> I guess the first step would be to enable it and just see if your
>>>> boot farm survives the change.
>>>
>>> Good point, I'll definitely give that a go once the current issues are resolved.
>>>
>>> Which are: These changes make 5250-based machines (snow and arndale)
>>> break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
>>> might be missing pinctrl setups for it?
>
> i2c timeout issue should have been fixed with the following patch:
> i2c: i2c-s3c2410: Drop class based scanning to improve bootup time
> (commit id: 6031d3dfc73b49bede540872e51a70ee0b6786d4) which is
> available on Wolfram's I2C tree (should be part of linux-next too). Also
> I do not see I2C_S3C2410 enabled in the config.
> I do not have access to h/w today. I can verify and check tomorrow or
> somebody could test it in the meantime with the above suggestions?

Olof,
Tested your multi_v7_defconfig patch on top of latest linux-next (20140731).
I did not see any aforementioned i2c issues on 5250 based Snow board. It
booted fine. However on 5250 based Arndale board, the boot stops at
the following:

[    1.951863] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.956937] ehci-pci: EHCI PCI platform driver
[    1.961392] ehci-exynos: EHCI EXYNOS driver
[    1.965698] exynos-ehci 12110000.usb: EHCI Host Controller
[    1.971007] exynos-ehci 12110000.usb: new USB bus registered,
assigned bus number 1
[    1.981593] exynos-ehci 12110000.usb: can't setup: -110
[    1.985361] exynos-ehci 12110000.usb: USB bus 1 deregistered
[    1.991001] exynos-ehci 12110000.usb: Failed to add USB HCD
[    1.996569] exynos-ehci: probe of 12110000.usb failed with error -110
[    2.003041] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.009149] ohci-exynos: OHCI EXYNOS driver
[    2.013457] exynos-ohci 12120000.usb: USB Host Controller
[    2.018702] exynos-ohci 12120000.usb: new USB bus registered,
assigned bus number 1

Boots well with exynos_defconfig though. Probably some conflict with
other config options?
I couldn't find out as I am busy with some other activity.

-- 
Regards,
Sachin.

[PATCH] ARM: multi_v7_defconfig: major refresh

[Sudeep Holla]

On 22/07/14 19:01, Olof Johansson wrote:
> This is a major refresh of the multi_v7_defconfig:
>
> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>   * Enable big.LITTLE
>   * MCPM
>   * CYAPA touchpad
>   * Samsung-related MTD/regulator/clk/pinmux drivers
>   * Add some of the CrOS EC drivers
> - Turn on TPM, HW_RANDOM
> - OMAP_USB3 -> TI_PIPE3 option rename
> - Enable MCPM/b.L for VEXPRESS
> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
> - CONFIG_LOGO, because penguins.
>
> I took care to keep the new options that have been added for whose the
> drivers are not yet in our for-next branch. This was pretty awkward so
> we should sort out how to handle those better in the future.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
>   arch/arm/configs/multi_v7_defconfig |   74 +++++++++++++++++++++++++++--------
>   1 file changed, 58 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 16518a7..c7654cf 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -50,6 +50,7 @@ CONFIG_MACH_SPEAR1310=y
>   CONFIG_MACH_SPEAR1340=y
>   CONFIG_ARCH_STI=y
>   CONFIG_ARCH_EXYNOS=y
> +CONFIG_EXYNOS5420_MCPM=y
>   CONFIG_ARCH_SUNXI=y
>   CONFIG_ARCH_SIRF=y
>   CONFIG_ARCH_TEGRA=y
> @@ -57,21 +58,23 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
>   CONFIG_ARCH_TEGRA_3x_SOC=y
>   CONFIG_ARCH_TEGRA_114_SOC=y
>   CONFIG_ARCH_TEGRA_124_SOC=y
> -CONFIG_TEGRA_EMC_SCALING_ENABLE=y
>   CONFIG_ARCH_U8500=y
>   CONFIG_MACH_HREFV60=y
>   CONFIG_MACH_SNOWBALL=y
> -CONFIG_MACH_UX500_DT=y
>   CONFIG_ARCH_VEXPRESS=y
>   CONFIG_ARCH_VEXPRESS_CA9X4=y
> +CONFIG_ARCH_VEXPRESS_DCSCB=y
> +CONFIG_ARCH_VEXPRESS_TC2_PM=y
>   CONFIG_ARCH_WM8850=y
>   CONFIG_ARCH_ZYNQ=y
> -CONFIG_TRUSTED_FOUNDATIONS=y
>   CONFIG_PCI=y
>   CONFIG_PCI_MSI=y
>   CONFIG_PCI_MVEBU=y
>   CONFIG_PCI_TEGRA=y
>   CONFIG_SMP=y
> +CONFIG_BIG_LITTLE=y
> +CONFIG_BL_SWITCHER=y

IIUC, this will enable switcher code by default. I am not sure if this
is intentional ? E.g.: After this I can have only 2 active cpus instead
of 5 on my Vexpress TC2 platform.

IMO we can keep this enabled by default in the build, but disabled
by default on boot. One way to achieve this:
(There's sysfs to re-enable it runtime)

-->8
diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index 490f3dced749..f4c36e70166a 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct 
notifier_block *nfb,
         return NOTIFY_DONE;
  }

-static bool no_bL_switcher;
+static bool no_bL_switcher = true;
  core_param(no_bL_switcher, no_bL_switcher, bool, 0644);

  static int __init bL_switcher_init(void)

---

> +CONFIG_BL_SWITCHER_DUMMY_IF=y

This was added only for debugging purposes, again not sure if you want
this enabled by default. Ideally it should be triggered by CPUFreq.

Regards,
Sudeep

[PATCH] ARM: multi_v7_defconfig: major refresh

[Jon Medhurst (Tixy)]

On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
> 
> On 22/07/14 19:01, Olof Johansson wrote:
> > This is a major refresh of the multi_v7_defconfig:
> >
> > - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
> >   * Enable big.LITTLE
> >   * MCPM
> [...]

> > +CONFIG_BIG_LITTLE=y
> > +CONFIG_BL_SWITCHER=y
> 
> IIUC, this will enable switcher code by default. I am not sure if this
> is intentional ? E.g.: After this I can have only 2 active cpus instead
> of 5 on my Vexpress TC2 platform.
> 
> IMO we can keep this enabled by default in the build, but disabled
> by default on boot.

TC2 has a big.LITTLE processor and the switcher is the only mainlined
way of making any kind of proper use of big.LITTLE, so why not have it
enabled by default?

>  One way to achieve this:
> (There's sysfs to re-enable it runtime)

The opposite is also true, if you don't want the switcher enabled you
can disable it by the same method after boot ;-)

> -->8
> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> index 490f3dced749..f4c36e70166a 100644
> --- a/arch/arm/common/bL_switcher.c
> +++ b/arch/arm/common/bL_switcher.c
> @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct 
> notifier_block *nfb,
>          return NOTIFY_DONE;
>   }
> 
> -static bool no_bL_switcher;
> +static bool no_bL_switcher = true;

This changes the default for everyone, which I guess is fair enough if
there is a good reason, but I'm not sure there is.

-- 
Tixy

[PATCH] ARM: multi_v7_defconfig: major refresh

[Olof Johansson]

On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
>>
>> On 22/07/14 19:01, Olof Johansson wrote:
>> > This is a major refresh of the multi_v7_defconfig:
>> >
>> > - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>> >   * Enable big.LITTLE
>> >   * MCPM
>> [...]
>
>> > +CONFIG_BIG_LITTLE=y
>> > +CONFIG_BL_SWITCHER=y
>>
>> IIUC, this will enable switcher code by default. I am not sure if this
>> is intentional ? E.g.: After this I can have only 2 active cpus instead
>> of 5 on my Vexpress TC2 platform.
>>
>> IMO we can keep this enabled by default in the build, but disabled
>> by default on boot.
>
> TC2 has a big.LITTLE processor and the switcher is the only mainlined
> way of making any kind of proper use of big.LITTLE, so why not have it
> enabled by default?

+1.

>
>>  One way to achieve this:
>> (There's sysfs to re-enable it runtime)
>
> The opposite is also true, if you don't want the switcher enabled you
> can disable it by the same method after boot ;-)
>
>> -->8
>> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
>> index 490f3dced749..f4c36e70166a 100644
>> --- a/arch/arm/common/bL_switcher.c
>> +++ b/arch/arm/common/bL_switcher.c
>> @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
>> notifier_block *nfb,
>>          return NOTIFY_DONE;
>>   }
>>
>> -static bool no_bL_switcher;
>> +static bool no_bL_switcher = true;
>
> This changes the default for everyone, which I guess is fair enough if
> there is a good reason, but I'm not sure there is.

No, I don't think there is.


-Olof

[PATCH] ARM: multi_v7_defconfig: major refresh

[Pawel Moll]

On Fri, 2014-08-01 at 12:01 +0100, Jon Medhurst (Tixy) wrote:
> > -->8
> > diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> > index 490f3dced749..f4c36e70166a 100644
> > --- a/arch/arm/common/bL_switcher.c
> > +++ b/arch/arm/common/bL_switcher.c
> > @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct 
> > notifier_block *nfb,
> >          return NOTIFY_DONE;
> >   }
> > 
> > -static bool no_bL_switcher;
> > +static bool no_bL_switcher = true;
> 
> This changes the default for everyone, which I guess is fair enough if
> there is a good reason, but I'm not sure there is.

I would vote for this change and argue that b.L switcher is "strange
enough" (ie. I know I've got 5 processors, so why do I see only 2?)
_not_ to have it enabled by default. I'd hope that a user looking for
this functionality will know how to turn it on.

Pawe?

[PATCH] ARM: multi_v7_defconfig: major refresh

[Sudeep Holla]

On 01/08/14 12:03, Olof Johansson wrote:
> On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
>> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
>>>
>>> On 22/07/14 19:01, Olof Johansson wrote:
>>>> This is a major refresh of the multi_v7_defconfig:
>>>>
>>>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>>>>    * Enable big.LITTLE
>>>>    * MCPM
>>> [...]
>>
>>>> +CONFIG_BIG_LITTLE=y
>>>> +CONFIG_BL_SWITCHER=y
>>>
>>> IIUC, this will enable switcher code by default. I am not sure if this
>>> is intentional ? E.g.: After this I can have only 2 active cpus instead
>>> of 5 on my Vexpress TC2 platform.
>>>
>>> IMO we can keep this enabled by default in the build, but disabled
>>> by default on boot.
>>
>> TC2 has a big.LITTLE processor and the switcher is the only mainlined
>> way of making any kind of proper use of big.LITTLE, so why not have it
>> enabled by default?
>
> +1.
>
>>
>>>   One way to achieve this:
>>> (There's sysfs to re-enable it runtime)
>>
>> The opposite is also true, if you don't want the switcher enabled you
>> can disable it by the same method after boot ;-)
>>
>>> -->8
>>> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
>>> index 490f3dced749..f4c36e70166a 100644
>>> --- a/arch/arm/common/bL_switcher.c
>>> +++ b/arch/arm/common/bL_switcher.c
>>> @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
>>> notifier_block *nfb,
>>>           return NOTIFY_DONE;
>>>    }
>>>
>>> -static bool no_bL_switcher;
>>> +static bool no_bL_switcher = true;
>>
>> This changes the default for everyone, which I guess is fair enough if
>> there is a good reason, but I'm not sure there is.
>
> No, I don't think there is.
>

It's just that people using TC2 will suddenly see 3 of the 5 CPUs missing.

Regards,
Sudeep

[PATCH] ARM: multi_v7_defconfig: major refresh

[Jon Medhurst (Tixy)]

On Fri, 2014-08-01 at 12:12 +0100, Sudeep Holla wrote:
> 
> On 01/08/14 12:03, Olof Johansson wrote:
> > On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
> >> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
> >>>
> >>> On 22/07/14 19:01, Olof Johansson wrote:
> >>>> This is a major refresh of the multi_v7_defconfig:
> >>>>
> >>>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
> >>>>    * Enable big.LITTLE
> >>>>    * MCPM
> >>> [...]
> >>
> >>>> +CONFIG_BIG_LITTLE=y
> >>>> +CONFIG_BL_SWITCHER=y
> >>>
> >>> IIUC, this will enable switcher code by default. I am not sure if this
> >>> is intentional ? E.g.: After this I can have only 2 active cpus instead
> >>> of 5 on my Vexpress TC2 platform.
> >>>
> >>> IMO we can keep this enabled by default in the build, but disabled
> >>> by default on boot.
> >>
> >> TC2 has a big.LITTLE processor and the switcher is the only mainlined
> >> way of making any kind of proper use of big.LITTLE, so why not have it
> >> enabled by default?
> >
> > +1.
> >
> >>
> >>>   One way to achieve this:
> >>> (There's sysfs to re-enable it runtime)
> >>
> >> The opposite is also true, if you don't want the switcher enabled you
> >> can disable it by the same method after boot ;-)
> >>
> >>> -->8
> >>> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> >>> index 490f3dced749..f4c36e70166a 100644
> >>> --- a/arch/arm/common/bL_switcher.c
> >>> +++ b/arch/arm/common/bL_switcher.c
> >>> @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
> >>> notifier_block *nfb,
> >>>           return NOTIFY_DONE;
> >>>    }
> >>>
> >>> -static bool no_bL_switcher;
> >>> +static bool no_bL_switcher = true;
> >>
> >> This changes the default for everyone, which I guess is fair enough if
> >> there is a good reason, but I'm not sure there is.
> >
> > No, I don't think there is.
> >
> 
> It's just that people using TC2 will suddenly see 3 of the 5 CPUs missing.

Yes, if they we're previously using multi_v7_defconfig (do people
working specifically with TC2's use that?)

Conversely, with the change in default proposed above, anyone with their
own configs enabling the switcher will suddenly see the number of CPUs
go from 2 to 5. We also have the situation where we have a config
option, which when enabled, doesn't actually do anything unless the user
also changes boot arguments or takes measures to enable it after boot.
Which seems the wrong way for things to work to me.

I believe that if we don't want the switcher enabled in kernels built
with multi_v7_defconfig, then it should be done by not adding the config
option to multi_v7_defconfig in the first place.

-- 
Tixy

[PATCH] ARM: multi_v7_defconfig: major refresh

[Bartlomiej Zolnierkiewicz]

Hi,

On Friday, August 01, 2014 12:14:41 PM Sachin Kamat wrote:
> On Thu, Jul 31, 2014 at 11:56 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
> > On Thu, Jul 31, 2014 at 11:37 AM, Tushar Behera <trblinux@gmail.com> wrote:
> >> On Wed, Jul 23, 2014 at 1:58 AM, Olof Johansson <olof@lixom.net> wrote:
> >>> On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >>>> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
> >>>>> This is a major refresh of the multi_v7_defconfig:
> >>>>>
> >>>>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
> >>>>>  * Enable big.LITTLE
> >>>>>  * MCPM
> >>>>>  * CYAPA touchpad
> >>>>>  * Samsung-related MTD/regulator/clk/pinmux drivers
> >>>>>  * Add some of the CrOS EC drivers
> >>>>> - Turn on TPM, HW_RANDOM
> >>>>> - OMAP_USB3 -> TI_PIPE3 option rename
> >>>>> - Enable MCPM/b.L for VEXPRESS
> >>>>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
> >>>>> - CONFIG_LOGO, because penguins.
> >>>>>
> >>>>> I took care to keep the new options that have been added for whose the
> >>>>> drivers are not yet in our for-next branch. This was pretty awkward so
> >>>>> we should sort out how to handle those better in the future.
> >>>>
> >>>> Since you've already done all those, how about enabling THUMB2_KERNEL?
> >>>> For the multi_v7_defconfig, it should actually give some benefits,
> >>>> since it's rather large, and it would be good to have some more testing
> >>>> with this option enabled.
> >>>>
> >>>> I guess the first step would be to enable it and just see if your
> >>>> boot farm survives the change.
> >>>
> >>> Good point, I'll definitely give that a go once the current issues are resolved.
> >>>
> >>> Which are: These changes make 5250-based machines (snow and arndale)
> >>> break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
> >>> might be missing pinctrl setups for it?
> >
> > i2c timeout issue should have been fixed with the following patch:
> > i2c: i2c-s3c2410: Drop class based scanning to improve bootup time
> > (commit id: 6031d3dfc73b49bede540872e51a70ee0b6786d4) which is
> > available on Wolfram's I2C tree (should be part of linux-next too). Also
> > I do not see I2C_S3C2410 enabled in the config.
> > I do not have access to h/w today. I can verify and check tomorrow or
> > somebody could test it in the meantime with the above suggestions?
> 
> Olof,
> Tested your multi_v7_defconfig patch on top of latest linux-next (20140731).
> I did not see any aforementioned i2c issues on 5250 based Snow board. It
> booted fine. However on 5250 based Arndale board, the boot stops at
> the following:
> 
> [    1.951863] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    1.956937] ehci-pci: EHCI PCI platform driver
> [    1.961392] ehci-exynos: EHCI EXYNOS driver
> [    1.965698] exynos-ehci 12110000.usb: EHCI Host Controller
> [    1.971007] exynos-ehci 12110000.usb: new USB bus registered,
> assigned bus number 1
> [    1.981593] exynos-ehci 12110000.usb: can't setup: -110
> [    1.985361] exynos-ehci 12110000.usb: USB bus 1 deregistered
> [    1.991001] exynos-ehci 12110000.usb: Failed to add USB HCD
> [    1.996569] exynos-ehci: probe of 12110000.usb failed with error -110
> [    2.003041] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    2.009149] ohci-exynos: OHCI EXYNOS driver
> [    2.013457] exynos-ohci 12120000.usb: USB Host Controller
> [    2.018702] exynos-ohci 12120000.usb: new USB bus registered,
> assigned bus number 1
> 
> Boots well with exynos_defconfig though. Probably some conflict with
> other config options?
> 
> I couldn't find out as I am busy with some other activity.

Olof, could you please remember to update exynos_defconfig when updating
multi_v7_defconfig with Exynos related changes?  These two configs have
been getting slightly out-of-sync since introduction of multiplatform
support for Exynos arch.  It causes waste of development/testing efforts.

Kukjin, it would really be great if all Exynos users run on a common
configuration so the development/testing is done more efficiently.  Could
you please reconsider removal of exynos_defconfig?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

[PATCH] ARM: multi_v7_defconfig: major refresh

[Sudeep Holla]

On 01/08/14 12:28, Jon Medhurst (Tixy) wrote:
> On Fri, 2014-08-01 at 12:12 +0100, Sudeep Holla wrote:
>>
>> On 01/08/14 12:03, Olof Johansson wrote:
>>> On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
>>>> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:

[...]

>>>>
>>>>>    One way to achieve this:
>>>>> (There's sysfs to re-enable it runtime)
>>>>
>>>> The opposite is also true, if you don't want the switcher enabled you
>>>> can disable it by the same method after boot ;-)
>>>>
>>>>> -->8
>>>>> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
>>>>> index 490f3dced749..f4c36e70166a 100644
>>>>> --- a/arch/arm/common/bL_switcher.c
>>>>> +++ b/arch/arm/common/bL_switcher.c
>>>>> @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
>>>>> notifier_block *nfb,
>>>>>            return NOTIFY_DONE;
>>>>>     }
>>>>>
>>>>> -static bool no_bL_switcher;
>>>>> +static bool no_bL_switcher = true;
>>>>
>>>> This changes the default for everyone, which I guess is fair enough if
>>>> there is a good reason, but I'm not sure there is.
>>>
>>> No, I don't think there is.
>>>
>>
>> It's just that people using TC2 will suddenly see 3 of the 5 CPUs missing.
>
> Yes, if they we're previously using multi_v7_defconfig (do people
> working specifically with TC2's use that?)
>

I don't, but assumed many might use it.

> Conversely, with the change in default proposed above, anyone with their
> own configs enabling the switcher will suddenly see the number of CPUs
> go from 2 to 5. We also have the situation where we have a config
> option, which when enabled, doesn't actually do anything unless the user
> also changes boot arguments or takes measures to enable it after boot.
> Which seems the wrong way for things to work to me.
>

OK, makes sense. Just curious how many big.LITTLE platforms have CPUFreq
support and integrated with bL switcher. Otherwise we end up switching
clusters/cpus using dummy i/f anyways(and probably that's the reason why
that config is enabled which I missed to understand initially as I was
thinking it's more for development and testing only). If is that's
acceptable for those platforms, then it should be fine I believe ?

Regards,
Sudeep

[PATCH] ARM: multi_v7_defconfig: major refresh

[Jon Medhurst (Tixy)]

On Fri, 2014-08-01 at 15:57 +0100, Sudeep Holla wrote:
> 
> On 01/08/14 12:28, Jon Medhurst (Tixy) wrote:
> > On Fri, 2014-08-01 at 12:12 +0100, Sudeep Holla wrote:
> >>
> >> On 01/08/14 12:03, Olof Johansson wrote:
> >>> On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
> >>>> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
> 
> [...]
> 
> >>>>
> >>>>>    One way to achieve this:
> >>>>> (There's sysfs to re-enable it runtime)
> >>>>
> >>>> The opposite is also true, if you don't want the switcher enabled you
> >>>> can disable it by the same method after boot ;-)
> >>>>
> >>>>> -->8
> >>>>> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> >>>>> index 490f3dced749..f4c36e70166a 100644
> >>>>> --- a/arch/arm/common/bL_switcher.c
> >>>>> +++ b/arch/arm/common/bL_switcher.c
> >>>>> @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
> >>>>> notifier_block *nfb,
> >>>>>            return NOTIFY_DONE;
> >>>>>     }
> >>>>>
> >>>>> -static bool no_bL_switcher;
> >>>>> +static bool no_bL_switcher = true;
> >>>>
> >>>> This changes the default for everyone, which I guess is fair enough if
> >>>> there is a good reason, but I'm not sure there is.
> >>>
> >>> No, I don't think there is.
> >>>
> >>
> >> It's just that people using TC2 will suddenly see 3 of the 5 CPUs missing.
> >
> > Yes, if they we're previously using multi_v7_defconfig (do people
> > working specifically with TC2's use that?)
> >
> 
> I don't, but assumed many might use it.
> 
> > Conversely, with the change in default proposed above, anyone with their
> > own configs enabling the switcher will suddenly see the number of CPUs
> > go from 2 to 5. We also have the situation where we have a config
> > option, which when enabled, doesn't actually do anything unless the user
> > also changes boot arguments or takes measures to enable it after boot.
> > Which seems the wrong way for things to work to me.
> >
> 
> OK, makes sense. Just curious how many big.LITTLE platforms have CPUFreq
> support and integrated with bL switcher. Otherwise we end up switching
> clusters/cpus using dummy i/f anyways

Hmm, that is a point, there are 3 other big.LITTLE SoC's I can spot in
mainline [1], and I wouldn't want to speculate how they would be
affected by having the big.LITTLE switcher enabled.

[1] exynos5420, exynos5260, r8a7790

-- 
Tixy

[PATCH] ARM: multi_v7_defconfig: major refresh

[Olof Johansson]

On Fri, Aug 01, 2014 at 02:53:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Friday, August 01, 2014 12:14:41 PM Sachin Kamat wrote:
> > On Thu, Jul 31, 2014 at 11:56 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
> > > On Thu, Jul 31, 2014 at 11:37 AM, Tushar Behera <trblinux@gmail.com> wrote:
> > >> On Wed, Jul 23, 2014 at 1:58 AM, Olof Johansson <olof@lixom.net> wrote:
> > >>> On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > >>>> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
> > >>>>> This is a major refresh of the multi_v7_defconfig:
> > >>>>>
> > >>>>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
> > >>>>>  * Enable big.LITTLE
> > >>>>>  * MCPM
> > >>>>>  * CYAPA touchpad
> > >>>>>  * Samsung-related MTD/regulator/clk/pinmux drivers
> > >>>>>  * Add some of the CrOS EC drivers
> > >>>>> - Turn on TPM, HW_RANDOM
> > >>>>> - OMAP_USB3 -> TI_PIPE3 option rename
> > >>>>> - Enable MCPM/b.L for VEXPRESS
> > >>>>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
> > >>>>> - CONFIG_LOGO, because penguins.
> > >>>>>
> > >>>>> I took care to keep the new options that have been added for whose the
> > >>>>> drivers are not yet in our for-next branch. This was pretty awkward so
> > >>>>> we should sort out how to handle those better in the future.
> > >>>>
> > >>>> Since you've already done all those, how about enabling THUMB2_KERNEL?
> > >>>> For the multi_v7_defconfig, it should actually give some benefits,
> > >>>> since it's rather large, and it would be good to have some more testing
> > >>>> with this option enabled.
> > >>>>
> > >>>> I guess the first step would be to enable it and just see if your
> > >>>> boot farm survives the change.
> > >>>
> > >>> Good point, I'll definitely give that a go once the current issues are resolved.
> > >>>
> > >>> Which are: These changes make 5250-based machines (snow and arndale)
> > >>> break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
> > >>> might be missing pinctrl setups for it?
> > >
> > > i2c timeout issue should have been fixed with the following patch:
> > > i2c: i2c-s3c2410: Drop class based scanning to improve bootup time
> > > (commit id: 6031d3dfc73b49bede540872e51a70ee0b6786d4) which is
> > > available on Wolfram's I2C tree (should be part of linux-next too). Also
> > > I do not see I2C_S3C2410 enabled in the config.
> > > I do not have access to h/w today. I can verify and check tomorrow or
> > > somebody could test it in the meantime with the above suggestions?
> > 
> > Olof,
> > Tested your multi_v7_defconfig patch on top of latest linux-next (20140731).
> > I did not see any aforementioned i2c issues on 5250 based Snow board. It
> > booted fine. However on 5250 based Arndale board, the boot stops at
> > the following:
> > 
> > [    1.951863] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> > [    1.956937] ehci-pci: EHCI PCI platform driver
> > [    1.961392] ehci-exynos: EHCI EXYNOS driver
> > [    1.965698] exynos-ehci 12110000.usb: EHCI Host Controller
> > [    1.971007] exynos-ehci 12110000.usb: new USB bus registered,
> > assigned bus number 1
> > [    1.981593] exynos-ehci 12110000.usb: can't setup: -110
> > [    1.985361] exynos-ehci 12110000.usb: USB bus 1 deregistered
> > [    1.991001] exynos-ehci 12110000.usb: Failed to add USB HCD
> > [    1.996569] exynos-ehci: probe of 12110000.usb failed with error -110
> > [    2.003041] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> > [    2.009149] ohci-exynos: OHCI EXYNOS driver
> > [    2.013457] exynos-ohci 12120000.usb: USB Host Controller
> > [    2.018702] exynos-ohci 12120000.usb: new USB bus registered,
> > assigned bus number 1
> > 
> > Boots well with exynos_defconfig though. Probably some conflict with
> > other config options?
> > 
> > I couldn't find out as I am busy with some other activity.
> 
> Olof, could you please remember to update exynos_defconfig when updating
> multi_v7_defconfig with Exynos related changes?  These two configs have
> been getting slightly out-of-sync since introduction of multiplatform
> support for Exynos arch.  It causes waste of development/testing efforts.

I can try to, but in the end it's up to the platform maintainer, which is
Kukjin.

> Kukjin, it would really be great if all Exynos users run on a common
> configuration so the development/testing is done more efficiently.  Could
> you please reconsider removal of exynos_defconfig?

There's still some benefit to having per-SoC defconfigs, since it's a better
starting point for someone looking to cut down a defconfig for use on their
product/single-platform kernel.

If anything, having slightly different defconfigs improves test coverage since
fewer assumptions about everybody using exactly the same configs will get
exposed.


-Olof

[PATCH] ARM: multi_v7_defconfig: major refresh

[Olof Johansson]

On Fri, Aug 01, 2014 at 04:53:19PM +0100, Jon Medhurst (Tixy) wrote:
> On Fri, 2014-08-01 at 15:57 +0100, Sudeep Holla wrote:
> > 
> > On 01/08/14 12:28, Jon Medhurst (Tixy) wrote:
> > > On Fri, 2014-08-01 at 12:12 +0100, Sudeep Holla wrote:
> > >>
> > >> On 01/08/14 12:03, Olof Johansson wrote:
> > >>> On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
> > >>>> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
> > 
> > [...]
> > 
> > >>>>
> > >>>>>    One way to achieve this:
> > >>>>> (There's sysfs to re-enable it runtime)
> > >>>>
> > >>>> The opposite is also true, if you don't want the switcher enabled you
> > >>>> can disable it by the same method after boot ;-)
> > >>>>
> > >>>>> -->8
> > >>>>> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> > >>>>> index 490f3dced749..f4c36e70166a 100644
> > >>>>> --- a/arch/arm/common/bL_switcher.c
> > >>>>> +++ b/arch/arm/common/bL_switcher.c
> > >>>>> @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
> > >>>>> notifier_block *nfb,
> > >>>>>            return NOTIFY_DONE;
> > >>>>>     }
> > >>>>>
> > >>>>> -static bool no_bL_switcher;
> > >>>>> +static bool no_bL_switcher = true;
> > >>>>
> > >>>> This changes the default for everyone, which I guess is fair enough if
> > >>>> there is a good reason, but I'm not sure there is.
> > >>>
> > >>> No, I don't think there is.
> > >>>
> > >>
> > >> It's just that people using TC2 will suddenly see 3 of the 5 CPUs missing.
> > >
> > > Yes, if they we're previously using multi_v7_defconfig (do people
> > > working specifically with TC2's use that?)
> > >
> > 
> > I don't, but assumed many might use it.
> > 
> > > Conversely, with the change in default proposed above, anyone with their
> > > own configs enabling the switcher will suddenly see the number of CPUs
> > > go from 2 to 5. We also have the situation where we have a config
> > > option, which when enabled, doesn't actually do anything unless the user
> > > also changes boot arguments or takes measures to enable it after boot.
> > > Which seems the wrong way for things to work to me.
> > >
> > 
> > OK, makes sense. Just curious how many big.LITTLE platforms have CPUFreq
> > support and integrated with bL switcher. Otherwise we end up switching
> > clusters/cpus using dummy i/f anyways
> 
> Hmm, that is a point, there are 3 other big.LITTLE SoC's I can spot in
> mainline [1], and I wouldn't want to speculate how they would be
> affected by having the big.LITTLE switcher enabled.
> 
> [1] exynos5420, exynos5260, r8a7790

5422/5800 is a fourth SoC, but it's nearly identical to 5420 with a few
bugfixes.

At the end of the day, b.L switcher has predictable user behavior, while
running with assymetric SMP does not. Until the scheduler work has been done,
it is significantly better to enable the switcher instead of SMP on these
platforms.

Once the scheduler work has come further, we can switch over. But not until
then.


-Olof

[PATCH] ARM: multi_v7_defconfig: major refresh

[Olof Johansson]

On Fri, Aug 01, 2014 at 12:06:13PM +0100, Pawel Moll wrote:
> On Fri, 2014-08-01 at 12:01 +0100, Jon Medhurst (Tixy) wrote:
> > > -->8
> > > diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> > > index 490f3dced749..f4c36e70166a 100644
> > > --- a/arch/arm/common/bL_switcher.c
> > > +++ b/arch/arm/common/bL_switcher.c
> > > @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct 
> > > notifier_block *nfb,
> > >          return NOTIFY_DONE;
> > >   }
> > > 
> > > -static bool no_bL_switcher;
> > > +static bool no_bL_switcher = true;
> > 
> > This changes the default for everyone, which I guess is fair enough if
> > there is a good reason, but I'm not sure there is.
> 
> I would vote for this change and argue that b.L switcher is "strange
> enough" (ie. I know I've got 5 processors, so why do I see only 2?)
> _not_ to have it enabled by default. I'd hope that a user looking for
> this functionality will know how to turn it on.

I strongly disagree. Today nearly all products that ship have a switcher
enabled, since the scheduler work has not been done yet upstream. Having
a platform that behaves undeterministically because the scheduler can't tell
the core types apart and makes bad decisions is better than someone not finding
the right number of CPUs under /proc/cpuinfo.

And the same goes in the other direction: Any user looking to test out the
scheduler work will know how to turn it on.

The only other argument I'm willing to have here is if you want to somehow
control this per platform and add a hook on vexpress that turns off the
switcher by default. The rest of them should have it on.


-Olof

[PATCH] ARM: multi_v7_defconfig: major refresh

[Sachin Kamat]

On Fri, Aug 1, 2014 at 12:14 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
> On Thu, Jul 31, 2014 at 11:56 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>> On Thu, Jul 31, 2014 at 11:37 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>> On Wed, Jul 23, 2014 at 1:58 AM, Olof Johansson <olof@lixom.net> wrote:
>>>> On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>>> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
>>>>>> This is a major refresh of the multi_v7_defconfig:
>>>>>>
>>>>>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>>>>>>  * Enable big.LITTLE
>>>>>>  * MCPM
>>>>>>  * CYAPA touchpad
>>>>>>  * Samsung-related MTD/regulator/clk/pinmux drivers
>>>>>>  * Add some of the CrOS EC drivers
>>>>>> - Turn on TPM, HW_RANDOM
>>>>>> - OMAP_USB3 -> TI_PIPE3 option rename
>>>>>> - Enable MCPM/b.L for VEXPRESS
>>>>>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
>>>>>> - CONFIG_LOGO, because penguins.
>>>>>>
>>>>>> I took care to keep the new options that have been added for whose the
>>>>>> drivers are not yet in our for-next branch. This was pretty awkward so
>>>>>> we should sort out how to handle those better in the future.
>>>>>
>>>>> Since you've already done all those, how about enabling THUMB2_KERNEL?
>>>>> For the multi_v7_defconfig, it should actually give some benefits,
>>>>> since it's rather large, and it would be good to have some more testing
>>>>> with this option enabled.
>>>>>
>>>>> I guess the first step would be to enable it and just see if your
>>>>> boot farm survives the change.
>>>>
>>>> Good point, I'll definitely give that a go once the current issues are resolved.
>>>>
>>>> Which are: These changes make 5250-based machines (snow and arndale)
>>>> break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
>>>> might be missing pinctrl setups for it?
>>
>> i2c timeout issue should have been fixed with the following patch:
>> i2c: i2c-s3c2410: Drop class based scanning to improve bootup time
>> (commit id: 6031d3dfc73b49bede540872e51a70ee0b6786d4) which is
>> available on Wolfram's I2C tree (should be part of linux-next too). Also
>> I do not see I2C_S3C2410 enabled in the config.
>> I do not have access to h/w today. I can verify and check tomorrow or
>> somebody could test it in the meantime with the above suggestions?
>
> Olof,
> Tested your multi_v7_defconfig patch on top of latest linux-next (20140731).
> I did not see any aforementioned i2c issues on 5250 based Snow board. It
> booted fine. However on 5250 based Arndale board, the boot stops at
> the following:
>
> [    1.951863] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    1.956937] ehci-pci: EHCI PCI platform driver
> [    1.961392] ehci-exynos: EHCI EXYNOS driver
> [    1.965698] exynos-ehci 12110000.usb: EHCI Host Controller
> [    1.971007] exynos-ehci 12110000.usb: new USB bus registered,
> assigned bus number 1
> [    1.981593] exynos-ehci 12110000.usb: can't setup: -110
> [    1.985361] exynos-ehci 12110000.usb: USB bus 1 deregistered
> [    1.991001] exynos-ehci 12110000.usb: Failed to add USB HCD
> [    1.996569] exynos-ehci: probe of 12110000.usb failed with error -110
> [    2.003041] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    2.009149] ohci-exynos: OHCI EXYNOS driver
> [    2.013457] exynos-ohci 12120000.usb: USB Host Controller
> [    2.018702] exynos-ohci 12120000.usb: new USB bus registered,
> assigned bus number 1
>
> Boots well with exynos_defconfig though. Probably some conflict with
> other config options?
> I couldn't find out as I am busy with some other activity.

The following patch from Vivek fixes the above mentioned USB issue.
https://lkml.org/lkml/2014/8/5/142

-- 
Regards,
Sachin.

[PATCH] ARM: multi_v7_defconfig: major refresh

[Kevin Hilman]

Olof Johansson <olof@lixom.net> writes:

> On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
>> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
>>>
>>> On 22/07/14 19:01, Olof Johansson wrote:
>>> > This is a major refresh of the multi_v7_defconfig:
>>> >
>>> > - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>>> >   * Enable big.LITTLE
>>> >   * MCPM
>>> [...]
>>
>>> > +CONFIG_BIG_LITTLE=y
>>> > +CONFIG_BL_SWITCHER=y
>>>
>>> IIUC, this will enable switcher code by default. I am not sure if this
>>> is intentional ? E.g.: After this I can have only 2 active cpus instead
>>> of 5 on my Vexpress TC2 platform.
>>>
>>> IMO we can keep this enabled by default in the build, but disabled
>>> by default on boot.
>>
>> TC2 has a big.LITTLE processor and the switcher is the only mainlined
>> way of making any kind of proper use of big.LITTLE, so why not have it
>> enabled by default?
>
> +1.
>

I disagree.

The bL switcher is a stopgap used on products (which have their own
defconfigs anyways) but upstream development is focused on HMP (or
whatever the current buzzword is for the kernel directly scheduling both
big and little cores.)  

So IMO, for upstream coverage, we should *not* be enabling the switcher
but should be letting the scheduler directly manage all CPUs.

At least on Exynos, with MCPM support merged, the kernel can boot up all
the CPUs and directly manage them.

Kevin

[PATCH] ARM: multi_v7_defconfig: major refresh

[Kevin Hilman]

Olof Johansson <olof@lixom.net> writes:

> On Fri, Aug 01, 2014 at 04:53:19PM +0100, Jon Medhurst (Tixy) wrote:
>> On Fri, 2014-08-01 at 15:57 +0100, Sudeep Holla wrote:
>> > 
>> > On 01/08/14 12:28, Jon Medhurst (Tixy) wrote:
>> > > On Fri, 2014-08-01 at 12:12 +0100, Sudeep Holla wrote:
>> > >>
>> > >> On 01/08/14 12:03, Olof Johansson wrote:
>> > >>> On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
>> > >>>> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
>> > 
>> > [...]
>> > 
>> > >>>>
>> > >>>>>    One way to achieve this:
>> > >>>>> (There's sysfs to re-enable it runtime)
>> > >>>>
>> > >>>> The opposite is also true, if you don't want the switcher enabled you
>> > >>>> can disable it by the same method after boot ;-)
>> > >>>>
>> > >>>>> -->8
>> > >>>>> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
>> > >>>>> index 490f3dced749..f4c36e70166a 100644
>> > >>>>> --- a/arch/arm/common/bL_switcher.c
>> > >>>>> +++ b/arch/arm/common/bL_switcher.c
>> > >>>>> @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
>> > >>>>> notifier_block *nfb,
>> > >>>>>            return NOTIFY_DONE;
>> > >>>>>     }
>> > >>>>>
>> > >>>>> -static bool no_bL_switcher;
>> > >>>>> +static bool no_bL_switcher = true;
>> > >>>>
>> > >>>> This changes the default for everyone, which I guess is fair enough if
>> > >>>> there is a good reason, but I'm not sure there is.
>> > >>>
>> > >>> No, I don't think there is.
>> > >>>
>> > >>
>> > >> It's just that people using TC2 will suddenly see 3 of the 5 CPUs missing.
>> > >
>> > > Yes, if they we're previously using multi_v7_defconfig (do people
>> > > working specifically with TC2's use that?)
>> > >
>> > 
>> > I don't, but assumed many might use it.
>> > 
>> > > Conversely, with the change in default proposed above, anyone with their
>> > > own configs enabling the switcher will suddenly see the number of CPUs
>> > > go from 2 to 5. We also have the situation where we have a config
>> > > option, which when enabled, doesn't actually do anything unless the user
>> > > also changes boot arguments or takes measures to enable it after boot.
>> > > Which seems the wrong way for things to work to me.
>> > >
>> > 
>> > OK, makes sense. Just curious how many big.LITTLE platforms have CPUFreq
>> > support and integrated with bL switcher. Otherwise we end up switching
>> > clusters/cpus using dummy i/f anyways
>> 
>> Hmm, that is a point, there are 3 other big.LITTLE SoC's I can spot in
>> mainline [1], and I wouldn't want to speculate how they would be
>> affected by having the big.LITTLE switcher enabled.
>> 
>> [1] exynos5420, exynos5260, r8a7790
>
> 5422/5800 is a fourth SoC, but it's nearly identical to 5420 with a few
> bugfixes.
>
> At the end of the day, b.L switcher has predictable user behavior, while
> running with assymetric SMP does not. 

What is unpredictable?  Perhaps sub-optimal, but I don't see what's any
more unpreditable about it than normal SMP.

> Until the scheduler work has been done,
> it is significantly better to enable the switcher instead of SMP on these
> platforms.
>
> Once the scheduler work has come further, we can switch over. But not until
> then.

I think the upstream defconfigs should facilitate the broader testing of
the scheduler work by having the swticher disabled.

By enabling the switcher (and the corresponding cpufreq switcher driver)
by default, we're now actually making one more obstacle for broader
testing of the generic scheduling on all cores.
  
Kevin

[PATCH] ARM: multi_v7_defconfig: major refresh

[Nicolas Pitre]

On Fri, 8 Aug 2014, Kevin Hilman wrote:

> Olof Johansson <olof@lixom.net> writes:
> 
> > On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
> >> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
> >>>
> >>> On 22/07/14 19:01, Olof Johansson wrote:
> >>> > This is a major refresh of the multi_v7_defconfig:
> >>> >
> >>> > - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
> >>> >   * Enable big.LITTLE
> >>> >   * MCPM
> >>> [...]
> >>
> >>> > +CONFIG_BIG_LITTLE=y
> >>> > +CONFIG_BL_SWITCHER=y
> >>>
> >>> IIUC, this will enable switcher code by default. I am not sure if this
> >>> is intentional ? E.g.: After this I can have only 2 active cpus instead
> >>> of 5 on my Vexpress TC2 platform.
> >>>
> >>> IMO we can keep this enabled by default in the build, but disabled
> >>> by default on boot.
> >>
> >> TC2 has a big.LITTLE processor and the switcher is the only mainlined
> >> way of making any kind of proper use of big.LITTLE, so why not have it
> >> enabled by default?
> >
> > +1.
> >
> 
> I disagree.
> 
> The bL switcher is a stopgap used on products (which have their own
> defconfigs anyways) but upstream development is focused on HMP (or
> whatever the current buzzword is for the kernel directly scheduling both
> big and little cores.)  
> 
> So IMO, for upstream coverage, we should *not* be enabling the switcher
> but should be letting the scheduler directly manage all CPUs.

I agree... in principle.  In practice the upstream scheduler has no 
notion of asymmetric processing yet, and probably still for a while to 
come.  Once the scheduler does a semi-descent job at it then the 
switcher should default to being disabled.

> At least on Exynos, with MCPM support merged, the kernel can boot up all
> the CPUs and directly manage them.

"Managing" them is still somewhat overstated.  Yes, the scheduler does 
_see_ them but it still can't manage them properly.  At best you'll get 
somewhat random system performance, at worst it'll be completely 
inefficient.  In most cases the switcher will give you much better 
behavior for the time being.


Nicolas

[PATCH] ARM: multi_v7_defconfig: major refresh

[Nicolas Pitre]

On Fri, 8 Aug 2014, Kevin Hilman wrote:

> Olof Johansson <olof@lixom.net> writes:
> 
> > On Fri, Aug 01, 2014 at 04:53:19PM +0100, Jon Medhurst (Tixy) wrote:
> >> On Fri, 2014-08-01 at 15:57 +0100, Sudeep Holla wrote:
> >> > 
> >> > On 01/08/14 12:28, Jon Medhurst (Tixy) wrote:
> >> > > On Fri, 2014-08-01 at 12:12 +0100, Sudeep Holla wrote:
> >> > >>
> >> > >> On 01/08/14 12:03, Olof Johansson wrote:
> >> > >>> On Fri, Aug 1, 2014 at 4:01 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
> >> > >>>> On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:
> >> > 
> >> > [...]
> >> > 
> >> > >>>>
> >> > >>>>>    One way to achieve this:
> >> > >>>>> (There's sysfs to re-enable it runtime)
> >> > >>>>
> >> > >>>> The opposite is also true, if you don't want the switcher enabled you
> >> > >>>> can disable it by the same method after boot ;-)
> >> > >>>>
> >> > >>>>> -->8
> >> > >>>>> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> >> > >>>>> index 490f3dced749..f4c36e70166a 100644
> >> > >>>>> --- a/arch/arm/common/bL_switcher.c
> >> > >>>>> +++ b/arch/arm/common/bL_switcher.c
> >> > >>>>> @@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
> >> > >>>>> notifier_block *nfb,
> >> > >>>>>            return NOTIFY_DONE;
> >> > >>>>>     }
> >> > >>>>>
> >> > >>>>> -static bool no_bL_switcher;
> >> > >>>>> +static bool no_bL_switcher = true;
> >> > >>>>
> >> > >>>> This changes the default for everyone, which I guess is fair enough if
> >> > >>>> there is a good reason, but I'm not sure there is.
> >> > >>>
> >> > >>> No, I don't think there is.
> >> > >>>
> >> > >>
> >> > >> It's just that people using TC2 will suddenly see 3 of the 5 CPUs missing.
> >> > >
> >> > > Yes, if they we're previously using multi_v7_defconfig (do people
> >> > > working specifically with TC2's use that?)
> >> > >
> >> > 
> >> > I don't, but assumed many might use it.
> >> > 
> >> > > Conversely, with the change in default proposed above, anyone with their
> >> > > own configs enabling the switcher will suddenly see the number of CPUs
> >> > > go from 2 to 5. We also have the situation where we have a config
> >> > > option, which when enabled, doesn't actually do anything unless the user
> >> > > also changes boot arguments or takes measures to enable it after boot.
> >> > > Which seems the wrong way for things to work to me.
> >> > >
> >> > 
> >> > OK, makes sense. Just curious how many big.LITTLE platforms have CPUFreq
> >> > support and integrated with bL switcher. Otherwise we end up switching
> >> > clusters/cpus using dummy i/f anyways
> >> 
> >> Hmm, that is a point, there are 3 other big.LITTLE SoC's I can spot in
> >> mainline [1], and I wouldn't want to speculate how they would be
> >> affected by having the big.LITTLE switcher enabled.
> >> 
> >> [1] exynos5420, exynos5260, r8a7790
> >
> > 5422/5800 is a fourth SoC, but it's nearly identical to 5420 with a few
> > bugfixes.
> >
> > At the end of the day, b.L switcher has predictable user behavior, while
> > running with assymetric SMP does not. 
> 
> What is unpredictable?  Perhaps sub-optimal, but I don't see what's any
> more unpreditable about it than normal SMP.

CPUs not being equal, your overall performance will be randomized 
depending on which CPU a given task ends up being scheduled on.  And in 
turn this is going to skew scheduler profiling and statistics gathering 
for that task if it is migrated around.  Some performance critical tasks 
might never get the boost from a big CPU while other tasks will 
needlessly drain your battery by not being run on a small CPU.  People 
will complain and the squirrel across the street will steal your SD 
cards, etc.

> > Until the scheduler work has been done,
> > it is significantly better to enable the switcher instead of SMP on these
> > platforms.
> >
> > Once the scheduler work has come further, we can switch over. But not until
> > then.
> 
> I think the upstream defconfigs should facilitate the broader testing of
> the scheduler work by having the swticher disabled.
> 
> By enabling the switcher (and the corresponding cpufreq switcher driver)
> by default, we're now actually making one more obstacle for broader
> testing of the generic scheduling on all cores.

The generic scheduler currently has nothing really worth testing by the 
wider  audience.  Be assured that when it does then the switcher will 
indeed default to off.


Nicolas

[PATCH] ARM: multi_v7_defconfig: major refresh

[Amit Kucheria]

On Fri, Aug 8, 2014 at 11:42 PM, Kevin Hilman <khilman@linaro.org> wrote:
> Olof Johansson <olof@lixom.net> writes:
>
>>
>> At the end of the day, b.L switcher has predictable user behavior, while
>> running with assymetric SMP does not.
>
> What is unpredictable?  Perhaps sub-optimal, but I don't see what's any
> more unpreditable about it than normal SMP.
>
>> Until the scheduler work has been done,
>> it is significantly better to enable the switcher instead of SMP on these
>> platforms.
>>
>> Once the scheduler work has come further, we can switch over. But not until
>> then.
>
> I think the upstream defconfigs should facilitate the broader testing of
> the scheduler work by having the swticher disabled.

I thought the upstream defconfigs were meant to make machines work out
of the box. Any development effort can surely tweak the configs to
their needs.

> By enabling the switcher (and the corresponding cpufreq switcher driver)
> by default, we're now actually making one more obstacle for broader
> testing of the generic scheduling on all cores.

Actually, there might some advantages to turning on the switcher.
 1. The performance/power numbers of the b.L switcher is the minimum
we need to achieve on a scheduler-driven b.L system. It establishes a
baseline. Shame on us working on EAS if the switcher does better.
 2. The switcher exercises the cpufreq drivers quite a bit. So any
niggles will be ironed out on platforms where it hasn't been well
tested.

Regards,
Amit

[PATCH] ARM: multi_v7_defconfig: major refresh

[Kevin Hilman]

On Fri, Aug 8, 2014 at 11:26 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 8 Aug 2014, Kevin Hilman wrote:

[...]

>> I think the upstream defconfigs should facilitate the broader testing of
>> the scheduler work by having the swticher disabled.
>>
>> By enabling the switcher (and the corresponding cpufreq switcher driver)
>> by default, we're now actually making one more obstacle for broader
>> testing of the generic scheduling on all cores.
>
> The generic scheduler currently has nothing really worth testing by the
> wider  audience.  Be assured that when it does then the switcher will
> indeed default to off.

I guess my vacation successfully purged my memory.  I was thinking the
switcher was only a complie-time option, but just realized that it can
be disabled at runtime (via /sys/kernel/bL_switcher/active.)

With the runtime enable/disable feature of the switcher, I don't have
any more (reasonable) objections to it being enabled by default.

Kevin

[PATCH] ARM: multi_v7_defconfig: major refresh

[Olof Johansson]

On Tue, Jul 22, 2014 at 1:28 PM, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
>>> This is a major refresh of the multi_v7_defconfig:
>>>
>>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
>>>  * Enable big.LITTLE
>>>  * MCPM
>>>  * CYAPA touchpad
>>>  * Samsung-related MTD/regulator/clk/pinmux drivers
>>>  * Add some of the CrOS EC drivers
>>> - Turn on TPM, HW_RANDOM
>>> - OMAP_USB3 -> TI_PIPE3 option rename
>>> - Enable MCPM/b.L for VEXPRESS
>>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
>>> - CONFIG_LOGO, because penguins.
>>>
>>> I took care to keep the new options that have been added for whose the
>>> drivers are not yet in our for-next branch. This was pretty awkward so
>>> we should sort out how to handle those better in the future.
>>
>> Since you've already done all those, how about enabling THUMB2_KERNEL?
>> For the multi_v7_defconfig, it should actually give some benefits,
>> since it's rather large, and it would be good to have some more testing
>> with this option enabled.
>>
>> I guess the first step would be to enable it and just see if your
>> boot farm survives the change.
>
> Good point, I'll definitely give that a go once the current issues are resolved.
>
> Which are: These changes make 5250-based machines (snow and arndale)
> break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
> might be missing pinctrl setups for it?
>
> Tushar, Kukjin, any chance you can investigate from your end? I'd like
> to get this change in since it allows for better multiplatform
> coverage, but the Exynos breakage must be fixed...

This is still broken on 5250:
http://arm-soc.lixom.net/bootlogs/misc/v3.16-10143-gccefc7a/ is with
this patch applied on top of current mainline and the few fixes we
have queued up.

I2C_S3C2410 is enabled with that config now.

Tushar is no longer on a Linaro landing team, so he's not looking
after Arndale. Kukjin?


-Olof

[PATCH] ARM: multi_v7_defconfig: major refresh

[Bartlomiej Zolnierkiewicz]

Hi Olof,

On Sunday, August 10, 2014 08:05:23 PM Olof Johansson wrote:
> On Tue, Jul 22, 2014 at 1:28 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
> >>> This is a major refresh of the multi_v7_defconfig:
> >>>
> >>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
> >>>  * Enable big.LITTLE
> >>>  * MCPM
> >>>  * CYAPA touchpad
> >>>  * Samsung-related MTD/regulator/clk/pinmux drivers
> >>>  * Add some of the CrOS EC drivers
> >>> - Turn on TPM, HW_RANDOM
> >>> - OMAP_USB3 -> TI_PIPE3 option rename
> >>> - Enable MCPM/b.L for VEXPRESS
> >>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
> >>> - CONFIG_LOGO, because penguins.
> >>>
> >>> I took care to keep the new options that have been added for whose the
> >>> drivers are not yet in our for-next branch. This was pretty awkward so
> >>> we should sort out how to handle those better in the future.
> >>
> >> Since you've already done all those, how about enabling THUMB2_KERNEL?
> >> For the multi_v7_defconfig, it should actually give some benefits,
> >> since it's rather large, and it would be good to have some more testing
> >> with this option enabled.
> >>
> >> I guess the first step would be to enable it and just see if your
> >> boot farm survives the change.
> >
> > Good point, I'll definitely give that a go once the current issues are resolved.
> >
> > Which are: These changes make 5250-based machines (snow and arndale)
> > break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
> > might be missing pinctrl setups for it?
> >
> > Tushar, Kukjin, any chance you can investigate from your end? I'd like
> > to get this change in since it allows for better multiplatform
> > coverage, but the Exynos breakage must be fixed...
> 
> This is still broken on 5250:
> http://arm-soc.lixom.net/bootlogs/misc/v3.16-10143-gccefc7a/ is with
> this patch applied on top of current mainline and the few fixes we
> have queued up.
> 
> I2C_S3C2410 is enabled with that config now.
> 
> Tushar is no longer on a Linaro landing team, so he's not looking
> after Arndale. Kukjin?

I'm not responsible for Arndale but I took a look at the issue and
managed to fix it on my setup.

Please see:

  https://lkml.org/lkml/2014/8/27/116

for details.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

[PATCH] ARM: multi_v7_defconfig: major refresh

[Bartlomiej Zolnierkiewicz]

Hi,

On Wednesday, August 27, 2014 09:59:37 AM Bartlomiej Zolnierkiewicz wrote:
> 
> Hi Olof,
> 
> On Sunday, August 10, 2014 08:05:23 PM Olof Johansson wrote:
> > On Tue, Jul 22, 2014 at 1:28 PM, Olof Johansson <olof@lixom.net> wrote:
> > > On Tue, Jul 22, 2014 at 11:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > >> On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
> > >>> This is a major refresh of the multi_v7_defconfig:
> > >>>
> > >>> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
> > >>>  * Enable big.LITTLE
> > >>>  * MCPM
> > >>>  * CYAPA touchpad
> > >>>  * Samsung-related MTD/regulator/clk/pinmux drivers
> > >>>  * Add some of the CrOS EC drivers
> > >>> - Turn on TPM, HW_RANDOM
> > >>> - OMAP_USB3 -> TI_PIPE3 option rename
> > >>> - Enable MCPM/b.L for VEXPRESS
> > >>> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
> > >>> - CONFIG_LOGO, because penguins.
> > >>>
> > >>> I took care to keep the new options that have been added for whose the
> > >>> drivers are not yet in our for-next branch. This was pretty awkward so
> > >>> we should sort out how to handle those better in the future.
> > >>
> > >> Since you've already done all those, how about enabling THUMB2_KERNEL?
> > >> For the multi_v7_defconfig, it should actually give some benefits,
> > >> since it's rather large, and it would be good to have some more testing
> > >> with this option enabled.
> > >>
> > >> I guess the first step would be to enable it and just see if your
> > >> boot farm survives the change.
> > >
> > > Good point, I'll definitely give that a go once the current issues are resolved.
> > >
> > > Which are: These changes make 5250-based machines (snow and arndale)
> > > break. Lots of i2c timeouts on SATA and hdmi-phy. Looks like arndale
> > > might be missing pinctrl setups for it?
> > >
> > > Tushar, Kukjin, any chance you can investigate from your end? I'd like
> > > to get this change in since it allows for better multiplatform
> > > coverage, but the Exynos breakage must be fixed...
> > 
> > This is still broken on 5250:
> > http://arm-soc.lixom.net/bootlogs/misc/v3.16-10143-gccefc7a/ is with
> > this patch applied on top of current mainline and the few fixes we
> > have queued up.
> > 
> > I2C_S3C2410 is enabled with that config now.
> > 
> > Tushar is no longer on a Linaro landing team, so he's not looking
> > after Arndale. Kukjin?
> 
> I'm not responsible for Arndale but I took a look at the issue and
> managed to fix it on my setup.
> 
> Please see:
> 
>   https://lkml.org/lkml/2014/8/27/116
> 
> for details.

Vivek's USB patches are now in Linus' tree:

  46c1cda88c6e "usb: host: ehci-exynos: Remove unnecessary usb-phy support"
  2db941623d5c "usb: host: ohci-exynos: Remove unnecessary usb-phy support"
  2f7f41c7a73c "usb: ehci/ohci-exynos: Fix PHY getting sequence"

so the Exynos5250 Arndale issue should be fixed.

Olof, could you please ressurect and merge your multi_v7_defconfig refresh
patch (it contains a lot of useful changes for Exynos platforms)?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics