Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #56725

Re: [PATCH v2] [arm64] Add more options

From Riku Voipio <riku.voipio@linaro.org>
Newsgroups linux.debian.kernel
Subject Re: [PATCH v2] [arm64] Add more options
Date 2017-01-24 11:00 +0100
Message-ID <t363n-2EC-1@gated-at.bofh.it> (permalink)
References <sZbuF-26I-5@gated-at.bofh.it> <t2Z1U-6Az-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 24 January 2017 at 04:21, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Fri, 2017-01-13 at 16:41 +0200, riku.voipio@linaro.org wrote:
>> From: Riku Voipio <riku.voipio@linaro.org>
>>
>> * Enable Cavium ThunderX server architecutre
>> * Enable server related options
>> * Enable CMA for DB410c DRM
>
> CMA and NUMA both require an ABI bump (which we'll do at some point
> before release, but probably not the next upload).
>
>> * Some missing gpio driver enabled in upstream defconfig
>> * DT cpufreq, spidev and missing DB410c audio setting
>> ---
> [...]
>> +##
>> +## file: drivers/base/Kconfig
>> +##
>> +CONFIG_DMA_CMA=y
>> +CONFIG_CMA_SIZE_MBYTES=64
>
> I notice this is higher than the default (16).  Is it a sensible
> default for all/most platforms that will need CMA?  What about
> platforms that don't use CMA at all, where the CMA zone will be wasted?

CMA memory isn't wasted. It is populated with movable pages until a
CMA user needs a continuous block from it. Userspace (unless mlocked)
and cache/buffers are all movable, so I don't think CMA would be
underutilized in memory pressure scenarios.

16M was not enough for getting DRM display on dragonboard 410c. I can
check what is the minimum needed.

> [...]
>>  @@ -682,6 +734,18 @@ CONFIG_USB_DWC3_DUAL_ROLE=y
>>  ## file: drivers/usb/gadget/Kconfig
>>  ##
>>  CONFIG_USB_GADGET=m
>> +CONFIG_USB_CONFIGFS=m
>
> I don't think that does anything useful unless we also enable some more
> CONFIG_USB_CONFIGFS_* options.

Gah, the set of configfs, functionfs and gadgetfs is so confusing here..

>> +
>> +##
>> +## file: drivers/usb/gadget/legacy/Kconfig
>> +##
>> +CONFIG_USB_ETH=m
>> +CONFIG_USB_ETH_RNDIS=y
>> +CONFIG_USB_GADGETFS=m
>> +CONFIG_USB_FUNCTIONFS=m
>> +CONFIG_USB_FUNCTIONFS_ETH=y
>> +CONFIG_USB_FUNCTIONFS_RNDIS=y
>> +CONFIG_USB_FUNCTIONFS_GENERIC=y
> [...]
>
> I think the gadget config should be consolidated in
> debian/config/config, leaving individual architectures to enable only
> CONFIG_USB_GADGET and driver-specific symbols for gadget support.  Can
> you do that as a preparatory patch?

Ok, I'll have a look.

Riku

Back to linux.debian.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v2] [arm64] Add more options riku.voipio@linaro.org - 2017-01-13 16:00 +0100
  Re: [PATCH v2] [arm64] Add more options Riku Voipio <riku.voipio@iki.fi> - 2017-01-23 10:00 +0100
  Re: [PATCH v2] [arm64] Add more options Ben Hutchings <ben@decadent.org.uk> - 2017-01-24 03:30 +0100
    Re: [PATCH v2] [arm64] Add more options Riku Voipio <riku.voipio@linaro.org> - 2017-01-24 11:00 +0100
      Re: [PATCH v2] [arm64] Add more options Ben Hutchings <ben@decadent.org.uk> - 2017-01-24 13:30 +0100

csiph-web