linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

[PATCH 00/10] CPUFreq: Fixes & Cleanups for 3.12

by Viresh Kumar

Hi Rafael, This patchset tries to fix & cleanup many existing cpufreq core issues. First four patches tries to cleanup basic problems in cpufreq core. Its first patch was earlier sent separately but now is part of this series. Fifth patch was also sent earlier as reply to your patches and was reviewed by Srivatsa. Sixth patch was picked from Lukasz's patchset on introducing software "boost" feature in core. It will be used by this patchset. And last four are the most significant part of this set. They try to make many things simple and robust. This is rebased of your bleeding-edge branch + two patches from you: 18a6b03 cpufreq: Avoid double kobject_put() for the same kobject in error code path d0cde63 cpufreq: Do not hold driver module references for additional policy CPUs abe513f Merge branch 'acpi-sleep-next' into linux-next They are also pushed in my cpufreq-next branch -- viresh Lukasz Majewski (1): cpufreq: Store cpufreq policies in a list Viresh Kumar (9): cpufreq: Cleanup header files included in core cpufreq: Re-arrange declarations in cpufreq.h cpufreq: Give consistent names for struct cpufreq_policy * cpufreq: Use sizeof(*ptr) form for finding size of a struct cpufreq: Pass policy to cpufreq_add_policy_cpu() cpufreq: Use cpufreq_policy_list for iterating over policies cpufreq: Fix broken usage of governor->owner's refcount cpufreq: Don't use cpufreq_driver->owner's refcount to protect critical sections cpufreq: Remove struct cpufreq_driver's owner field Documentation/cpu-freq/cpu-drivers.txt | 2 - drivers/cpufreq/acpi-cpufreq.c | 5 +- drivers/cpufreq/at32ap-cpufreq.c | 1 - drivers/cpufreq/blackfin-cpufreq.c | 1 - drivers/cpufreq/cpufreq-nforce2.c | 1 - drivers/cpufreq/cpufreq.c | 389 +++++++++++++++------------------ drivers/cpufreq/cpufreq_conservative.c | 14 +- drivers/cpufreq/cpufreq_governor.c | 6 - drivers/cpufreq/cpufreq_governor.h | 7 +- drivers/cpufreq/cpufreq_ondemand.c | 24 +- drivers/cpufreq/cpufreq_performance.c | 3 +- drivers/cpufreq/cpufreq_powersave.c | 3 +- drivers/cpufreq/cpufreq_stats.c | 25 +-- drivers/cpufreq/cris-artpec3-cpufreq.c | 1 - drivers/cpufreq/cris-etraxfs-cpufreq.c | 1 - drivers/cpufreq/e_powersaver.c | 5 +- drivers/cpufreq/elanfreq.c | 1 - drivers/cpufreq/exynos-cpufreq.c | 2 +- drivers/cpufreq/freq_table.c | 4 +- drivers/cpufreq/gx-suspmod.c | 3 +- drivers/cpufreq/ia64-acpi-cpufreq.c | 5 +- drivers/cpufreq/intel_pstate.c | 1 - drivers/cpufreq/kirkwood-cpufreq.c | 1 - drivers/cpufreq/longhaul.c | 1 - drivers/cpufreq/longrun.c | 1 - drivers/cpufreq/loongson2_cpufreq.c | 1 - drivers/cpufreq/maple-cpufreq.c | 1 - drivers/cpufreq/p4-clockmod.c | 1 - drivers/cpufreq/pasemi-cpufreq.c | 1 - drivers/cpufreq/pcc-cpufreq.c | 1 - drivers/cpufreq/pmac32-cpufreq.c | 1 - drivers/cpufreq/pmac64-cpufreq.c | 6 +- drivers/cpufreq/powernow-k6.c | 1 - drivers/cpufreq/powernow-k7.c | 14 +- drivers/cpufreq/powernow-k8.c | 7 +- drivers/cpufreq/ppc-corenet-cpufreq.c | 1 - drivers/cpufreq/ppc_cbe_cpufreq.c | 1 - drivers/cpufreq/s3c2416-cpufreq.c | 1 - drivers/cpufreq/s3c24xx-cpufreq.c | 6 +- drivers/cpufreq/s3c64xx-cpufreq.c | 1 - drivers/cpufreq/sc520_freq.c | 1 - drivers/cpufreq/sh-cpufreq.c | 1 - drivers/cpufreq/sparc-us2e-cpufreq.c | 6 +- drivers/cpufreq/sparc-us3-cpufreq.c | 6 +- drivers/cpufreq/speedstep-centrino.c | 1 - drivers/cpufreq/speedstep-ich.c | 1 - drivers/cpufreq/speedstep-smi.c | 1 - include/linux/cpufreq.h | 383 +++++++++++++++----------------- 48 files changed, 409 insertions(+), 542 deletions(-) -- 1.7.12.rc2.18.g61b472e

