* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices @ 2017-01-10 9:55 ` Linus Walleij 0 siblings, 0 replies; 12+ messages in thread From: Linus Walleij @ 2017-01-10 9:55 UTC (permalink / raw) To: linux-arm-kernel, linux-arm-msm, Andy Gross, Bjorn Andersson Cc: Stephen Boyd, David Brown, 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 Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- arch/arm/configs/qcom_defconfig | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index 8c3a0108a231..eed314e39721 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -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 -- 2.9.3 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices @ 2017-01-10 9:55 ` Linus Walleij 0 siblings, 0 replies; 12+ messages in thread From: Linus Walleij @ 2017-01-10 9:55 UTC (permalink / raw) To: linux-arm-kernel 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 <linus.walleij@linaro.org> --- arch/arm/configs/qcom_defconfig | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index 8c3a0108a231..eed314e39721 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -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 -- 2.9.3 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices 2017-01-10 9:55 ` Linus Walleij @ 2017-01-10 14:53 ` Andy Gross -1 siblings, 0 replies; 12+ messages in thread From: Andy Gross @ 2017-01-10 14:53 UTC (permalink / raw) To: Linus Walleij Cc: linux-arm-kernel, linux-arm-msm, Bjorn Andersson, Stephen Boyd, David Brown On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: > 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 <linus.walleij@linaro.org> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices @ 2017-01-10 14:53 ` Andy Gross 0 siblings, 0 replies; 12+ messages in thread From: Andy Gross @ 2017-01-10 14:53 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: > 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 <linus.walleij@linaro.org> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices 2017-01-10 14:53 ` Andy Gross @ 2017-01-11 13:19 ` Linus Walleij -1 siblings, 0 replies; 12+ messages in thread From: Linus Walleij @ 2017-01-11 13:19 UTC (permalink / raw) To: Andy Gross, Arnd Bergmann, Olof Johansson Cc: David Brown, linux-arm-msm@vger.kernel.org, Stephen Boyd, linux-arm-kernel@lists.infradead.org, Bjorn Andersson On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross@linaro.org> wrote: > On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: >> 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 <linus.walleij@linaro.org> > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices @ 2017-01-11 13:19 ` Linus Walleij 0 siblings, 0 replies; 12+ messages in thread From: Linus Walleij @ 2017-01-11 13:19 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross@linaro.org> wrote: > On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: >> 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 <linus.walleij@linaro.org> > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices 2017-01-11 13:19 ` Linus Walleij @ 2017-01-11 14:08 ` Arnd Bergmann -1 siblings, 0 replies; 12+ messages in thread From: Arnd Bergmann @ 2017-01-11 14:08 UTC (permalink / raw) To: Linus Walleij Cc: David Brown, linux-arm-msm@vger.kernel.org, Stephen Boyd, Bjorn Andersson, Olof Johansson, Andy Gross, linux-arm-kernel@lists.infradead.org On Wednesday, January 11, 2017 2:19:55 PM CET Linus Walleij wrote: > On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross@linaro.org> wrote: > > On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: > >> 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 <linus.walleij@linaro.org> > > > > 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. > > 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 :) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices @ 2017-01-11 14:08 ` Arnd Bergmann 0 siblings, 0 replies; 12+ messages in thread From: Arnd Bergmann @ 2017-01-11 14:08 UTC (permalink / raw) To: linux-arm-kernel On Wednesday, January 11, 2017 2:19:55 PM CET Linus Walleij wrote: > On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross@linaro.org> wrote: > > On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: > >> 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 <linus.walleij@linaro.org> > > > > 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. > > 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 :) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices 2017-01-11 14:08 ` Arnd Bergmann @ 2017-01-11 14:11 ` Neil Armstrong -1 siblings, 0 replies; 12+ messages in thread From: Neil Armstrong @ 2017-01-11 14:11 UTC (permalink / raw) To: Arnd Bergmann, Linus Walleij Cc: David Brown, linux-arm-msm@vger.kernel.org, Stephen Boyd, Bjorn Andersson, Olof Johansson, Andy Gross, linux-arm-kernel@lists.infradead.org On 01/11/2017 03:08 PM, Arnd Bergmann wrote: > On Wednesday, January 11, 2017 2:19:55 PM CET Linus Walleij wrote: >> On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross@linaro.org> wrote: >>> On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: >>>> 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 <linus.walleij@linaro.org> >>> >>> 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. > >>> 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 :) > > 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 > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices @ 2017-01-11 14:11 ` Neil Armstrong 0 siblings, 0 replies; 12+ messages in thread From: Neil Armstrong @ 2017-01-11 14:11 UTC (permalink / raw) To: linux-arm-kernel On 01/11/2017 03:08 PM, Arnd Bergmann wrote: > On Wednesday, January 11, 2017 2:19:55 PM CET Linus Walleij wrote: >> On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross@linaro.org> wrote: >>> On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: >>>> 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 <linus.walleij@linaro.org> >>> >>> 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. > >>> 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 :) > > 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 > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices 2017-01-11 14:11 ` Neil Armstrong @ 2017-01-11 16:03 ` Andy Gross -1 siblings, 0 replies; 12+ messages in thread From: Andy Gross @ 2017-01-11 16:03 UTC (permalink / raw) To: Neil Armstrong Cc: Arnd Bergmann, Linus Walleij, David Brown, linux-arm-msm@vger.kernel.org, Stephen Boyd, Bjorn Andersson, Olof Johansson, linux-arm-kernel@lists.infradead.org On Wed, Jan 11, 2017 at 03:11:01PM +0100, Neil Armstrong wrote: > On 01/11/2017 03:08 PM, Arnd Bergmann wrote: > > On Wednesday, January 11, 2017 2:19:55 PM CET Linus Walleij wrote: > >> On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross@linaro.org> wrote: > >>> On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: > >>>> 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 <linus.walleij@linaro.org> > >>> > >>> 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. > > > >>> 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 :) > > > > 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 > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@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. 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices @ 2017-01-11 16:03 ` Andy Gross 0 siblings, 0 replies; 12+ messages in thread From: Andy Gross @ 2017-01-11 16:03 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jan 11, 2017 at 03:11:01PM +0100, Neil Armstrong wrote: > On 01/11/2017 03:08 PM, Arnd Bergmann wrote: > > On Wednesday, January 11, 2017 2:19:55 PM CET Linus Walleij wrote: > >> On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross@linaro.org> wrote: > >>> On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote: > >>>> 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 <linus.walleij@linaro.org> > >>> > >>> 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. > > > >>> 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 :) > > > > 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 > > > > _______________________________________________ > > 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. 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-01-11 16:03 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-01-10 9:55 [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices Linus Walleij 2017-01-10 9:55 ` Linus Walleij 2017-01-10 14:53 ` Andy Gross 2017-01-10 14:53 ` Andy Gross 2017-01-11 13:19 ` Linus Walleij 2017-01-11 13:19 ` Linus Walleij 2017-01-11 14:08 ` Arnd Bergmann 2017-01-11 14:08 ` Arnd Bergmann 2017-01-11 14:11 ` Neil Armstrong 2017-01-11 14:11 ` Neil Armstrong 2017-01-11 16:03 ` Andy Gross 2017-01-11 16:03 ` Andy Gross
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.