Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #56725
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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