ARM: defconfig: qcom: add APQ8060 DragonBoard devices

PATCH New Linus Walleij 4 participants 6 messages Jan 10, 2017 – Jan 11, 2017

Subsystems (3)

Arm (32-bit) Arm Qualcomm mailing list Arm Qualcomm support

lore

Share & tools

lore

Linus Walleij

author

2017-01-10 09:55 UTC #0 lore raw

PATCH 1/1 ARM: defconfig: qcom: add APQ8060 DragonBoard devices

This default-enables the devices found on the APQ8060 DragonBoard in the qcom_defconfig:

- EBI2 bus
- SMSC911x ethernet
- LEDs class and PM8058 LEDs driver, trigger and heartbeat trigger (so we get heartbeat on the board by default)
- IIO framework, including the HRTimer trigger, KXSD9 accelerometer, MPU3050 gyroscope, AK8975 magnetometer and BMP085 pressure sensor

Signed-off-by Linus Walleij <[email protected]>

---
 arch/arm/configs/qcom_defconfig | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

arch/arm/configs/qcom_defconfig +16 -0

index 8c3a0108a231..eed314e39721 100644
@@ -55,6 +55,7 @@ CONFIG_CFG80211=y
 CONFIG_RFKILL=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_QCOM_EBI2=y
 CONFIG_MTD=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_M25P80=y

@@ -71,6 +72,7 @@ CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_NETDEVICES=y
 CONFIG_DUMMY=y
 CONFIG_KS8851=y
+CONFIG_SMSC911X=y
 CONFIG_MDIO_BITBANG=y
 CONFIG_MDIO_GPIO=y
 CONFIG_SLIP=y

@@ -151,6 +153,12 @@ CONFIG_MMC_QCOM_DML=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_MSM=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_PM8058=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_PM8XXX=y
 CONFIG_DMADEVICES=y

@@ -171,6 +179,14 @@ CONFIG_QCOM_PM=y
 CONFIG_QCOM_SMEM=y
 CONFIG_QCOM_SMD=y
 CONFIG_QCOM_SMD_RPM=y
+CONFIG_IIO=y
+CONFIG_IIO_BUFFER_CB=y
+CONFIG_IIO_SW_TRIGGER=y
+CONFIG_KXSD9=y
+CONFIG_MPU3050_I2C=y
+CONFIG_AK8975=y
+CONFIG_IIO_HRTIMER_TRIGGER=y
+CONFIG_BMP280=y
 CONFIG_PHY_QCOM_APQ8064_SATA=y
 CONFIG_PHY_QCOM_IPQ806X_SATA=y
 CONFIG_EXT2_FS=y

Signature · 1 line

2.9.3

Andy Gross

2017-01-10 14:53 UTC #1 lore raw

PATCH 1/1 ARM: defconfig: qcom: add APQ8060 DragonBoard devices

Quoted 11 lines · Linus Walleij

This default-enables the devices found on the APQ8060 DragonBoard in the qcom_defconfig:
- EBI2 bus
- SMSC911x ethernet
- LEDs class and PM8058 LEDs driver, trigger and heartbeat trigger (so we get heartbeat on the board by default)
- IIO framework, including the HRTimer trigger, KXSD9 accelerometer, MPU3050 gyroscope, AK8975 magnetometer and BMP085 pressure sensor

Quoted 1 line

Signed-off-by Linus Walleij <[email protected]>

This brings up a point of discussion. Do we even need the qcom_defconfig any more? Is everyone comfortable with using the multi_v7_defconfig?

Aside from size of the image, i can't think of any other reason to keep around the separate qcom file.

Regards,
Andy

Linus Walleij

author

2017-01-11 13:19 UTC #2 lore raw

PATCH 1/1 ARM: defconfig: qcom: add APQ8060 DragonBoard devices

Quoted 12 lines · Andy Gross

Quoted 11 lines · Linus Walleij
This default-enables the devices found on the APQ8060 DragonBoard in the qcom_defconfig:
- EBI2 bus
- SMSC911x ethernet
- LEDs class and PM8058 LEDs driver, trigger and heartbeat trigger (so we get heartbeat on the board by default)
- IIO framework, including the HRTimer trigger, KXSD9 accelerometer, MPU3050 gyroscope, AK8975 magnetometer and BMP085 pressure sensor