12 years, 1 month

[PATCH] MFD: Make VEXPRESS MFD controller depends on VEXPRESS systems

by Manjunath Goudar

This patch adds a Kconfig dependency on an ARCH_VEXPRESS(it is for both ARM and ARM64) or ARCH_VEXPRESS_CA9X being available before VEXPRESS_CONFIG can be enabled. Without this patch,build system can lead to issues. This was discovered during randconfig testing, in which VEXPRESS_CONFIG was enabled w/o ARCH_VEXPRESS or VEXPRESS_CONFIG being enabled,leading to the following error: CC drivers/mfd/vexpress-config.o drivers/mfd/vexpress-config.c: In function ‘__vexpress_config_func_get’: drivers/mfd/vexpress-config.c:117:4: error: implicit declaration of function ‘of_find_node_by_phandle’ [-Werror=implicit-function-declaration] bridge_node = of_find_node_by_phandle( ^ drivers/mfd/vexpress-config.c:117:16: warning: assignment makes pointer from integer without a cast [enabled by default] bridge_node = of_find_node_by_phandle( Signed-off-by: Manjunath Goudar <manjunath.goudar(a)linaro.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Deepak Saxena <dsaxena(a)linaro.org> Cc: Samuel Ortiz <sameo(a)linux.intel.com> Cc: Lee Jones <lee.jones(a)linaro.org> --- drivers/mfd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 633ee43..c9202f6 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1174,7 +1174,7 @@ endmenu config VEXPRESS_CONFIG bool "ARM Versatile Express platform infrastructure" - depends on ARM || ARM64 + depends on ARCH_VEXPRESS || ARCH_VEXPRESS_CA9X4 help Platform configuration infrastructure for the ARM Ltd. Versatile Express. -- 1.7.9.5

12 years, 1 month

[PATCH v3] drm/exynos: Add fallback option to get non physically continous memory for fb

by Vikas Sajjan

While trying to get boot-logo up on exynos5420 SMDK which has eDP panel connected with resolution 2560x1600, following error occured even with IOMMU enabled: [0.880000] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer. [0.890000] [drm] Initialized exynos 1.0.0 20110530 on minor 0 To address the cases where physically continous memory MAY NOT be a mandatory requirement for fb, the patch adds a feature to get non physically continous memory for fb if IOMMU is supported and if CONTIG memory allocation fails. Signed-off-by: Vikas Sajjan <vikas.sajjan(a)linaro.org> Signed-off-by: Arun Kumar <arun.kk(a)samsung.com> Reviewed-by: Rob Clark <robdclark(a)gmail.com> --- changes since v2: - addressed comments given by Tomasz Figa <tomasz.figa(a)gmail.com>. changes since v1: - Modified to add the fallback patch if CONTIG alloc fails as suggested by Rob Clark robdclark(a)gmail.com and Tomasz Figa <tomasz.figa(a)gmail.com>. - changed the commit message. --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..faec77e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -16,6 +16,7 @@ #include <drm/drm_crtc.h> #include <drm/drm_fb_helper.h> #include <drm/drm_crtc_helper.h> +#include <drm/exynos_drm.h> #include "exynos_drm_drv.h" #include "exynos_drm_fb.h" @@ -165,8 +166,17 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height; - /* 0 means to allocate physically continuous memory */ - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size); + exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size); + /* + * If IOMMU is supported then try to get buffer from non physically + * continous memory area. + */ + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) { + dev_warn(&pdev->dev, "contiguous FB allocation failed, falling back to non-contiguous\n"); + exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_NONCONTIG, + size); + } + if (IS_ERR(exynos_gem_obj)) { ret = PTR_ERR(exynos_gem_obj); goto err_release_framebuffer; -- 1.7.9.5

12 years, 1 month

RE: power measurement

by Comaschi, F.

Dear Mike, yes I have seen Andy's presentation about using AEP, and I had the impression that some measurements would have been possible on my board. Could you tell me which is the exact reason why it is more advisable to use a NI DAQ rather than a AEP? I thought that an AEP would have integrated better with the ARM development chain of DS5. Also, could you please tell me what do you exactly mean by "Solder sense resistors across exposed capacitors"? Does it mean inserting a shunt resistors in series to an existing capacitor on the board? Would you or somebody else be able to suggest me any of such capacitors on the Arndale board? According to Andy' s presentation, I thought that the best way to do power measurement was rather looking for inductors on the input side of power regulators, and replace those ones with shunt resistors. Looking at the enclosed schematic, Andy told me that unfortunately it seems like the Arndale 5250 does not present any suitable spot where to perform accurate power measurements. Could you please tell me more about this? Thanks again for all the provided information. Best regards, Francesco ________________________________________ From: Mike Turquette [mike.turquette(a)linaro.org] Sent: Wednesday, July 31, 2013 5:58 AM To: Comaschi, F. Subject: Re: power measurement Quoting Comaschi, F. (2013-07-10 05:49:36) > Dear Mike, > > I am Francesco Comaschi, a researcher at Eindhoven University of Technology. I am sending you this email because my group is interested in purchasing an ARM-powered board where to measure power consumption with the highest accuracy possible. > Ideally, the board we are looking for has the following characteristics: > > -) options for power-saving strategies (DVFS and power gating); > -) options for measuring power consumption on the board (possibly via software, maybe using lm_sensors), or via hardware otherwise (maybe using ARM Energy Probe?); > -) support available: since I do not have much experience, i would rather choose an option where either some work has already been done in terms of power management/power measurements, or some sort of support would be guaranteed (for example, regarding the Arndale board I could not get to work the DVFS through Linaro, and so far I didn'get any answer/feed-back from In Signal). > > Also, if you have any documentation/tutorial/reference to suggest me in order to understand how to properly perform DVFS/power gating on one of the boards supported by Linaro, I would be really grateful. > I was considering, among the others, the Arndale dual-board (that we already have), the Origen quad-core board and the Panda board. Also the Versatile Express family from ARM is very attractive of course, but terribly expensive. Hi Francesco, Arndale and Panda are both good options which have some support upstream for DVFS and power gating. > I have read about the possibility of using the AEP to measure energy on device: > http://www.linaro.org/documents/download/3f44bb2b53ebd7ef498202d496c8cadd50… > and I was wandering if anything similar has been already done on the Origen and the Arndale. AEP is very limiting. Did you see Andy Gross' presentation on using the AEP? It might be good for observing some DVFS transitions, but is essentially useless for high-accuracy low-power idle transitions. It is important to know that measuring high-performance workloads is not the same as measuing low power workloads. You might choose different resistor values depending on whether you are interested in measuring active frequency scaling versus idle power gating. There is still no easy way to do this. I suggest purchasing a National Instruments DAQ, one of the USB 6000 series should be good. Solder sense resistors across exposed capacitors on the boards and measure that way. It is how most of us do it when we want to get serious about measuring power. If you have further questions please Cc the Linux ARM kernel mailing list. It means more people can answer your questions and future researchers can benefit from your correspondence. Regards, Mike > > Also, from this page: > https://wiki.linaro.org/WorkingGroups/PowerManagement/Matrix1105 > is is not clear to me if the cpu_idle and cpu_freq frameworks (which I think are used for power gating and DVFS respectively) are up and running on the mentioned boards, and if it would be possible to manage DVFS and power-gating directly from inside my application. > > Sorry for all the questions, but any help would be very much appreciated. > > Thanks in advance for your kind attention, > > Best regards, > > Francesco Comaschi

12 years, 1 month

[PATCH V2] drm/exynos: Add fallback option to get non physically continous memory for fb

by Vikas Sajjan

While trying to get boot-logo up on exynos5420 SMDK which has eDP panel connected with resolution 2560x1600, following error occured even with IOMMU enabled: [0.880000] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer. [0.890000] [drm] Initialized exynos 1.0.0 20110530 on minor 0 To address the case where physically continous memory MAY NOT be a mandatory requirement for fb, the patch adds a feature to get non physically continous memory for fb if IOMMU is supported and if CONTIG memory allocation fails. Signed-off-by: Vikas Sajjan <vikas.sajjan(a)linaro.org> Signed-off-by: Arun Kumar <arun.kk(a)samsung.com> --- changes since v1: - Modified to add the fallback patch if CONTIG alloc fails as suggested by Rob Clark robdclark(a)gmail.com and Tomasz Figa <tomasz.figa(a)gmail.com>. - changed the commit message. --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..9a4b886 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -16,6 +16,7 @@ #include <drm/drm_crtc.h> #include <drm/drm_fb_helper.h> #include <drm/drm_crtc_helper.h> +#include <drm/exynos_drm.h> #include "exynos_drm_drv.h" #include "exynos_drm_fb.h" @@ -165,11 +166,21 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height; - /* 0 means to allocate physically continuous memory */ - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size); + exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size); if (IS_ERR(exynos_gem_obj)) { - ret = PTR_ERR(exynos_gem_obj); - goto err_release_framebuffer; + /* + * If IOMMU is supported then try to get buffer from + * non-continous memory area + */ + if (is_drm_iommu_supported(dev)) + exynos_gem_obj = exynos_drm_gem_create(dev, + EXYNOS_BO_NONCONTIG, size); + if (IS_ERR(exynos_gem_obj)) { + ret = PTR_ERR(exynos_gem_obj); + goto err_release_framebuffer; + } + dev_warn(&pdev->dev, "exynos_gem_obj for FB is allocated with\n" + "non physically continuous memory\n"); } exynos_fbdev->exynos_gem_obj = exynos_gem_obj; -- 1.7.9.5

12 years, 1 month

Re: [PATCH] MM: Make Contiguous Memory Allocator depends on MMU

by Manjunath Goudar

On 4 August 2013 13:24, Wanpeng Li <liwanp(a)linux.vnet.ibm.com> wrote: > On Sun, Aug 04, 2013 at 10:41:01AM +0530, Manjunath Goudar wrote: > >s patch adds a Kconfig dependency on an MMU being available before > >CMA can be enabled. Without this patch, CMA can be enabled on an > >MMU-less system which can lead to issues. This was discovered during > >randconfig testing, in which CMA was enabled w/o MMU being enabled, > >leading to the following error: > > > > CC mm/migrate.o > >mm/migrate.c: In function ‘remove_migration_pte’: > >mm/migrate.c:134:3: error: implicit declaration of function > ‘pmd_trans_huge’ > >[-Werror=implicit-function-declaration] > > if (pmd_trans_huge(*pmd)) > > ^ > >mm/migrate.c:137:3: error: implicit declaration of function > ‘pte_offset_map’ > >[-Werror=implicit-function-declaration] > > ptep = pte_offset_map(pmd, addr); > > > > Similar one. > > http://marc.info/?l=linux-mm&m=137532486405085&w=2 In this patch MIGRATION config is not required MMU, because already CMA config depends on MMU and HAVE_MEMBLOCK if both are true then only selecting MIGRATION and MEMORY_ISOLATION. > > > >Signed-off-by: Manjunath Goudar <manjunath.goudar(a)linaro.org> > >Acked-by: Arnd Bergmann <arnd(a)linaro.org> > >Cc: Deepak Saxena <dsaxena(a)linaro.org> > >Cc: IWAMOTO Toshihiro <iwamoto(a)valinux.co.jp> > >Cc: Hirokazu Takahashi <taka(a)valinux.co.jp> > >Cc: Dave Hansen <haveblue(a)us.ibm.com> > >Cc: linux-mm(a)kvack.org > >Cc: Johannes Weiner <hannes(a)cmpxchg.org> > >Cc: Michal Hocko <mhocko(a)suse.cz> > >Cc: Balbir Singh <bsingharora(a)gmail.com> > >Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> > >--- > > mm/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/mm/Kconfig b/mm/Kconfig > >index 256bfd0..ad6b98e 100644 > >--- a/mm/Kconfig > >+++ b/mm/Kconfig > >@@ -522,7 +522,7 @@ config MEM_SOFT_DIRTY > > > > config CMA > > bool "Contiguous Memory Allocator" > >- depends on HAVE_MEMBLOCK > >+ depends on MMU && HAVE_MEMBLOCK > > select MIGRATION > > select MEMORY_ISOLATION > > help > >-- > >1.7.9.5 > > > >-- > >To unsubscribe, send a message with 'unsubscribe linux-mm' in > >the body to majordomo(a)kvack.org. For more info on Linux MM, > >see: http://www.linux-mm.org/ . > >Don't email: <a href=mailto:"dont(a)kvack.org"> email(a)kvack.org </a> > > Thanks Manjunath Goudar

12 years, 1 month

Question about HMP profile test with linaro 13.06

by Wenna Zhang

Hi list, I am profiling data with linaro 13.06 image on TC2, According to the white paper ( Advances_in_big LITTLE_Technology_for_Power_and_Energy_Savings.pdf), Profile test on energy comsumption and relative page load speed get below data: [cid:image001.png@01CE8ECD.4DD35B20] I get some questions here: 1. What is your web browser benchmark used for test ? what is the browser benchmark setting? Do you get 2 seconds delay stay on each web page ? 2. Which governor do you use for test ? is it interactive governor or fixed frequency ? 3. When I test with Coretex-A7 image , I find Cortex-CA15 still have energy through interface : /sys/devices/dcc.5/energy.22/energy1_input, I think it is abnormal. Do you get same problem here ? Best Regards -------------------------------------------------- Wenna Zhang (张文娜) BSP Validation Team Tel: 6194 4202 Email: zhangwn(a)marvell.com<mailto:zhangwn@marvell.com>

12 years, 1 month

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

by Vikas Sajjan

While trying to get boot-logo up on exynos5420 SMDK which has eDP panel connected with resolution 2560x1600, following error occured even with IOMMU enabled: [0.880000] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer. [0.890000] [drm] Initialized exynos 1.0.0 20110530 on minor 0 This patch fixes the issue by adding a check for IOMMU. Signed-off-by: Vikas Sajjan <vikas.sajjan(a)linaro.org> Signed-off-by: Arun Kumar <arun.kk(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a86666 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -16,6 +16,7 @@ #include <drm/drm_crtc.h> #include <drm/drm_fb_helper.h> #include <drm/drm_crtc_helper.h> +#include <drm/exynos_drm.h> #include "exynos_drm_drv.h" #include "exynos_drm_fb.h" @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev; unsigned long size; int ret; + unsigned int flag; DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n", sizes->surface_width, sizes->surface_height, @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height; /* 0 means to allocate physically continuous memory */ - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size); + if (!is_drm_iommu_supported(dev)) + flag = 0; + else + flag = EXYNOS_BO_NONCONTIG; + + exynos_gem_obj = exynos_drm_gem_create(dev, flag, size); if (IS_ERR(exynos_gem_obj)) { ret = PTR_ERR(exynos_gem_obj); goto err_release_framebuffer; -- 1.7.9.5

12 years, 1 month

[PATCH] MM: Make Contiguous Memory Allocator depends on MMU

by Manjunath Goudar

s patch adds a Kconfig dependency on an MMU being available before CMA can be enabled. Without this patch, CMA can be enabled on an MMU-less system which can lead to issues. This was discovered during randconfig testing, in which CMA was enabled w/o MMU being enabled, leading to the following error: CC mm/migrate.o mm/migrate.c: In function ‘remove_migration_pte’: mm/migrate.c:134:3: error: implicit declaration of function ‘pmd_trans_huge’ [-Werror=implicit-function-declaration] if (pmd_trans_huge(*pmd)) ^ mm/migrate.c:137:3: error: implicit declaration of function ‘pte_offset_map’ [-Werror=implicit-function-declaration] ptep = pte_offset_map(pmd, addr); Signed-off-by: Manjunath Goudar <manjunath.goudar(a)linaro.org> Acked-by: Arnd Bergmann <arnd(a)linaro.org> Cc: Deepak Saxena <dsaxena(a)linaro.org> Cc: IWAMOTO Toshihiro <iwamoto(a)valinux.co.jp> Cc: Hirokazu Takahashi <taka(a)valinux.co.jp> Cc: Dave Hansen <haveblue(a)us.ibm.com> Cc: linux-mm(a)kvack.org Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.cz> Cc: Balbir Singh <bsingharora(a)gmail.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> --- mm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/Kconfig b/mm/Kconfig index 256bfd0..ad6b98e 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -522,7 +522,7 @@ config MEM_SOFT_DIRTY config CMA bool "Contiguous Memory Allocator" - depends on HAVE_MEMBLOCK + depends on MMU && HAVE_MEMBLOCK select MIGRATION select MEMORY_ISOLATION help -- 1.7.9.5

12 years, 1 month

Re: [PATCH] MM: Make Contiguous Memory Allocator depends on MMU

by Manjunath Goudar

On 4 August 2013 13:24, Wanpeng Li <liwanp(a)linux.vnet.ibm.com> wrote: > On Sun, Aug 04, 2013 at 10:41:01AM +0530, Manjunath Goudar wrote: > >s patch adds a Kconfig dependency on an MMU being available before > >CMA can be enabled. Without this patch, CMA can be enabled on an > >MMU-less system which can lead to issues. This was discovered during > >randconfig testing, in which CMA was enabled w/o MMU being enabled, > >leading to the following error: > > > > CC mm/migrate.o > >mm/migrate.c: In function ‘remove_migration_pte’: > >mm/migrate.c:134:3: error: implicit declaration of function > ‘pmd_trans_huge’ > >[-Werror=implicit-function-declaration] > > if (pmd_trans_huge(*pmd)) > > ^ > >mm/migrate.c:137:3: error: implicit declaration of function > ‘pte_offset_map’ > >[-Werror=implicit-function-declaration] > > ptep = pte_offset_map(pmd, addr); > > > > Similar one. > > http://marc.info/?l=linux-mm&m=137532486405085&w=2 Ok thank you for your information. > > > >Signed-off-by: Manjunath Goudar <manjunath.goudar(a)linaro.org> > >Acked-by: Arnd Bergmann <arnd(a)linaro.org> > >Cc: Deepak Saxena <dsaxena(a)linaro.org> > >Cc: IWAMOTO Toshihiro <iwamoto(a)valinux.co.jp> > >Cc: Hirokazu Takahashi <taka(a)valinux.co.jp> > >Cc: Dave Hansen <haveblue(a)us.ibm.com> > >Cc: linux-mm(a)kvack.org > >Cc: Johannes Weiner <hannes(a)cmpxchg.org> > >Cc: Michal Hocko <mhocko(a)suse.cz> > >Cc: Balbir Singh <bsingharora(a)gmail.com> > >Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> > >--- > > mm/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/mm/Kconfig b/mm/Kconfig > >index 256bfd0..ad6b98e 100644 > >--- a/mm/Kconfig > >+++ b/mm/Kconfig > >@@ -522,7 +522,7 @@ config MEM_SOFT_DIRTY > > > > config CMA > > bool "Contiguous Memory Allocator" > >- depends on HAVE_MEMBLOCK > >+ depends on MMU && HAVE_MEMBLOCK > > select MIGRATION > > select MEMORY_ISOLATION > > help > >-- > >1.7.9.5 > > > >-- > >To unsubscribe, send a message with 'unsubscribe linux-mm' in > >the body to majordomo(a)kvack.org. For more info on Linux MM, > >see: http://www.linux-mm.org/ . > >Don't email: <a href=mailto:"dont(a)kvack.org"> email(a)kvack.org </a> > > Thanks Manjunath Goudar

12 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel