[PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices
narmstrong at baylibre.com
Wed Jan 11 06:11:01 PST 2017
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 at 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 at 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.
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
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.
More information about the linux-arm-kernel