Quoted 7 lines

Quoted 1 line
Signed-off-by Linus Walleij <[email protected]>
This brings up a point of discussion. Do we even need the qcom_defconfig any more? Is everyone comfortable with using the multi_v7_defconfig?
Aside from size of the image, i can't think of any other reason to keep around the separate qcom file.

Actually a bit of Arnd/Olof question.

Bystander opinion below:

That is pretty much up to the maintainer (you) I guess. Reasons would be:

- Lower footprint (because you may not need all stuff selected as 'y' compiled-in in multi_v7) on some platforms this is even necessary to get a bootable image or one that will load in reasonable time.

- Enable a few things by default (both compiled-in and modules) that multi_v7 would consider to be littering

- For "my" systems I usually like them because these defconfigs have vastly shorter compile time (because so much stuff that idon't concern me is left out).

On the other hand: some ARMv7 system maintainers have x86
ambitions: compile once, run everywhere, and certainly that is the ambition with multi_v7, and if that overshadows all the above, just kill off qcom_defconfig and be happy :)

Yours,
Linus Walleij

Arnd Bergmann

2017-01-11 14:08 UTC #3 lore raw

PATCH 1/1 ARM: defconfig: qcom: add APQ8060 DragonBoard devices

Quoted 13 lines · CET Linus Walleij

Quoted 12 lines · Andy Gross
Quoted 11 lines · Linus Walleij
This default-enables the devices found on the APQ8060 DragonBoard in the qcom_defconfig:
- EBI2 bus
- SMSC911x ethernet
- LEDs class and PM8058 LEDs driver, trigger and heartbeat trigger (so we get heartbeat on the board by default)
- IIO framework, including the HRTimer trigger, KXSD9 accelerometer, MPU3050 gyroscope, AK8975 magnetometer and BMP085 pressure sensor

Quoted 4 lines

Quoted 4 lines
Quoted 1 line
Signed-off-by Linus Walleij <[email protected]>
This brings up a point of discussion. Do we even need the qcom_defconfig any more? Is everyone comfortable with using the multi_v7_defconfig?

I think having one specialized defconfig for the platform is helpful for the build/boot testing, e.g. it can show whether a boot failure with multi_v7_defconfig is the result of a qcom-specific change, or a side-effect of something that was done on another platform.

Quoted 18 lines

Quoted 2 lines
Aside from size of the image, i can't think of any other reason to keep around the separate qcom file.
Actually a bit of Arnd/Olof question.
Bystander opinion below:
That is pretty much up to the maintainer (you) I guess. Reasons would be:
- Lower footprint (because you may not need all stuff selected as 'y' compiled-in in multi_v7) on some platforms this is even necessary to get a bootable image or one that will load in reasonable time.
- Enable a few things by default (both compiled-in and modules) that multi_v7 would consider to be littering

Quoted 8 lines

- For "my" systems I usually like them because these defconfigs have vastly shorter compile time (because so much stuff that idon't concern me is left out).
On the other hand: some ARMv7 system maintainers have x86
ambitions: compile once, run everywhere, and certainly that is the ambition with multi_v7, and if that overshadows all the above, just kill off qcom_defconfig and be happy :)

We recently killed of the Broadcom defconfig file that actually contained some very different platforms that had not much in common besides the company name.

I think my preference is to keep it, but if Andy wants it removed and nobody complains, that's fine too.

Arnd

Neil Armstrong

2017-01-11 14:11 UTC #4 lore raw

PATCH 1/1 ARM: defconfig: qcom: add APQ8060 DragonBoard devices

Quoted 58 lines · Arnd Bergmann

