ARM: multi_v7_defconfig: major refresh

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.

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 19 lines · Arnd Bergmann

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 7 lines

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

Quoted 25 lines · Olof Johansson

Quoted 24 lines · Arnd Bergmann

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 2 lines

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?

Quoted 26 lines · Tushar Behera

Quoted 25 lines · Olof Johansson

Quoted 24 lines · Arnd Bergmann

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

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?

Quoted 36 lines · Sachin Kamat

Quoted 26 lines · Tushar Behera

Quoted 25 lines · Olof Johansson

Quoted 24 lines · Arnd Bergmann

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

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?

Quoted 7 lines

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.

Hi,

Quoted 70 lines · Sachin Kamat

Quoted 36 lines · Sachin Kamat

Quoted 26 lines · Tushar Behera

Quoted 25 lines · Olof Johansson

Quoted 24 lines · Arnd Bergmann

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

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?

Quoted 7 lines

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?

Quoted 1 line

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?

Quoted 36 lines · Sachin Kamat

Quoted 26 lines · Tushar Behera

Quoted 25 lines · Olof Johansson

Quoted 24 lines · Arnd Bergmann

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

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?

Quoted 7 lines

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.

Quoted 19 lines · Arnd Bergmann

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 7 lines

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...

Quoted 30 lines · Olof Johansson

Quoted 19 lines · Arnd Bergmann

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 7 lines

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?

Hi Olof,

Quoted 44 lines · Olof Johansson

Quoted 30 lines · Olof Johansson

Quoted 19 lines · Arnd Bergmann

Quoted 14 lines · 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.

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 4 lines

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.

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 <[email protected]>

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 <[email protected]>

---
  arch/arm/configs/multi_v7_defconfig |   74 +++++++++++++++++++++++++++--------
  1 file changed, 58 insertions(+), 16 deletions(-)

arch/arm/configs/multi_v7_defconfig +3 -2

index 16518a7..c7654cf 100644
@@ -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

Quoted 5 lines · 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

[...]

Review

Quoted 2 lines

(quoted diff) +2 -0

+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)

Quoted 16 lines · Sudeep Holla

Quoted 5 lines · 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

[...]

Review

Quoted 2 lines

(quoted diff) +2 -0

+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.

Quoted 2 lines

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?

Quoted 3 lines

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 ;-)

Quoted 10 lines

-->8

arch/arm/common/bL_switcher.c +0 -0

index 490f3dced749..f4c36e70166a 100644
@@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
 notifier_block *nfb,
         return NOTIFY_DONE;
  }
 

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 2 lines

arch/arm/common/bL_switcher.c +1 -1

-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.

Quoted 17 lines · Jon Medhurst (Tixy)

Quoted 16 lines · Sudeep Holla

Quoted 5 lines · 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

[...]

Review

Quoted 2 lines

(quoted diff) +2 -0

+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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 17 lines

Quoted 3 lines

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 ;-)

Quoted 10 lines

-->8

arch/arm/common/bL_switcher.c +0 -0

index 490f3dced749..f4c36e70166a 100644
@@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct
 notifier_block *nfb,
          return NOTIFY_DONE;
   }
 

Quoted 5 lines

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 2 lines

arch/arm/common/bL_switcher.c +1 -1

-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.

Quoted 50 lines · Olof Johansson

Quoted 17 lines · Jon Medhurst (Tixy)

Quoted 16 lines · Sudeep Holla

Quoted 5 lines · 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

[...]

Review

Quoted 2 lines

(quoted diff) +2 -0

+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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 22 lines

Quoted 3 lines

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 ;-)

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 12 lines

-->8

arch/arm/common/bL_switcher.c +1 -1

index 490f3dced749..f4c36e70166a 100644
@@ -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.

Quoted 2 lines

No, I don't think there is.

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

Quoted 4 lines · Sudeep Holla

Quoted 2 lines · Olof Johansson

Quoted 1 line · Jon Medhurst (Tixy)

On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:

Quoted 23 lines

Quoted 23 lines

Quoted 22 lines

Quoted 3 lines

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 ;-)

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 12 lines

-->8

arch/arm/common/bL_switcher.c +1 -1

index 490f3dced749..f4c36e70166a 100644
@@ -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.

Quoted 4 lines

Quoted 2 lines

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.

Quoted 5 lines · Jon Medhurst (Tixy)

Quoted 4 lines · Sudeep Holla

Quoted 2 lines · Olof Johansson

Quoted 1 line · Jon Medhurst (Tixy)

On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:

[...]

Quoted 23 lines

Quoted 23 lines

Quoted 23 lines

Quoted 22 lines

Quoted 3 lines

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 ;-)

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 12 lines

-->8

arch/arm/common/bL_switcher.c +1 -1

index 490f3dced749..f4c36e70166a 100644
@@ -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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 7 lines

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

Quoted 52 lines · Sudeep Holla

Quoted 5 lines · Jon Medhurst (Tixy)

Quoted 4 lines · Sudeep Holla

Quoted 2 lines · Olof Johansson

Quoted 1 line · Jon Medhurst (Tixy)

On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:

[...]

Quoted 23 lines

Quoted 23 lines

Quoted 23 lines

Quoted 22 lines

Quoted 3 lines

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 ;-)

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 12 lines

-->8

arch/arm/common/bL_switcher.c +1 -1

index 490f3dced749..f4c36e70166a 100644
@@ -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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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

Quoted 61 lines · Jon Medhurst (Tixy)

Quoted 52 lines · Sudeep Holla

Quoted 5 lines · Jon Medhurst (Tixy)

Quoted 4 lines · Sudeep Holla

Quoted 2 lines · Olof Johansson

Quoted 1 line · Jon Medhurst (Tixy)

On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:

[...]

Quoted 23 lines

Quoted 23 lines

Quoted 23 lines

Quoted 22 lines

Quoted 3 lines

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 ;-)

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 12 lines

-->8

arch/arm/common/bL_switcher.c +1 -1

index 490f3dced749..f4c36e70166a 100644
@@ -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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 1 line

[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.

Quoted 64 lines · Olof Johansson

Quoted 62 lines · Jon Medhurst (Tixy)

Quoted 52 lines · Sudeep Holla

Quoted 5 lines · Jon Medhurst (Tixy)

Quoted 4 lines · Sudeep Holla

Quoted 2 lines · Olof Johansson

Quoted 1 line · Jon Medhurst (Tixy)

On Fri, 2014-08-01 at 11:26 +0100, Sudeep Holla wrote:

[...]

Quoted 23 lines

Quoted 23 lines

Quoted 23 lines

Quoted 22 lines

Quoted 3 lines

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 ;-)

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 12 lines

-->8

arch/arm/common/bL_switcher.c +1 -1

index 490f3dced749..f4c36e70166a 100644
@@ -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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 6 lines

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.

On Fri, 8 Aug 2014, Kevin Hilman wrote:

Quoted 6 lines

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.

Quoted 3 lines · Olof Johansson

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.

Quoted 4 lines

Until the scheduler work has been done,
it is significantly better to enable the switcher instead of SMP on these platforms.

Quoted 2 lines

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.

Quoted 17 lines · Jon Medhurst (Tixy)

Quoted 16 lines · Sudeep Holla

Quoted 5 lines · 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

[...]

Review

Quoted 2 lines

(quoted diff) +2 -0

+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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 18 lines · Olof Johansson

Quoted 17 lines · Jon Medhurst (Tixy)

Quoted 16 lines · Sudeep Holla

Quoted 5 lines · 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

[...]

Review

Quoted 2 lines

(quoted diff) +2 -0

+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.

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

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.

Quoted 10 lines

-->8

arch/arm/common/bL_switcher.c +0 -0

index 490f3dced749..f4c36e70166a 100644
@@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct 
 notifier_block *nfb,
         return NOTIFY_DONE;
  }
 

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 2 lines

arch/arm/common/bL_switcher.c +1 -1

-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.

Quoted 10 lines · Jon Medhurst (Tixy)

Quoted 10 lines

-->8

arch/arm/common/bL_switcher.c +0 -0

index 490f3dced749..f4c36e70166a 100644
@@ -794,7 +794,7 @@ static int bL_switcher_hotplug_callback(struct 
 notifier_block *nfb,
         return NOTIFY_DONE;
  }
 

Quoted 5 lines

arch/arm/common/bL_switcher.c static int bL_switcher_hotplug_callback(struct · line 798

Quoted 2 lines

arch/arm/common/bL_switcher.c +1 -1

-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.