Quoted 13 lines · CET Linus Walleij
Quoted 12 lines · Andy Gross
Quoted 11 lines · Linus Walleij
This default-enables the devices found on the APQ8060 DragonBoard in the qcom_defconfig:
- EBI2 bus
- SMSC911x ethernet
- LEDs class and PM8058 LEDs driver, trigger and heartbeat trigger (so we get heartbeat on the board by default)
- IIO framework, including the HRTimer trigger, KXSD9 accelerometer, MPU3050 gyroscope, AK8975 magnetometer and BMP085 pressure sensor
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Linus Walleij <[email protected]>
This brings up a point of discussion. Do we even need the qcom_defconfig any more? Is everyone comfortable with using the multi_v7_defconfig?
I think having one specialized defconfig for the platform is helpful for the build/boot testing, e.g. it can show whether a boot failure with multi_v7_defconfig is the result of a qcom-specific change, or a side-effect of something that was done on another platform.
Quoted 18 lines
Quoted 2 lines
Aside from size of the image, i can't think of any other reason to keep around the separate qcom file.
Actually a bit of Arnd/Olof question.
Bystander opinion below:
That is pretty much up to the maintainer (you) I guess. Reasons would be:
- Lower footprint (because you may not need all stuff selected as 'y' compiled-in in multi_v7) on some platforms this is even necessary to get a bootable image or one that will load in reasonable time.
- Enable a few things by default (both compiled-in and modules) that multi_v7 would consider to be littering
Quoted 8 lines
- For "my" systems I usually like them because these defconfigs have vastly shorter compile time (because so much stuff that idon't concern me is left out).
On the other hand: some ARMv7 system maintainers have x86
ambitions: compile once, run everywhere, and certainly that is the ambition with multi_v7, and if that overshadows all the above, just kill off qcom_defconfig and be happy :)
We recently killed of the Broadcom defconfig file that actually contained some very different platforms that had not much in common besides the company name.
I think my preference is to keep it, but if Andy wants it removed and nobody complains, that's fine too.

Quoted 7 lines

Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Hi all,

In fact, as far as I remember the multi_v7 did not fit on the MDM9615 due to it's limited memory available to Linux.

Neil

Andy Gross

2017-01-11 16:03 UTC #5 lore raw

PATCH 1/1 ARM: defconfig: qcom: add APQ8060 DragonBoard devices

Quoted 67 lines · Neil Armstrong

Quoted 58 lines · Arnd Bergmann
Quoted 13 lines · CET Linus Walleij
Quoted 12 lines · Andy Gross
Quoted 11 lines · Linus Walleij
This default-enables the devices found on the APQ8060 DragonBoard in the qcom_defconfig:
- EBI2 bus
- SMSC911x ethernet
- LEDs class and PM8058 LEDs driver, trigger and heartbeat trigger (so we get heartbeat on the board by default)
- IIO framework, including the HRTimer trigger, KXSD9 accelerometer, MPU3050 gyroscope, AK8975 magnetometer and BMP085 pressure sensor
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Linus Walleij <[email protected]>
This brings up a point of discussion. Do we even need the qcom_defconfig any more? Is everyone comfortable with using the multi_v7_defconfig?
I think having one specialized defconfig for the platform is helpful for the build/boot testing, e.g. it can show whether a boot failure with multi_v7_defconfig is the result of a qcom-specific change, or a side-effect of something that was done on another platform.
Quoted 18 lines
Quoted 2 lines
Aside from size of the image, i can't think of any other reason to keep around the separate qcom file.
Actually a bit of Arnd/Olof question.
Bystander opinion below:
That is pretty much up to the maintainer (you) I guess. Reasons would be:
- Lower footprint (because you may not need all stuff selected as 'y' compiled-in in multi_v7) on some platforms this is even necessary to get a bootable image or one that will load in reasonable time.
- Enable a few things by default (both compiled-in and modules) that multi_v7 would consider to be littering
Quoted 8 lines
- For "my" systems I usually like them because these defconfigs have vastly shorter compile time (because so much stuff that idon't concern me is left out).
On the other hand: some ARMv7 system maintainers have x86
ambitions: compile once, run everywhere, and certainly that is the ambition with multi_v7, and if that overshadows all the above, just kill off qcom_defconfig and be happy :)
We recently killed of the Broadcom defconfig file that actually contained some very different platforms that had not much in common besides the company name.
I think my preference is to keep it, but if Andy wants it removed and nobody complains, that's fine too.
Quoted 7 lines
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 4 lines

Hi all,
In fact, as far as I remember the multi_v7 did not fit on the MDM9615 due to it's limited memory available to Linux.

This was mainly a user poll. We'll keep it in as there is at least one user who cannot use the multiv7 due to size. That alone is enough to keep it around.

Linus, I'll add this to my pull list.

Andy