- linaro-kernel - lists.linaro.org

by Naresh Kamboju

Hi, linux-next daily kernel CI loop reported multiplatform build failure. If you feel it is a bug in linux-next, I will report this to lkml. Error log: ------------ 02:29:37 LINK vmlinux 02:29:37 LD vmlinux.o 02:29:37 MODPOST vmlinux.o 02:29:37 GEN .version 02:29:37 CHK include/generated/compile.h 02:29:37 UPD include/generated/compile.h 02:29:37 CC init/version.o 02:29:38 LD init/built-in.o 02:29:38 drivers/built-in.o: In function `drm_lastclose': 02:29:38 :(.text+0x9fbbc): undefined reference to `drm_agp_clear' 02:29:38 make[1]: *** [vmlinux] Error 1 02:29:38 make: *** [sub-make] Error 2 02:29:38 + cleanup_exit 02:29:38 + cd /mnt/ci_build/workspace/linux-next/hwpack/multiplatform/label/kernel_cloud 02:29:38 + rm -rf lci-build-tools 02:29:38 + rm -rf builddir-3.11.0-rc4-linaro-multiplatform 02:29:38 Build step 'Execute shell' marked build as failure 02:29:38 Finished: FAILURE Kernel build env: ---------------------- 02:21:40 ++ echo KERNEL_VERSION=3.11.0-rc4 02:21:40 ++ echo KERNEL_GIT=git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 02:21:40 ++ echo KERNEL_COMMIT=20bf249c2d909c8530615c46d0f9aaa90c73498f 02:21:40 +++ git show -s --format=%cD HEAD 02:21:40 ++ echo COMMIT_TIME=Thu, 8 Aug 2013 16:49:48 +1000 02:21:40 ++ echo KERNEL_NAME=linux-next/hwpack=multiplatform,label=kernel ... 2:21:45 + make ARCH=arm O=builddir-3.11.0-rc4-linaro-multiplatform KERNELVERSION=3.11.0-rc4-linaro-multiplatform KERNELRELEASE=3.11.0-rc4-linaro-multiplatform CROSS_COMPILE=/mnt/ci_build/workspace/linux-next/hwpack/multiplatform/label/kernel_cloud/toolchain/bin/arm-linux-gnueabihf- multi_v7_defconfig Failed build link: ---------------------- https://ci.linaro.org/jenkins/job/linux-next/124/hwpack=multiplatform,label… Best regards Naresh Kamboju

11 years, 10 months

3
2
0 0

[PATCH] ARM: KVM: Fix unaligned unmap_range leak

by Christoffer Dall

The unmap_range function did not properly cover the case when the start address was not aligned to PMD_SIZE or PUD_SIZE and an entire pte table or pmd table was cleared, causing us to leak memory when incrementing the addr. The fix is to always move onto the next page table entry boundary instead of adding the full size of the VA range covered by the corresponding table level entry. Acked-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> --- arch/arm/kvm/mmu.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index ca6bea4..80a83ec 100644 --- a/arch/arm/kvm/mmu.c +++ b/arch/arm/kvm/mmu.c @@ -132,37 +132,37 @@ static void unmap_range(struct kvm *kvm, pgd_t *pgdp, pmd_t *pmd; pte_t *pte; unsigned long long addr = start, end = start + size; - u64 range; + u64 next; while (addr < end) { pgd = pgdp + pgd_index(addr); pud = pud_offset(pgd, addr); if (pud_none(*pud)) { - addr += PUD_SIZE; + addr = pud_addr_end(addr, end); continue; } pmd = pmd_offset(pud, addr); if (pmd_none(*pmd)) { - addr += PMD_SIZE; + addr = pmd_addr_end(addr, end); continue; } pte = pte_offset_kernel(pmd, addr); clear_pte_entry(kvm, pte, addr); - range = PAGE_SIZE; + next = addr + PAGE_SIZE; /* If we emptied the pte, walk back up the ladder */ if (pte_empty(pte)) { clear_pmd_entry(kvm, pmd, addr); - range = PMD_SIZE; + next = pmd_addr_end(addr, end); if (pmd_empty(pmd)) { clear_pud_entry(kvm, pud, addr); - range = PUD_SIZE; + next = pud_addr_end(addr, end); } } - addr += range; + addr = next; } } -- 1.7.10.4

11 years, 10 months

1
0
0 0

[PATCH] ARM: KVM: Fix kvm_set_pte assignment

by Christoffer Dall

THe kvm_set_pte function was actually assigning the entire struct to the structure member, which should work because the structure only has that one member, but it is still not very nice. Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> --- arch/arm/include/asm/kvm_mmu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h index 472ac70..9b28c41 100644 --- a/arch/arm/include/asm/kvm_mmu.h +++ b/arch/arm/include/asm/kvm_mmu.h @@ -64,7 +64,7 @@ void kvm_clear_hyp_idmap(void); static inline void kvm_set_pte(pte_t *pte, pte_t new_pte) { - pte_val(*pte) = new_pte; + *pte = new_pte; /* * flush_pmd_entry just takes a void pointer and cleans the necessary * cache entries, so we can reuse the function for ptes. -- 1.7.10.4

11 years, 10 months

1
0
0 0

[PATCH 0/6] Tegra: Use cpufreq-cpu0 driver

by Viresh Kumar

Hi Stephen, This is the first attempt to get rid of tegra-cpufreq driver. This patchset tries to add supporting infrastructure for tegra to use cpufreq-cpu0 driver. I don't have hardware to test it and so is compiled tested only.. Few bits may be missing as I couldn't think of all aspects and so may need your help getting them fixed. Once this is tested by you, I would like to take it through my ARM cpufreq tree if nobody else has a problem with it. Thanks -- Viresh. Viresh Kumar (6): clk: Tegra: Add CPU0 clock driver ARM: Tegra: Add CPU's OPPs for using cpufreq-cpu0 driver ARM: Tegra: Enable OPP library ARM: Tegra: defconfig: select cpufreq-cpu0 driver ARM: Tegra: start using cpufreq-cpu0 driver cpufreq: Tegra: Remove tegra-cpufreq driver arch/arm/boot/dts/tegra114.dtsi | 12 ++ arch/arm/boot/dts/tegra20.dtsi | 12 ++ arch/arm/boot/dts/tegra30.dtsi | 12 ++ arch/arm/configs/tegra_defconfig | 1 + arch/arm/mach-tegra/Kconfig | 2 + arch/arm/mach-tegra/tegra.c | 2 + drivers/clk/tegra/Makefile | 1 + drivers/clk/tegra/clk-cpu.c | 164 ++++++++++++++++++++++ drivers/clk/tegra/clk-tegra30.c | 4 + drivers/cpufreq/Kconfig.arm | 8 -- drivers/cpufreq/Makefile | 1 - drivers/cpufreq/tegra-cpufreq.c | 291 --------------------------------------- include/linux/clk/tegra.h | 1 + 13 files changed, 211 insertions(+), 300 deletions(-) create mode 100644 drivers/clk/tegra/clk-cpu.c delete mode 100644 drivers/cpufreq/tegra-cpufreq.c -- 1.7.12.rc2.18.g61b472e

11 years, 10 months

6
35
0 0

[PATCH] drm/agp: Fix build for non-AGP platforms

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c) broke the build for platforms which do not have AGP since it moved the AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced unconditionally in drm_drv.c. This causes build failures for embedded SoCs which use DRM but do not have AGP. Fix this by providing stub static inlines in the header. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- include/drm/drmP.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index fba5473..e7f7da0 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -1453,6 +1453,7 @@ extern int drm_modeset_ctl(struct drm_device *dev, void *data, struct drm_file *file_priv); /* AGP/GART support (drm_agpsupport.h) */ +#if __OS_HAS_AGP extern struct drm_agp_head *drm_agp_init(struct drm_device *dev); extern void drm_agp_destroy(struct drm_agp_head *agp); extern void drm_agp_clear(struct drm_device *dev); @@ -1480,6 +1481,10 @@ extern int drm_agp_unbind_ioctl(struct drm_device *dev, void *data, extern int drm_agp_bind(struct drm_device *dev, struct drm_agp_binding *request); extern int drm_agp_bind_ioctl(struct drm_device *dev, void *data, struct drm_file *file_priv); +#else +static inline void drm_agp_destroy(struct drm_agp_head *agp) { } +static inline void drm_agp_clear(struct drm_device *dev) { } +#endif /* Stub support (drm_stub.h) */ extern int drm_setmaster_ioctl(struct drm_device *dev, void *data, -- 1.8.4.rc1

11 years, 10 months

2
1
0 0

[PATCH] kvm-host.conf: enable guest OS networking

by Kim Phillips

Bridge and TUN/TAP support are needed for enabling networking with a guest OS. Signed-off-by: Kim Phillips <kim.phillips(a)linaro.org> --- ultimately targeted for the LNG kernel, but seeking acceptance in the upstream linaro kernel linaro/configs/kvm-host.conf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/linaro/configs/kvm-host.conf b/linaro/configs/kvm-host.conf index 21a40e0..0e4c21a 100644 --- a/linaro/configs/kvm-host.conf +++ b/linaro/configs/kvm-host.conf @@ -9,3 +9,5 @@ CONFIG_KVM_ARM_VGIC=y CONFIG_KVM_MMIO=y CONFIG_KVM=y CONFIG_BLK_DEV_NBD=m +CONFIG_BRIDGE=y +CONFIG_TUN=y -- 1.8.3.3

11 years, 10 months

2
1
0 0

[PATCH] OPP: Export opp_add()

by Viresh Kumar

Export opp_add() so that modules can use it. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/base/power/opp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c index c8ec186..ef89897 100644 --- a/drivers/base/power/opp.c +++ b/drivers/base/power/opp.c @@ -460,6 +460,7 @@ int opp_add(struct device *dev, unsigned long freq, unsigned long u_volt) srcu_notifier_call_chain(&dev_opp->head, OPP_EVENT_ADD, new_opp); return 0; } +EXPORT_SYMBOL_GPL(opp_add); /** * opp_set_availability() - helper to set the availability of an opp -- 1.7.12.rc2.18.g61b472e

11 years, 10 months

4
9
0 0

[PATCH 1/2] ASoC: ad73311: Add DAPM support

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> This makes it possible to hook up other devices in boards and is required by removal of support for non-DAPM CODECs in the core. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/codecs/ad73311.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/ad73311.c b/sound/soc/codecs/ad73311.c index b1f2baf..5fac8ad 100644 --- a/sound/soc/codecs/ad73311.c +++ b/sound/soc/codecs/ad73311.c @@ -23,6 +23,21 @@ #include "ad73311.h" +static const struct snd_soc_dapm_widget ad73311_dapm_widgets[] = { +SND_SOC_DAPM_INPUT("VINP"), +SND_SOC_DAPM_INPUT("VINN"), +SND_SOC_DAPM_OUTPUT("VOUTN"), +SND_SOC_DAPM_OUTPUT("VOUTP"), +}; + +static const struct snd_soc_dapm_route ad73311_dapm_routes[] = { + { "Capture", NULL, "VINP" }, + { "Capture", NULL, "VINN" }, + + { "VOUTN", NULL, "Playback" }, + { "VOUTP", NULL, "Playback" }, +}; + static struct snd_soc_dai_driver ad73311_dai = { .name = "ad73311-hifi", .playback = { @@ -39,7 +54,12 @@ static struct snd_soc_dai_driver ad73311_dai = { .formats = SNDRV_PCM_FMTBIT_S16_LE, }, }; -static struct snd_soc_codec_driver soc_codec_dev_ad73311; +static struct snd_soc_codec_driver soc_codec_dev_ad73311 = { + .dapm_widgets = ad73311_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(ad73311_dapm_widgets), + .dapm_routes = ad73311_dapm_routes, + .num_dapm_routes = ARRAY_SIZE(ad73311_dapm_routes), +}; static int ad73311_probe(struct platform_device *pdev) { -- 1.8.4.rc1

11 years, 10 months

2
3
0 0

Re: [PATCH] cpufreq: arm-big-little: don't use cpu_last_req_freq for MP

by Jon Medhurst (Tixy)

On Wed, 2013-08-07 at 18:52 +0530, Viresh Kumar wrote: > While getting support for In-Kernel-Switcher in big LITTLE cpufreq driver we > introduced cpu_last_req_freq per-cpu variable that stores the last frequency > requested for a cpu. It was important for IKS as CPUs in the same cluster can > have separate struct cpufreq_policy associated with them and so cpufreq core may > try to set different frequencies on both CPUs of same cluster. > > But for non-IKS solution or MP we don't need to cache last requested frequency. > Currently there is a bug in code where if cpufreq_driver->get() is called for > any cpu other than policy->cpu, we are returning 0, because we set > cpu_last_req_freq only for policy->cpu and not for others. Do you know what the observable symptoms of this are? As this is a fix which needs to get into LSK I've added the linaro-kernel list to the cc so it has more public visibility. Tixy > This problem could have been fixed by setting cpu_last_req_freq for all CPUs in > policy->cpus, but that wouldn't be the best solution. Purpose of > cpufreq_driver->get() is to get exact frequency from the hardware instead of > returning cached frequency that was last requested as that is already present > with the core. > > Hence, this patch forces only IKS to use cpu_last_req_freq and not MP. We will > get the frequency from hardware when ->get() is called for MP. > > Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> > --- > drivers/cpufreq/arm_big_little.c | 27 ++++++++++++++++++--------- > 1 file changed, 18 insertions(+), 9 deletions(-) > > diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c > index f589b6c..c8de71f 100644 > --- a/drivers/cpufreq/arm_big_little.c > +++ b/drivers/cpufreq/arm_big_little.c > @@ -91,9 +91,14 @@ static unsigned int clk_get_cpu_rate(unsigned int cpu) > > static unsigned int bL_cpufreq_get_rate(unsigned int cpu) > { > - pr_debug("%s: freq: %d\n", __func__, per_cpu(cpu_last_req_freq, cpu)); > + if (is_bL_switching_enabled()) { > + pr_debug("%s: freq: %d\n", __func__, per_cpu(cpu_last_req_freq, > + cpu)); > > - return per_cpu(cpu_last_req_freq, cpu); > + return per_cpu(cpu_last_req_freq, cpu); > + } else { > + return clk_get_cpu_rate(cpu); > + } > } > > static unsigned int > @@ -104,11 +109,11 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate) > > mutex_lock(&cluster_lock[new_cluster]); > > - prev_rate = per_cpu(cpu_last_req_freq, cpu); > - per_cpu(cpu_last_req_freq, cpu) = rate; > - per_cpu(physical_cluster, cpu) = new_cluster; > - > if (is_bL_switching_enabled()) { > + prev_rate = per_cpu(cpu_last_req_freq, cpu); > + per_cpu(cpu_last_req_freq, cpu) = rate; > + per_cpu(physical_cluster, cpu) = new_cluster; > + > new_rate = find_cluster_maxfreq(new_cluster); > new_rate = ACTUAL_FREQ(new_cluster, new_rate); > } else { > @@ -122,8 +127,10 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate) > if (WARN_ON(ret)) { > pr_err("clk_set_rate failed: %d, new cluster: %d\n", ret, > new_cluster); > - per_cpu(cpu_last_req_freq, cpu) = prev_rate; > - per_cpu(physical_cluster, cpu) = old_cluster; > + if (is_bL_switching_enabled()) { > + per_cpu(cpu_last_req_freq, cpu) = prev_rate; > + per_cpu(physical_cluster, cpu) = old_cluster; > + } > > mutex_unlock(&cluster_lock[new_cluster]); > > @@ -461,7 +468,9 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy) > policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL; > > policy->cur = clk_get_cpu_rate(policy->cpu); > - per_cpu(cpu_last_req_freq, policy->cpu) = policy->cur; > + > + if (is_bL_switching_enabled()) > + per_cpu(cpu_last_req_freq, policy->cpu) = policy->cur; > > dev_info(cpu_dev, "%s: CPU %d initialized\n", __func__, policy->cpu); > return 0;

11 years, 10 months

2
9
0 0

[PATCH] ASoC: dt: Move WM8903 pin list from Tegra board binding to CODEC binding

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> The pin list is the same for any board using the CODEC. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- .../bindings/sound/nvidia,tegra-audio-wm8903.txt | 24 ++-------------------- Documentation/devicetree/bindings/sound/wm8903.txt | 19 +++++++++++++++++ 2 files changed, 21 insertions(+), 22 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt index 3bf722d..4b44dfb 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt @@ -11,28 +11,8 @@ Required properties: - nvidia,audio-routing : A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. Valid names for sources and - sinks are the WM8903's pins, and the jacks on the board: - - WM8903 pins: - - * IN1L - * IN1R - * IN2L - * IN2R - * IN3L - * IN3R - * DMICDAT - * HPOUTL - * HPOUTR - * LINEOUTL - * LINEOUTR - * LOP - * LON - * ROP - * RON - * MICBIAS - - Board connectors: + sinks are the WM8903's pins (documented in the WM8903 binding document), + and the jacks on the board: * Headphone Jack * Int Spk diff --git a/Documentation/devicetree/bindings/sound/wm8903.txt b/Documentation/devicetree/bindings/sound/wm8903.txt index f102cbc..94ec32c 100644 --- a/Documentation/devicetree/bindings/sound/wm8903.txt +++ b/Documentation/devicetree/bindings/sound/wm8903.txt @@ -28,6 +28,25 @@ Optional properties: performed. If any entry has the value 0xffffffff, that GPIO's configuration will not be modified. +Pins on the device (for linking into audio routes): + + * IN1L + * IN1R + * IN2L + * IN2R + * IN3L + * IN3R + * DMICDAT + * HPOUTL + * HPOUTR + * LINEOUTL + * LINEOUTR + * LOP + * LON + * ROP + * RON + * MICBIAS + Example: codec: wm8903@1a { -- 1.8.4.rc1

11 years, 10 months

3
2
0 0

[PATCH v2] ARM: KVM: Fix 64-bit coprocessor handling

by Christoffer Dall

The PAR was exported as CRn == 7 and CRm == 0, but in fact the primary coprocessor register number was determined by CRm for 64-bit coprocessor registers as the user space API was modeled after the coprocessor access instructions (see the ARM ARM rev. C - B3-1445). However, just changing the CRn to CRm breaks the sorting check when booting the kernel, because the internal kernel logic always treats CRn as the primary register number, and it makes the table sorting impossible to understand for humans. Alternatively we could change the logic to always have CRn == CRm, but that becomes unclear in the number of ways we do look up of a coprocessor register. We could also have a separate 64-bit table but that feels somewhat over-engineered. Instead, keep CRn the primary representation of the primary coproc. register number in-kernel and always export the primary number as CRm as per the existing user space ABI. Note: The TTBR registers just magically worked because they happened to follow the CRn(0) regs and were considered CRn(0) in the in-kernel representation. Cc: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> --- [Changes v1 -> v2]: - Use CRm64 macro as suggested by Marc Zyngier - Fix spelling issues arch/arm/kvm/coproc.c | 26 +++++++++++++++++++------- arch/arm/kvm/coproc.h | 3 +++ arch/arm/kvm/coproc_a15.c | 6 +++++- 3 files changed, 27 insertions(+), 8 deletions(-) diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c index 4a51990..db9cf69 100644 --- a/arch/arm/kvm/coproc.c +++ b/arch/arm/kvm/coproc.c @@ -146,7 +146,11 @@ static bool pm_fake(struct kvm_vcpu *vcpu, #define access_pmintenclr pm_fake /* Architected CP15 registers. - * Important: Must be sorted ascending by CRn, CRM, Op1, Op2 + * CRn denotes the primary register number, but is copied to the CRm in the + * user space API for 64-bit register access in line with the terminology used + * in the ARM ARM. + * Important: Must be sorted ascending by CRn, CRM, Op1, Op2 and with 64-bit + * registers preceding 32-bit ones. */ static const struct coproc_reg cp15_regs[] = { /* CSSELR: swapped by interrupt.S. */ @@ -154,8 +158,8 @@ static const struct coproc_reg cp15_regs[] = { NULL, reset_unknown, c0_CSSELR }, /* TTBR0/TTBR1: swapped by interrupt.S. */ - { CRm( 2), Op1( 0), is64, NULL, reset_unknown64, c2_TTBR0 }, - { CRm( 2), Op1( 1), is64, NULL, reset_unknown64, c2_TTBR1 }, + { CRm64( 2), Op1( 0), is64, NULL, reset_unknown64, c2_TTBR0 }, + { CRm64( 2), Op1( 1), is64, NULL, reset_unknown64, c2_TTBR1 }, /* TTBCR: swapped by interrupt.S. */ { CRn( 2), CRm( 0), Op1( 0), Op2( 2), is32, @@ -182,7 +186,7 @@ static const struct coproc_reg cp15_regs[] = { NULL, reset_unknown, c6_IFAR }, /* PAR swapped by interrupt.S */ - { CRn( 7), Op1( 0), is64, NULL, reset_unknown64, c7_PAR }, + { CRm64( 7), Op1( 0), is64, NULL, reset_unknown64, c7_PAR }, /* * DC{C,I,CI}SW operations: @@ -399,12 +403,13 @@ static bool index_to_params(u64 id, struct coproc_params *params) | KVM_REG_ARM_OPC1_MASK)) return false; params->is_64bit = true; - params->CRm = ((id & KVM_REG_ARM_CRM_MASK) + /* CRm to CRn: see cp15_to_index for details */ + params->CRn = ((id & KVM_REG_ARM_CRM_MASK) >> KVM_REG_ARM_CRM_SHIFT); params->Op1 = ((id & KVM_REG_ARM_OPC1_MASK) >> KVM_REG_ARM_OPC1_SHIFT); params->Op2 = 0; - params->CRn = 0; + params->CRm = 0; return true; default: return false; @@ -898,7 +903,14 @@ static u64 cp15_to_index(const struct coproc_reg *reg) if (reg->is_64) { val |= KVM_REG_SIZE_U64; val |= (reg->Op1 << KVM_REG_ARM_OPC1_SHIFT); - val |= (reg->CRm << KVM_REG_ARM_CRM_SHIFT); + /* + * CRn always denotes the primary coproc. reg. nr. for the + * in-kernel representation, but the user space API uses the + * CRm for the encoding, because it is modelled after the + * MRRC/MCRR instructions: see the ARM ARM rev. c page + * B3-1445 + */ + val |= (reg->CRn << KVM_REG_ARM_CRM_SHIFT); } else { val |= KVM_REG_SIZE_U32; val |= (reg->Op1 << KVM_REG_ARM_OPC1_SHIFT); diff --git a/arch/arm/kvm/coproc.h b/arch/arm/kvm/coproc.h index b7301d3..0461d5c 100644 --- a/arch/arm/kvm/coproc.h +++ b/arch/arm/kvm/coproc.h @@ -135,6 +135,8 @@ static inline int cmp_reg(const struct coproc_reg *i1, return -1; if (i1->CRn != i2->CRn) return i1->CRn - i2->CRn; + if (i1->is_64 != i2->is_64) + return i2->is_64 - i1->is_64; if (i1->CRm != i2->CRm) return i1->CRm - i2->CRm; if (i1->Op1 != i2->Op1) @@ -145,6 +147,7 @@ static inline int cmp_reg(const struct coproc_reg *i1, #define CRn(_x) .CRn = _x #define CRm(_x) .CRm = _x +#define CRm64(_x) .CRn = _x, .CRm = 0 #define Op1(_x) .Op1 = _x #define Op2(_x) .Op2 = _x #define is64 .is_64 = true diff --git a/arch/arm/kvm/coproc_a15.c b/arch/arm/kvm/coproc_a15.c index 685063a..cf93472 100644 --- a/arch/arm/kvm/coproc_a15.c +++ b/arch/arm/kvm/coproc_a15.c @@ -114,7 +114,11 @@ static bool access_l2ectlr(struct kvm_vcpu *vcpu, /* * A15-specific CP15 registers. - * Important: Must be sorted ascending by CRn, CRM, Op1, Op2 + * CRn denotes the primary register number, but is copied to the CRm in the + * user space API for 64-bit register access in line with the terminology used + * in the ARM ARM. + * Important: Must be sorted ascending by CRn, CRM, Op1, Op2 and with 64-bit + * registers preceding 32-bit ones. */ static const struct coproc_reg a15_regs[] = { /* MPIDR: we use VMPIDR for guest access. */ -- 1.7.10.4

11 years, 10 months

2
1
0 0

Re: [PATCH] cpufreq: exynos5440: Fix to skip when new frequency same as current

by Viresh Kumar

On 7 August 2013 17:00, Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha(a)arm.com> wrote: > Any particular reason we need this check in all drivers after your > commit: 5a1c0228 "cpufreq: Avoid calling cpufreq driver's target() > routine if target_freq == policy->cur" > > I think it can removed from all drivers, am I missing something ? Yeah.. Just a bit though :) So, cpufreq core checks this when we call target for any frequency. Now, cpufreq driver actually does a cpufreq_frequency_table_target() and so the frequency may vary than what is requested, in case requested frequency isn't picked from the table. In such cases we check it again to be sure that we aren't at this frequency already.. Earlier I thought of calling cpufreq_frequency_table_target() in the core before calling target but dropped the idea as I wasn't sure of the side effects. @Rafael: Do you see why we shouldn't/can't call cpufreq_frequency_table_target() from the core itself and so drivers never need to do it?

11 years, 10 months

2
2
0 0

[PATCH] usb/hcd: Log error code if reset() fails

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> If someone provided meaningful error codes from reset() we should tell the user what they were. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/usb/core/hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index dc1346f..c7fdf10 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -2580,7 +2580,7 @@ int usb_add_hcd(struct usb_hcd *hcd, * should already have been reset (and boot firmware kicked off etc). */ if (hcd->driver->reset && (retval = hcd->driver->reset(hcd)) < 0) { - dev_err(hcd->self.controller, "can't setup\n"); + dev_err(hcd->self.controller, "can't setup: %d\n", retval); goto err_hcd_driver_setup; } hcd->rh_pollable = 1; -- 1.8.4.rc1

11 years, 10 months

1
0
0 0

[PATCH] usb: misc: usb3503: Convert to devm_ APIs

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Saves us a bit of code. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- This depends on my previous patch "usb: misc: Fix swapped properties in usb3503 DT parsing". drivers/usb/misc/usb3503.c | 42 +++++++----------------------------------- 1 file changed, 7 insertions(+), 35 deletions(-) diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c index 4e3a2d2..41b4228 100644 --- a/drivers/usb/misc/usb3503.c +++ b/drivers/usb/misc/usb3503.c @@ -187,7 +187,7 @@ static int usb3503_probe(struct i2c_client *i2c, const struct i2c_device_id *id) const u32 *property; int len; - hub = kzalloc(sizeof(struct usb3503), GFP_KERNEL); + hub = devm_kzalloc(&i2c->dev, sizeof(struct usb3503), GFP_KERNEL); if (!hub) { dev_err(&i2c->dev, "private data alloc fail\n"); return err; @@ -229,35 +229,35 @@ static int usb3503_probe(struct i2c_client *i2c, const struct i2c_device_id *id) } if (gpio_is_valid(hub->gpio_intn)) { - err = gpio_request_one(hub->gpio_intn, + err = devm_gpio_request_one(&i2c->dev, hub->gpio_intn, GPIOF_OUT_INIT_HIGH, "usb3503 intn"); if (err) { dev_err(&i2c->dev, "unable to request GPIO %d as connect pin (%d)\n", hub->gpio_intn, err); - goto err_out; + return err; } } if (gpio_is_valid(hub->gpio_connect)) { - err = gpio_request_one(hub->gpio_connect, + err = devm_gpio_request_one(&i2c->dev, hub->gpio_connect, GPIOF_OUT_INIT_HIGH, "usb3503 connect"); if (err) { dev_err(&i2c->dev, "unable to request GPIO %d as connect pin (%d)\n", hub->gpio_connect, err); - goto err_gpio_connect; + return err; } } if (gpio_is_valid(hub->gpio_reset)) { - err = gpio_request_one(hub->gpio_reset, + err = devm_gpio_request_one(&i2c->dev, hub->gpio_reset, GPIOF_OUT_INIT_LOW, "usb3503 reset"); if (err) { dev_err(&i2c->dev, "unable to request GPIO %d as reset pin (%d)\n", hub->gpio_reset, err); - goto err_gpio_reset; + return err; } } @@ -267,33 +267,6 @@ static int usb3503_probe(struct i2c_client *i2c, const struct i2c_device_id *id) (hub->mode == USB3503_MODE_HUB) ? "hub" : "standby"); return 0; - -err_gpio_reset: - if (gpio_is_valid(hub->gpio_connect)) - gpio_free(hub->gpio_connect); -err_gpio_connect: - if (gpio_is_valid(hub->gpio_intn)) - gpio_free(hub->gpio_intn); -err_out: - kfree(hub); - - return err; -} - -static int usb3503_remove(struct i2c_client *i2c) -{ - struct usb3503 *hub = i2c_get_clientdata(i2c); - - if (gpio_is_valid(hub->gpio_intn)) - gpio_free(hub->gpio_intn); - if (gpio_is_valid(hub->gpio_connect)) - gpio_free(hub->gpio_connect); - if (gpio_is_valid(hub->gpio_reset)) - gpio_free(hub->gpio_reset); - - kfree(hub); - - return 0; } static const struct i2c_device_id usb3503_id[] = { @@ -316,7 +289,6 @@ static struct i2c_driver usb3503_driver = { .of_match_table = of_match_ptr(usb3503_of_match), }, .probe = usb3503_probe, - .remove = usb3503_remove, .id_table = usb3503_id, }; -- 1.8.4.rc1

11 years, 10 months

1
0
0 0

[PATCH 1/2] ASoC: ak4104: Add stub DAPM support

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> This makes it easer to integrate the device with other on-board components and ensures correct operation following removal of support for non-DAPM CODECs. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/codecs/ak4104.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sound/soc/codecs/ak4104.c b/sound/soc/codecs/ak4104.c index c7cfdf9..9a7c89b 100644 --- a/sound/soc/codecs/ak4104.c +++ b/sound/soc/codecs/ak4104.c @@ -51,6 +51,14 @@ struct ak4104_private { struct regmap *regmap; }; +static const struct snd_soc_dapm_widget ak4104_dapm_widgets[] = { +SND_SOC_DAPM_OUTPUT("TX"), +}; + +static const struct snd_soc_dapm_route ak4104_dapm_routes[] = { + { "TX", NULL, "Playback" }, +}; + static int ak4104_set_dai_fmt(struct snd_soc_dai *codec_dai, unsigned int format) { @@ -214,6 +222,11 @@ static int ak4104_remove(struct snd_soc_codec *codec) static struct snd_soc_codec_driver soc_codec_device_ak4104 = { .probe = ak4104_probe, .remove = ak4104_remove, + + .dapm_widgets = ak4104_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(ak4104_dapm_widgets), + .dapm_routes = ak4104_dapm_routes, + .num_dapm_routes = ARRAY_SIZE(ak4104_dapm_routes), }; static const struct regmap_config ak4104_regmap = { -- 1.8.4.rc1

11 years, 10 months

1
1
0 0

[PATCH] ASoC: ads711x: Add DAPM support

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> This makes it easier to hook into boards and ensures the driver continues to work with support for non-DAPM CODECs removed. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/codecs/ads117x.c | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/ads117x.c b/sound/soc/codecs/ads117x.c index 506d474..8f388ed 100644 --- a/sound/soc/codecs/ads117x.c +++ b/sound/soc/codecs/ads117x.c @@ -23,6 +23,28 @@ #define ADS117X_RATES (SNDRV_PCM_RATE_8000_48000) #define ADS117X_FORMATS (SNDRV_PCM_FMTBIT_S16_LE) +static const struct snd_soc_dapm_widget ads117x_dapm_widgets[] = { +SND_SOC_DAPM_INPUT("Input1"), +SND_SOC_DAPM_INPUT("Input2"), +SND_SOC_DAPM_INPUT("Input3"), +SND_SOC_DAPM_INPUT("Input4"), +SND_SOC_DAPM_INPUT("Input5"), +SND_SOC_DAPM_INPUT("Input6"), +SND_SOC_DAPM_INPUT("Input7"), +SND_SOC_DAPM_INPUT("Input8"), +}; + +static const struct snd_soc_dapm_route ads117x_dapm_routes[] = { + { "Capture", NULL, "Input1" }, + { "Capture", NULL, "Input2" }, + { "Capture", NULL, "Input3" }, + { "Capture", NULL, "Input4" }, + { "Capture", NULL, "Input5" }, + { "Capture", NULL, "Input6" }, + { "Capture", NULL, "Input7" }, + { "Capture", NULL, "Input8" }, +}; + static struct snd_soc_dai_driver ads117x_dai = { /* ADC */ .name = "ads117x-hifi", @@ -34,7 +56,12 @@ static struct snd_soc_dai_driver ads117x_dai = { .formats = ADS117X_FORMATS,}, }; -static struct snd_soc_codec_driver soc_codec_dev_ads117x; +static struct snd_soc_codec_driver soc_codec_dev_ads117x = { + .dapm_widgets = ads117x_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(ads117x_dapm_widgets), + .dapm_routes = ads117x_dapm_routes, + .num_dapm_routes = ARRAY_SIZE(ads117x_dapm_routes), +}; static int ads117x_probe(struct platform_device *pdev) { -- 1.8.4.rc1

11 years, 10 months

1
0
0 0

[PATCH] mach-ks8695/Kconfig: Make MACH_KS8695 depends on PCI

by Manjunath Goudar

From: root <root(a)si-cspbld63.lge.net> This patch adds a Kconfig dependency on MACH_KS8695,MACH_CM* or MACH_IM* being available before PCI can be enabled. Without this patch,build system can lead to issues. This was discovered during randconfig testing, without PCI if any one of MACH_KS8695,MACH_CM* or MACH_IM* being enabled, leading to the following error: LD init/built-in.o arch/arm/mach-ks8695/built-in.o: In function `og_register_pci': arch/arm/mach-ks8695/board-og.c:47:undefined reference to `ks8695_init_pci' make: *** [vmlinux] Error 1 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: Greg Ungerer <gerg(a)uclinux.org> Cc: linux-arm-kernel(a)lists.infradead.org --- arch/arm/mach-ks8695/Kconfig | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-ks8695/Kconfig b/arch/arm/mach-ks8695/Kconfig index a545976..29d7d9f 100644 --- a/arch/arm/mach-ks8695/Kconfig +++ b/arch/arm/mach-ks8695/Kconfig @@ -5,6 +5,7 @@ menu "Kendin/Micrel KS8695 Implementations" config MACH_KS8695 bool "KS8695 development board" select MIGHT_HAVE_PCI + depends on PCI help Say 'Y' here if you want your kernel to run on the original Kendin-Micrel KS8695 development board. @@ -53,6 +54,7 @@ config MACH_CM4002 config MACH_CM4008 bool "OpenGear CM4008" select MIGHT_HAVE_PCI + depends on PCI help Say 'Y' here if you want your kernel to support the OpenGear CM4008 Console Server. See http://www.opengear.com for more @@ -61,6 +63,7 @@ config MACH_CM4008 config MACH_CM41xx bool "OpenGear CM41xx" select MIGHT_HAVE_PCI + depends on PCI help Say 'Y' here if you want your kernel to support the OpenGear CM4016 or CM4048 Console Servers. See http://www.opengear.com for @@ -69,6 +72,7 @@ config MACH_CM41xx config MACH_IM4004 bool "OpenGear IM4004" select MIGHT_HAVE_PCI + depends on PCI help Say 'Y' here if you want your kernel to support the OpenGear IM4004 Secure Access Server. See http://www.opengear.com for @@ -77,6 +81,7 @@ config MACH_IM4004 config MACH_IM42xx bool "OpenGear IM42xx" select MIGHT_HAVE_PCI + depends on PCI help Say 'Y' here if you want your kernel to support the OpenGear IM4216 or IM4248 Console Servers. See http://www.opengear.com for -- 1.8.1.2

11 years, 10 months

4
6
0 0

[PATCH v4] drm/exynos: Add fallback option to get non physically contiguous 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 contiguous memory MAY NOT be a mandatory requirement for fb, the patch adds a feature to get non physically contiguous memory for fb if physically contiguous memory allocation fails and if IOMMU is supported. 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 v3: - addressed nits pointed out by Sylwester Nawrocki <s.nawrocki(a)samsung.com> and Sachin Kamat <sachin.kamat(a)linaro.org>. 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 | 15 +++++++++++++-- 1 file changed, 13 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..5292fc7 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,18 @@ 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 physically contiguous memory allocation fails and if IOMMU is + * supported then try to get buffer from non physically contiguous + * 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

11 years, 10 months

4
4
0 0

Re: [PATCH] clk: gate: add CLK_GATE_ALWAYS_ON

by Viresh Kumar

Added linaro-kernel & patches(a)linaro.org in cc list.. On 6 August 2013 09:27, Shaojie Sun <shaojie.sun(a)linaro.org> wrote: > By default gate clock could be enable and disable. but > in some debug condition, must keep clock on, and never be closed. > setting this flag then gate clock never be closed. Consider rewriting it as: By default gate clk can be enabled/disabled but during debugging we may want to disable clk-disabling feature. This patch adds a flag for it.. > Signed-off-by: Shaojie Sun <shaojie.sun(a)linaro.com> > --- > drivers/clk/clk-gate.c | 24 ++++++++++++++++++++++++ > include/linux/clk-provider.h | 4 ++++ > 2 files changed, 28 insertions(+) Honestly speaking, I am not sure if this patch is really required or not. And so Mike can decide on that. I will do a simple code review in that time. > diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c > index 790306e..cc2b00e 100644 > --- a/drivers/clk/clk-gate.c > +++ b/drivers/clk/clk-gate.c > @@ -15,6 +15,7 @@ > #include <linux/io.h> > #include <linux/err.h> > #include <linux/string.h> > +#include <linux/device.h> why? > /** > * DOC: basic gatable clock which can gate and ungate it's ouput > @@ -48,6 +49,9 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable) > unsigned long flags = 0; > u32 reg; > > + if (!enable && (gate->flags & CLK_GATE_ALWAYS_ON)) > + return; > + > set ^= enable; > > if (gate->lock) > @@ -159,5 +163,25 @@ struct clk *clk_register_gate(struct device *dev, const char *name, > if (IS_ERR(clk)) > kfree(gate); > > + if (clk_gate_flags & CLK_GATE_ALWAYS_ON) { > + int ret; > + if (flags & CLK_SET_PARENT_GATE) > + pr_debug("%s: %salways on, but need parent gate.\n", > + __func__, name); > + > + ret = clk_prepare(clk); > + if (ret) { > + pr_debug("%s: %s could not be prepared.\n", > + __func__, name); > + return clk; > + } > + ret = clk_enable(clk); > + if (ret) { > + pr_debug("%s: %s could not be enabled.\n", > + __func__, name); > + clk_unprepare(clk); > + } Call clk_prepare_enable instead. > + } > + > return clk; > } > diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h > index 1ec14a7..641422c 100644 > --- a/include/linux/clk-provider.h > +++ b/include/linux/clk-provider.h > @@ -214,6 +214,9 @@ void of_fixed_clk_setup(struct device_node *np); > * of this register, and mask of gate bits are in higher 16-bit of this > * register. While setting the gate bits, higher 16-bit should also be > * updated to indicate changing gate bits. > + * CLK_GATE_ALWAYS_ON - by default this clock could be enable and disable. but > + * in some debug condition, must keep this clock on, and never be closed. > + * setting this flag then this clock never be closed. Copy some part from the commit log I just suggested.. If this flag is only for debugging we may name it that way. Maybe: CLK_GATE_DBG_ALWAYS_ON ??

11 years, 10 months

2
1
0 0

[PATCH] ARM: KVM: Fix 64-bit coprocessor handling

by Christoffer Dall

The PAR was exported as CRn == 7 and CRm == 0, but in fact the primary coprocessor register number was determined by CRm for 64-bit coprocessor registers as the user space API was modelled after the coprocessor access instructions (see the ARM ARM rev. C - B3-1445). However, just changing the CRn to CRm breaks the sorting check when booting the kernel, because the internal kernel logic always treats CRn as the primary register number, and it makes the table sorting impossible to understand for humans. Alternatively we could change the logic to always have CRn == CRm, but that becomes unclear in the number of ways we do lookup of a coprocessor register. We could also have a separate 64-bit table but that feels somewhat over-engineerd. Instead, keep CRn the primary representation of the primary corproc. register number in-kernel and always export the primary number as CRm as per the existing user space ABI. Note: The TTBR registers just magically worked because they happened to follow the CRn(0) regs and were considered CRn(0) in the in-kernel representation. Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> --- arch/arm/kvm/coproc.c | 23 +++++++++++++++++------ arch/arm/kvm/coproc.h | 2 ++ arch/arm/kvm/coproc_a15.c | 5 ++++- 3 files changed, 23 insertions(+), 7 deletions(-) diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c index 4a51990..fc5fec2 100644 --- a/arch/arm/kvm/coproc.c +++ b/arch/arm/kvm/coproc.c @@ -146,7 +146,10 @@ static bool pm_fake(struct kvm_vcpu *vcpu, #define access_pmintenclr pm_fake /* Architected CP15 registers. - * Important: Must be sorted ascending by CRn, CRM, Op1, Op2 + * CRn denotes the primary register number, but is copied to the CRm in the + * user space API in line with the terminology used in the ARM ARM. + * Important: Must be sorted ascending by CRn, CRM, Op1, Op2 and with 64-bit + * registers preceeding 32-bit ones. */ static const struct coproc_reg cp15_regs[] = { /* CSSELR: swapped by interrupt.S. */ @@ -154,8 +157,8 @@ static const struct coproc_reg cp15_regs[] = { NULL, reset_unknown, c0_CSSELR }, /* TTBR0/TTBR1: swapped by interrupt.S. */ - { CRm( 2), Op1( 0), is64, NULL, reset_unknown64, c2_TTBR0 }, - { CRm( 2), Op1( 1), is64, NULL, reset_unknown64, c2_TTBR1 }, + { CRn( 2), Op1( 0), is64, NULL, reset_unknown64, c2_TTBR0 }, + { CRn( 2), Op1( 1), is64, NULL, reset_unknown64, c2_TTBR1 }, /* TTBCR: swapped by interrupt.S. */ { CRn( 2), CRm( 0), Op1( 0), Op2( 2), is32, @@ -399,12 +402,13 @@ static bool index_to_params(u64 id, struct coproc_params *params) | KVM_REG_ARM_OPC1_MASK)) return false; params->is_64bit = true; - params->CRm = ((id & KVM_REG_ARM_CRM_MASK) + /* CRm to CRn: see cp15_to_index for details */ + params->CRn = ((id & KVM_REG_ARM_CRM_MASK) >> KVM_REG_ARM_CRM_SHIFT); params->Op1 = ((id & KVM_REG_ARM_OPC1_MASK) >> KVM_REG_ARM_OPC1_SHIFT); params->Op2 = 0; - params->CRn = 0; + params->CRm = 0; return true; default: return false; @@ -898,7 +902,14 @@ static u64 cp15_to_index(const struct coproc_reg *reg) if (reg->is_64) { val |= KVM_REG_SIZE_U64; val |= (reg->Op1 << KVM_REG_ARM_OPC1_SHIFT); - val |= (reg->CRm << KVM_REG_ARM_CRM_SHIFT); + /* + * CRn always denotes the primary coproc. reg. nr. for the + * in-kernel representation, but the user space API uses the + * CRm for the encoding, because it is modelled after the + * MRRC/MCRR instructions: see the ARM ARM rev. c page + * B3-1445 + */ + val |= (reg->CRn << KVM_REG_ARM_CRM_SHIFT); } else { val |= KVM_REG_SIZE_U32; val |= (reg->Op1 << KVM_REG_ARM_OPC1_SHIFT); diff --git a/arch/arm/kvm/coproc.h b/arch/arm/kvm/coproc.h index b7301d3..dccb904 100644 --- a/arch/arm/kvm/coproc.h +++ b/arch/arm/kvm/coproc.h @@ -135,6 +135,8 @@ static inline int cmp_reg(const struct coproc_reg *i1, return -1; if (i1->CRn != i2->CRn) return i1->CRn - i2->CRn; + if (i1->is_64 != i2->is_64) + return i2->is_64 - i1->is_64; if (i1->CRm != i2->CRm) return i1->CRm - i2->CRm; if (i1->Op1 != i2->Op1) diff --git a/arch/arm/kvm/coproc_a15.c b/arch/arm/kvm/coproc_a15.c index 685063a..3d8f61f 100644 --- a/arch/arm/kvm/coproc_a15.c +++ b/arch/arm/kvm/coproc_a15.c @@ -114,7 +114,10 @@ static bool access_l2ectlr(struct kvm_vcpu *vcpu, /* * A15-specific CP15 registers. - * Important: Must be sorted ascending by CRn, CRM, Op1, Op2 + * CRn denotes the primary register number, but is copied to the CRm in the + * user space API in line with the terminology used in the ARM ARM. + * Important: Must be sorted ascending by CRn, CRM, Op1, Op2 and with 64-bit + * registers preceeding 32-bit ones. */ static const struct coproc_reg a15_regs[] = { /* MPIDR: we use VMPIDR for guest access. */ -- 1.7.10.4

11 years, 10 months

2
2
0 0

[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

11 years, 10 months

2
22
0 0

[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

11 years, 10 months

3
5
0 0

[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

11 years, 10 months

3
2
0 0

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

11 years, 10 months

4
3
0 0

[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

11 years, 10 months

3
2
0 0

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

11 years, 10 months

2
3
0 0

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>

11 years, 10 months

2
1
0 0

[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

11 years, 10 months

6
11
0 0

[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

11 years, 10 months

3
3
0 0

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

11 years, 10 months

1
0
0 0

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

by Manjunath Goudar

This patch create CMA dependns on MMU.With the help MMU, page migration and CMA functionality is achieved. Signed-off-by: Manjunath Goudar <manjunath.goudar(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

11 years, 10 months

2
1
0 0

Re: [RFC][PATCH] cpufreq: Do not hold driver module references for additional policy CPUs

by Viresh Kumar

On 1 August 2013 13:41, Srivatsa S. Bhat <srivatsa.bhat(a)linux.vnet.ibm.com> wrote: > On 08/01/2013 05:38 AM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> >> >> The cpufreq core is a little inconsistent in the way it uses the >> driver module refcount. >> >> Namely, if __cpufreq_add_dev() is called for a CPU without siblings >> or generally a CPU for which a new policy object has to be created, >> it grabs a reference to the driver module to start with, but drops >> that reference before returning. As a result, the driver module >> refcount is then equal to 0 after __cpufreq_add_dev() has returned. >> >> On the other hand, if the given CPU is a sibling of some other >> CPU already having a policy, cpufreq_add_policy_cpu() is called >> to link the new CPU to the existing policy. In that case, >> cpufreq_cpu_get() is called to obtain that policy and grabs a >> reference to the driver module, but that reference is not >> released and the module refcount will be different from 0 after >> __cpufreq_add_dev() returns (unless there is an error). That >> prevents the driver module from being unloaded until >> __cpufreq_remove_dev() is called for all the CPUs that >> cpufreq_add_policy_cpu() was called for previously. >> >> To remove that inconsistency make cpufreq_add_policy_cpu() execute >> cpufreq_cpu_put() for the given policy before returning, which >> decrements the driver module refcount so that it will be 0 after >> __cpufreq_add_dev() returns, > > Removing the inconsistency is a good thing, but I think we should > make it consistent the other way around - make a CPU-online increment > the driver module refcount and decrement it only on CPU-offline. I took time to review to this mail as I was looking at the problem yesterday. I am sorry to say, but I have completely different views as compared to You and Rafael both :) First of all, Rafael's patch is incomplete as it hasn't fixed the issue completely. When we have multiple CPUs per policy and cpufreq_add_dev() is called for the first one, it call cpufreq_get_cpu() for all cpus of this policy(), so count is == x (no. of CPUs in this policy) + 1 (This is the initial value of .owner). And so we still have module count getting incremented for other cpus :) Now few lines about My point of view to this whole thing. I believe we should get rid of .owner field from struct cpufreq_driver completely. It doesn't make sense to me in doing all this management at all. Surprised? Shocked? Laughing at me? :) Well I may be wrong but this is what I think: - It looks stupid to me that I can't do this from userspace in one go: $ insmod cpufreq_driver.ko $ rmmod cpufreq_driver.ko What the hell changed in between that isn't visible to user? It looked completely stupid in that way.. Something like this sure makes sense: $ insmod ondemand-governor.ko $ change governor to ondemand for few CPUs $ rmmod ondemand-governor.ko as we have deliberately add few users of governor. And so without second step, rmmod should really work smoothly. And it does. Now, why shouldn't there be a problem with this approach? I will write that inline to the problems you just described. > The reason is, one should not be able to unload the back-end cpufreq > driver module when some CPUs are still being managed. Nasty things > will result if we allow that. For example, if we unload the module, > and then try to do a CPU offline, then the cpufreq hotplug notifier > won't even be called (because cpufreq_unregister_driver also > unregisters the hotplug notifier). And that might be troublesome. So what? Its simply equivalent to we have booted our system, haven't inserted cpufreq module and taken out a cpu. > Even worse, if we unload a cpufreq driver module and load a new > one and *then* try to offline the CPU, then the cpufreq_driver->exit() > function that we call during CPU offline will end up calling the > corresponding function of an entirely different driver! So the > ->init() and ->exit() calls won't match. That's not true. When we unload the module, it must call cpufreq_unregister_driver() which should call cpufreq_remove_cpu() for all cpus and so exit() is already called for last module. If we get something new now, it should simply work. What do you think gentlemen? -- viresh

11 years, 10 months

3
26
0 0

Re: BUG_ON(irqs_disabled()) in cpufreq.c

by Viresh Kumar

More lists cc'd On Thu, Aug 1, 2013 at 6:08 PM, Michael Giardino <giardino(a)ece.gatech.edu> wrote: > Hi, > > I hope this is the right spot to ask this. > > Is there any way to change the cpu frequency using the cpufreq driver > from within an hrtimer callback function? I encounter a kernel panic > at cpufreq.c line 255 (260 in 3.9.5) > > void __cpufreq_notify_transition(struct cpufreq_policy *policy, > 253 struct cpufreq_freqs *freqs, unsigned int state) > 254 { > 255 BUG_ON(irqs_disabled()); > > > I'm assuming this is due to the cpufreq_notify_transition needs > interrupts to notify? Is there a way around this? It appears that > acpi-cpufreq.c is calling the notifier both before and after the > transition (CPUFREQ_PRECHANGE and CPUFREQ_POSTCHANGE). > > Are there any frequency change functions that can operate without interrupts? > > The background is this: > > For the past few days I have been trying to get to the bottom of a > problem involving a nonSMP governor I have written. The goal of this > governor is to change the frequency on a predefined schedule (in the > ms scale). The basic breakdown is this: > > 1. The external scheduler computes schedules and then passes them to > the governor (with much code appropriated from the userspace governor) > via an exported function. > 2. The governor sets the frequency, then sets a timer to call the next > frequency change when it goes off > > In order to do this, I was using hrtimers. These timer's callback > functions run with interrupts disabled. > > Michael Giardino > <giardino(a)ece.gatech.edu> > <michael.giardino(a)gmail.com> > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html

11 years, 10 months

3
4
0 0

[PATCH 0/3] nohz/full: final Kconfig bits for ARM support

by Kevin Hilman

As of v3.10, the core ARM support is in mainline for NO_HZ_FULL. The only remaining part is the removal of the hard-coded Kconfig requirement on 64-bit platforms, which I believe can now be removed after the nsec granularity cputime was made to work on non 64_BIT (c.f. commit 8c23b80e, cputime_nsecs: use math64.h for nsec resolution conversion helpers.) This series makes the final Kconfig changes to bring NO_HZ_FULL support to ARM. Series applies to v3.10. I will queue up the arch/arm patch for Russell separately once the generic changes are accepted. Kevin arch/arm/Kconfig | 1 + init/Kconfig | 2 +- kernel/time/Kconfig | 2 -- 3 files changed, 2 insertions(+), 3 deletions(-) -- 1.8.3

11 years, 10 months

2
7
0 0

[PATCH] ASoC: samsung: Make secondary I2S DAI device a child of primary

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> More for neatness than for any great utility. Really we shouldn't be creating the child device at all, refactoring will follow. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/samsung/i2s.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index a3e4b49..47e08dd 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -1019,6 +1019,8 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec) if (IS_ERR(i2s->pdev)) return NULL; + i2s->pdev->dev.parent = &pdev->dev; + platform_set_drvdata(i2s->pdev, i2s); ret = platform_device_add(i2s->pdev); if (ret < 0) -- 1.8.3.2

11 years, 10 months

1
0
0 0

[PATCH] cpufreq: Re-arrange header files

by Viresh Kumar

This exercise has been done earlier but hasn't been done for few files. Lets do it now. It targets to fix following problems: - Include headers in ascending order, so that we don't add same multiple times by mistake. - <asm/> must be included after <linux/>, so that they override whatever they need. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/cpufreq.c | 23 +++++++++++------------ drivers/cpufreq/cpufreq_governor.c | 2 +- drivers/cpufreq/cpufreq_ondemand.c | 2 +- drivers/cpufreq/cpufreq_performance.c | 4 ++-- drivers/cpufreq/cpufreq_powersave.c | 4 ++-- drivers/cpufreq/cpufreq_stats.c | 12 ++++++------ include/linux/cpufreq.h | 10 +++++----- 7 files changed, 28 insertions(+), 29 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 170d344..d5f2a09 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -17,25 +17,24 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include <asm/cputime.h> +#include <linux/cpu.h> +#include <linux/cpufreq.h> +#include <linux/completion.h> +#include <linux/delay.h> +#include <linux/device.h> +#include <linux/init.h> +#include <linux/interrupt.h> #include <linux/kernel.h> #include <linux/kernel_stat.h> #include <linux/module.h> -#include <linux/init.h> +#include <linux/mutex.h> #include <linux/notifier.h> -#include <linux/cpufreq.h> -#include <linux/delay.h> -#include <linux/interrupt.h> -#include <linux/spinlock.h> -#include <linux/tick.h> -#include <linux/device.h> #include <linux/slab.h> -#include <linux/cpu.h> -#include <linux/completion.h> -#include <linux/mutex.h> +#include <linux/spinlock.h> #include <linux/syscore_ops.h> - +#include <linux/tick.h> #include <trace/events/power.h> +#include <asm/cputime.h> /** * The "cpufreq driver" - the arch- or hardware-dependent low diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index 7409dbd..5876788 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b/drivers/cpufreq/cpufreq_governor.c @@ -16,7 +16,6 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include <asm/cputime.h> #include <linux/cpufreq.h> #include <linux/cpumask.h> #include <linux/export.h> @@ -25,6 +24,7 @@ #include <linux/slab.h> #include <linux/types.h> #include <linux/workqueue.h> +#include <asm/cputime.h> #include "cpufreq_governor.h" diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c index a3c5574..d3344b5 100644 --- a/drivers/cpufreq/cpufreq_ondemand.c +++ b/drivers/cpufreq/cpufreq_ondemand.c @@ -12,6 +12,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include <linux/cpu.h> #include <linux/cpufreq.h> #include <linux/init.h> #include <linux/kernel.h> @@ -24,7 +25,6 @@ #include <linux/sysfs.h> #include <linux/tick.h> #include <linux/types.h> -#include <linux/cpu.h> #include "cpufreq_governor.h" diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c index 9fef7d6..bdfda75 100644 --- a/drivers/cpufreq/cpufreq_performance.c +++ b/drivers/cpufreq/cpufreq_performance.c @@ -12,10 +12,10 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include <linux/kernel.h> -#include <linux/module.h> #include <linux/cpufreq.h> #include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> static int cpufreq_governor_performance(struct cpufreq_policy *policy, unsigned int event) diff --git a/drivers/cpufreq/cpufreq_powersave.c b/drivers/cpufreq/cpufreq_powersave.c index 32109a1..47235e2 100644 --- a/drivers/cpufreq/cpufreq_powersave.c +++ b/drivers/cpufreq/cpufreq_powersave.c @@ -12,10 +12,10 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include <linux/kernel.h> -#include <linux/module.h> #include <linux/cpufreq.h> #include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> static int cpufreq_governor_powersave(struct cpufreq_policy *policy, unsigned int event) diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c index cb38413..7610e4b 100644 --- a/drivers/cpufreq/cpufreq_stats.c +++ b/drivers/cpufreq/cpufreq_stats.c @@ -9,17 +9,17 @@ * published by the Free Software Foundation. */ -#include <linux/kernel.h> -#include <linux/slab.h> #include <linux/cpu.h> -#include <linux/sysfs.h> #include <linux/cpufreq.h> -#include <linux/module.h> #include <linux/jiffies.h> -#include <linux/percpu.h> +#include <linux/kernel.h> #include <linux/kobject.h> -#include <linux/spinlock.h> +#include <linux/module.h> #include <linux/notifier.h> +#include <linux/percpu.h> +#include <linux/slab.h> +#include <linux/spinlock.h> +#include <linux/sysfs.h> #include <asm/cputime.h> static spinlock_t cpufreq_stats_lock; diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index e1fd215..247d83a 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -11,15 +11,15 @@ #ifndef _LINUX_CPUFREQ_H #define _LINUX_CPUFREQ_H -#include <asm/cputime.h> +#include <linux/cpumask.h> +#include <linux/completion.h> +#include <linux/kobject.h> #include <linux/mutex.h> #include <linux/notifier.h> -#include <linux/threads.h> -#include <linux/kobject.h> #include <linux/sysfs.h> -#include <linux/completion.h> +#include <linux/threads.h> #include <linux/workqueue.h> -#include <linux/cpumask.h> +#include <asm/cputime.h> #include <asm/div64.h> #define CPUFREQ_NAME_LEN 16 -- 1.7.12.rc2.18.g61b472e

11 years, 10 months

2
2
0 0

[PATCH V4 0/6] USB: OHCI: more bus glues as separate modules

by Manjunath Goudar

These patches are for separating the SOC On-Chip ohci host controller from ohci-hcd host code into its own driver module. This work is part of enabling multi-platform kernels on ARM; it would be nice to have in 3.12. V2: In patch 5/6 and 6/6: -Set non-standard fields in hc_driver manually, rather than relying on an expanded struct ohci_driver_overrides. -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than relying on ohci_hub_control and hub_status_data being exported. In patch 1/6 to 4/6 -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. V3: In patch 5/6 and 6/6: -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. In patch 5/6: -The ohci_restart() function is not required in current scenario, only discarding connection state of integrated transceivers is sufficient, for this directly handling ohci->hc_control. In patch 2/6 : -rewritten if (config->otg || config->rwc) block statements into two separate 'if blocks' to handle below scenarios 1. config->otg set scenario. 2. if any of these (config->otg, config->rwc) are set, this scenario should be handled only after ohci_setup() In patch 1/6 and 4/6: No change. V4: In patch 1/6 and 4/6: No change. In patch 2/6 : -usb_remove_hcd() function is required a valid clock that is what omap_ohci_clock_power(0) is called after hcd shutdown. In patch 3/6 : -V3 modification revert back, only ohci->regs setting write() function has been removed because ohci->regs doesn't get set until usb_add_hcd. In patch 5/6 : - Removed extra space after "tristate". - Removed extra space between function name and '(' characters. - MODULE_ALIAS line moved to last statement of ohci-at91 file. In patch 6/6 : - Removed extra space before the '='. - Moved /* forward definitions */ line before the declarations of functions. Manjunath Goudar (6): USB: OHCI: make ohci-exynos a separate driver USB: OHCI: make ohci-omap a separate driver USB: OHCI: make ohci-omap3 a separate driver USB: OHCI: make ohci-spear a separate driver USB: OHCI: make ohci-at91 a separate driver USB: OHCI: make ohci-s3c2410 a separate driver drivers/usb/host/Kconfig | 30 ++++++- drivers/usb/host/Makefile | 6 ++ drivers/usb/host/ohci-at91.c | 153 ++++++++++++++++------------------- drivers/usb/host/ohci-exynos.c | 167 ++++++++++++++++----------------------- drivers/usb/host/ohci-hcd.c | 108 ------------------------- drivers/usb/host/ohci-omap.c | 156 +++++++++++++----------------------- drivers/usb/host/ohci-omap3.c | 118 +++++++++------------------ drivers/usb/host/ohci-s3c2410.c | 128 +++++++++++++----------------- drivers/usb/host/ohci-spear.c | 140 +++++++++++++------------------- 9 files changed, 374 insertions(+), 632 deletions(-) -- 1.7.9.5

11 years, 10 months

1
6
0 0

[PATCH V2] USB: EHCI: make ehci-w90X900 a separate driver

by Manjunath Goudar

Separate the W90X900(W90P910) on-chip host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before W90X900(W90P910) can be booted with a multi-platform kernel and an ehci driver that only works on one of them. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the w90X900 bus glue. Signed-off-by: Manjunath Goudar <manjunath.goudar(a)linaro.org> Acked-by: Arnd Bergmann <arnd(a)arndb.de> Cc: Greg KH <greg(a)kroah.com> Cc: Alan Stern <stern(a)rowland.harvard.edu> Cc: Wan ZongShun <mcuos.com(a)gmail.com> Cc: linux-usb(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org V2: -Arranged #include's in alphabetical order. -Replaced "w90p910" by "w90x900" because it is supports all series of w90x900. --- drivers/usb/host/Kconfig | 2 +- drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 5 --- drivers/usb/host/ehci-w90x900.c | 85 ++++++++++++++++----------------------- 4 files changed, 37 insertions(+), 56 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index ba52912..7bc598b 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -244,7 +244,7 @@ config USB_EHCI_MV SoCs, see USB_EHCI_HCD_ORION for those. config USB_W90X900_EHCI - bool "W90X900(W90P910) EHCI support" + tristate "W90X900(W90P910) EHCI support" depends on ARCH_W90X900 ---help--- Enables support for the W90X900 USB controller diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 7664db8..28adb3f 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -35,6 +35,7 @@ obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o obj-$(CONFIG_USB_EHCI_TEGRA) += ehci-tegra.o obj-$(CONFIG_USB_EHCI_MV) += ehci-mv.o +obj-$(CONFIG_USB_W90X900_EHCI) += ehci-w90x900.o obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 5717dcd..4a5644e 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1249,11 +1249,6 @@ MODULE_LICENSE ("GPL"); #define XILINX_OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver #endif -#ifdef CONFIG_USB_W90X900_EHCI -#include "ehci-w90x900.c" -#define PLATFORM_DRIVER ehci_hcd_w90x900_driver -#endif - #ifdef CONFIG_USB_OCTEON_EHCI #include "ehci-octeon.c" #define PLATFORM_DRIVER ehci_octeon_driver diff --git a/drivers/usb/host/ehci-w90x900.c b/drivers/usb/host/ehci-w90x900.c index 59e0e24..4d6631d 100644 --- a/drivers/usb/host/ehci-w90x900.c +++ b/drivers/usb/host/ehci-w90x900.c @@ -11,13 +11,28 @@ * */ +#include <linux/dma-mapping.h> +#include <linux/io.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/of.h> #include <linux/platform_device.h> +#include <linux/usb.h> +#include <linux/usb/hcd.h> + +#include "ehci.h" /* enable phy0 and phy1 for w90p910 */ #define ENPHY (0x01<<8) #define PHY0_CTR (0xA4) #define PHY1_CTR (0xA8) +#define DRIVER_DESC "EHCI w90x900 driver" + +static const char hcd_name[] = "ehci-w90x900 "; + +static struct hc_driver __read_mostly ehci_w90x900_hc_driver; + static int usb_w90x900_probe(const struct hc_driver *driver, struct platform_device *pdev) { @@ -99,54 +114,6 @@ void usb_w90x900_remove(struct usb_hcd *hcd, struct platform_device *pdev) usb_put_hcd(hcd); } -static const struct hc_driver ehci_w90x900_hc_driver = { - .description = hcd_name, - .product_desc = "Nuvoton w90x900 EHCI Host Controller", - .hcd_priv_size = sizeof(struct ehci_hcd), - - /* - * generic hardware linkage - */ - .irq = ehci_irq, - .flags = HCD_USB2|HCD_MEMORY, - - /* - * basic lifecycle operations - */ - .reset = ehci_setup, - .start = ehci_run, - - .stop = ehci_stop, - .shutdown = ehci_shutdown, - - /* - * managing i/o requests and associated device resources - */ - .urb_enqueue = ehci_urb_enqueue, - .urb_dequeue = ehci_urb_dequeue, - .endpoint_disable = ehci_endpoint_disable, - .endpoint_reset = ehci_endpoint_reset, - - /* - * scheduling support - */ - .get_frame_number = ehci_get_frame, - - /* - * root hub support - */ - .hub_status_data = ehci_hub_status_data, - .hub_control = ehci_hub_control, -#ifdef CONFIG_PM - .bus_suspend = ehci_bus_suspend, - .bus_resume = ehci_bus_resume, -#endif - .relinquish_port = ehci_relinquish_port, - .port_handed_over = ehci_port_handed_over, - - .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete, -}; - static int ehci_w90x900_probe(struct platform_device *pdev) { if (usb_disabled()) @@ -173,7 +140,25 @@ static struct platform_driver ehci_hcd_w90x900_driver = { }, }; +static int __init ehci_w90X900_init(void) +{ + if (usb_disabled()) + return -ENODEV; + + pr_info("%s: " DRIVER_DESC "\n", hcd_name); + + ehci_init_driver(&ehci_w90x900_hc_driver, NULL); + return platform_driver_register(&ehci_hcd_w90x900_driver); +} +module_init(ehci_w90X900_init); + +static void __exit ehci_w90X900_cleanup(void) +{ + platform_driver_unregister(&ehci_hcd_w90x900_driver); +} +module_exit(ehci_w90X900_cleanup); + +MODULE_DESCRIPTION(DRIVER_DESC); MODULE_AUTHOR("Wan ZongShun <mcuos.com(a)gmail.com>"); -MODULE_DESCRIPTION("w90p910 usb ehci driver!"); -MODULE_LICENSE("GPL"); MODULE_ALIAS("platform:w90p910-ehci"); +MODULE_LICENSE("GPL v2"); -- 1.7.9.5

11 years, 10 months

2
2
0 0

[PATCH 1/5] regulator: core: Provide hints to the core about optional supplies

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> While the majority of supplies on devices are mandatory and can't be physically omitted for electrical reasons some devices do have optional supplies and need to know if they are missing, MMC being the most common of these. Currently the core accurately reports all errors when regulators are requested since it does not know if the supply is one that must be provided even if by a regulator software does not know about or if it is one that may genuinely be disconnected. In order to allow this behaviour to be changed and stub regulators to be provided in the former case add a new regulator request function regulator_get_optional() which provides a hint to the core that the regulator may genuinely not be connected. Currently the implementation is identical to the current behaviour, future patches will add support in the core for returning stub regulators in the case where normal regulator_get() fails and the board has requested it. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/regulator/core.c | 59 ++++++++++++++++++++++++++++++++++++++ include/linux/regulator/consumer.h | 18 +++++++++++- 2 files changed, 76 insertions(+), 1 deletion(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 61e4060..f24f401 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1414,6 +1414,65 @@ struct regulator *regulator_get_exclusive(struct device *dev, const char *id) } EXPORT_SYMBOL_GPL(regulator_get_exclusive); +/** + * regulator_get_optional - obtain optional access to a regulator. + * @dev: device for regulator "consumer" + * @id: Supply name or regulator ID. + * + * Returns a struct regulator corresponding to the regulator producer, + * or IS_ERR() condition containing errno. Other consumers will be + * unable to obtain this reference is held and the use count for the + * regulator will be initialised to reflect the current state of the + * regulator. + * + * This is intended for use by consumers for devices which can have + * some supplies unconnected in normal use, such as some MMC devices. + * It can allow the regulator core to provide stub supplies for other + * supplies requested using normal regulator_get() calls without + * disrupting the operation of drivers that can handle absent + * supplies. + * + * Use of supply names configured via regulator_set_device_supply() is + * strongly encouraged. It is recommended that the supply name used + * should match the name used for the supply and/or the relevant + * device pins in the datasheet. + */ +struct regulator *regulator_get_optional(struct device *dev, const char *id) +{ + return _regulator_get(dev, id, 0); +} +EXPORT_SYMBOL_GPL(regulator_get_optional); + +/** + * devm_regulator_get_optional - Resource managed regulator_get_optional() + * @dev: device for regulator "consumer" + * @id: Supply name or regulator ID. + * + * Managed regulator_get_optional(). Regulators returned from this + * function are automatically regulator_put() on driver detach. See + * regulator_get_optional() for more information. + */ +struct regulator *devm_regulator_get_optional(struct device *dev, + const char *id) +{ + struct regulator **ptr, *regulator; + + ptr = devres_alloc(devm_regulator_release, sizeof(*ptr), GFP_KERNEL); + if (!ptr) + return ERR_PTR(-ENOMEM); + + regulator = regulator_get_optional(dev, id); + if (!IS_ERR(regulator)) { + *ptr = regulator; + devres_add(dev, ptr); + } else { + devres_free(ptr); + } + + return regulator; +} +EXPORT_SYMBOL_GPL(devm_regulator_get_optional); + /* Locks held by regulator_put() */ static void _regulator_put(struct regulator *regulator) { diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h index 1ccc889..2582e41 100644 --- a/include/linux/regulator/consumer.h +++ b/include/linux/regulator/consumer.h @@ -137,6 +137,10 @@ struct regulator *__must_check devm_regulator_get(struct device *dev, const char *id); struct regulator *__must_check regulator_get_exclusive(struct device *dev, const char *id); +struct regulator *__must_check regulator_get_optional(struct device *dev, + const char *id); +struct regulator *__must_check devm_regulator_get_optional(struct device *dev, + const char *id); void regulator_put(struct regulator *regulator); void devm_regulator_put(struct regulator *regulator); @@ -212,14 +216,26 @@ static inline struct regulator *__must_check regulator_get(struct device *dev, } static inline struct regulator *__must_check +devm_regulator_get(struct device *dev, const char *id) +{ + return NULL; +} + +static inline struct regulator *__must_check regulator_get_exclusive(struct device *dev, const char *id) { return NULL; } +static inline struct regulator *__must_check +regulator_get_optional(struct device *dev, const char *id) +{ + return NULL; +} + static inline struct regulator *__must_check -devm_regulator_get(struct device *dev, const char *id) +devm_regulator_get_optional(struct device *dev, const char *id) { return NULL; } -- 1.8.3.2

11 years, 10 months

3
6
0 0

[PATCH 0/5] Optional regulator support

by Mark Brown

This patch series adds a variant of regulator_get() which allows regulator consumers to tell the core that the supply they are requesting may genuinely be absent in the system. The goal is to help address some of the problems with handling errors in regulator_get() in drivers that are newly converted to the regulator API by allowing the core to provide stub regulators for supplies that aren't hooked up without disrupting the operation of drivers like MMC drivers which may genuinely not have some of their supplies hooked up. Currently the code simply introduces a new API call with exactly the same implementation as regulator_get() so there should be zero impact from the series other than a slightly larger kernel. Right now all the MMC users are converted over as-is, though it does look like drivers such as sdhci really ought to be insisting on having a regulator for VMMC in the same way that the MMC core helper does (and indeed in that case it looks like it ought to be converted over to the core code). If this series is OK I'd like to merge it via the regulator tree so that the functionality to make use of the optional regulators can be built out on top of it. Mark Brown (5): regulator: core: Provide hints to the core about optional supplies mmc: core: Indicate that vmmcq may be absent mmc: sdhci: Indicate that regulators may be absent mmc: dw_mmc: Indicate that regulators may be absent mmc: pxamci: Indicate that regulators may be absent drivers/mmc/core/core.c | 2 +- drivers/mmc/host/dw_mmc.c | 2 +- drivers/mmc/host/pxamci.c | 2 +- drivers/mmc/host/sdhci.c | 4 +-- drivers/regulator/core.c | 59 ++++++++++++++++++++++++++++++++++++++ include/linux/regulator/consumer.h | 18 +++++++++++- 6 files changed, 81 insertions(+), 6 deletions(-)

11 years, 10 months

2
2
0 0

[PATCH 1/2] cpufreq: Remove extra variables

by Viresh Kumar

We call cpufreq_cpu_get() in cpufreq_add_dev_symlink() to increase usage refcount of policy and not to get policy for a cpu. So, we don't really need to capture the return value of this routine and call put for it later for failure cases. We can simply use policy passed as an argument to this routine. Moreover debug print is rewritten to make it more clear. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/cpufreq.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 170d344..35e1a03 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -813,19 +813,18 @@ static int cpufreq_add_dev_symlink(unsigned int cpu, int ret = 0; for_each_cpu(j, policy->cpus) { - struct cpufreq_policy *managed_policy; struct device *cpu_dev; if (j == cpu) continue; - pr_debug("CPU %u already managed, adding link\n", j); - managed_policy = cpufreq_cpu_get(cpu); + pr_debug("Adding link for CPU: %u\n", j); + cpufreq_cpu_get(cpu); cpu_dev = get_cpu_device(j); ret = sysfs_create_link(&cpu_dev->kobj, &policy->kobj, "cpufreq"); if (ret) { - cpufreq_cpu_put(managed_policy); + cpufreq_cpu_put(policy); return ret; } } -- 1.7.12.rc2.18.g61b472e

11 years, 10 months

2
3
0 0

HMP behavior bad when port the patch set to latest kernel

by Lei Wen

Hi list, I am trying to porting linaro MP patches to other kernel branches, and find some regression due to latest kernel change. The regression is while we test over Linaro 13.06 release with MP3 scenario, we find CA7 is always busy, while one core of CA15 is occasionally raise up with the average of 2% cpu usage ratio, another core is kept silence most of time. But when switch to our backported branch, we find both core in CA15 becomes active, and keep the usage ratio around 2%. With further checking, I find one recent merged patch in mainline cause this: https://lkml.org/lkml/2013/6/27/152 This patch mainly change the initial load for the new born task to the largest one, so that it cause hmp make the decision to move all such task to the big cluster. Since cpu3(The first cpu of CA15) is getting busy now, cpu4 is raise up to share the load as consequence. And it make ALL 5 cpus are used in the MP3 scenario, which should make power result looks bad than before... What is your opinion for this regression, especially for how HMP should act with the increased load raising up with the merged patch? Actually, I have one patch which would forbid the new born task to the faster cluster. Not sure it would cause any other side affect. Comments welcomes. :) --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -840,10 +840,26 @@ void init_task_runnable_average(struct task_struct *p) p->se.avg.runnable_avg_period = slice; __update_task_entity_contrib(&p->se); } + +static inline bool task_is_new_born(struct task_struct *p) +{ + u32 slice; + + /* tribble the times for the new born task */ + slice = sched_slice(task_cfs_rq(p), &p->se) >> 8; + + return p->se.avg.runnable_avg_period < slice; +} + #else void init_task_runnable_average(struct task_struct *p) { } + +static inline bool task_is_new_born(struct task_struct *p) +{ + return true; +} #endif /* @@ -6331,7 +6347,7 @@ static unsigned int hmp_up_migration(int cpu, struct sched_entity *se) < hmp_next_up_threshold) return 0; - if (se->avg.load_avg_ratio > hmp_up_threshold) { + if (!task_is_new_born(p) && se->avg.load_avg_ratio > hmp_up_threshold) { /* Target domain load < ~94% */ if (hmp_domain_min_load(hmp_faster_domain(cpu), NULL) > NICE_0_LOAD-64) Thanks, Lei

11 years, 10 months

3
6
0 0

[PATCH 0/7] Add DT nodes for FIMD and DP controller for Exynos5420 SoC

by Vikas Sajjan

This patchset adds DT nodes for FIMD and DP controller for Exynos5420 based SMDK. It moves all common properties of FIMD and DP controller DT node specific to Exynos5 Socs like 5250 and 5420 to exynos5.dtsi file. It also adds required PM domain DT nodes for exynos5420. Is rebased on branch kgene's "for-next" https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h… The DP PHY DT Node is based on Jingoo Han's inflight patchset at http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/66… Vikas Sajjan (6): ARM: dts: move display-timimg information inside FIMD DT node for exynos5250 ARM: dts: Update FIMD DT node for Exynos5 SoCs ARM: dts: Add FIMD DT node to exynos5420 DTS files ARM: dts: Update DP controller DT Node for Exynos5 based SoCs ARM: dts: Add DP controller DT node to exynos5420 SoC ARM: dts: add pin state information for DP HPD support to Exynos5420 Yadwinder Singh Brar (1): ARM: dts: Add basic PM domains for EXYNOS5420 arch/arm/boot/dts/exynos5.dtsi | 39 +++++++++++++++++++++++ arch/arm/boot/dts/exynos5250-arndale.dts | 9 ------ arch/arm/boot/dts/exynos5250-smdk5250.dts | 35 +++++++++------------ arch/arm/boot/dts/exynos5250.dtsi | 18 ++--------- arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 7 +++++ arch/arm/boot/dts/exynos5420-smdk5420.dts | 23 ++++++++++++++ arch/arm/boot/dts/exynos5420.dtsi | 49 +++++++++++++++++++++++++++++ 7 files changed, 135 insertions(+), 45 deletions(-) -- 1.7.9.5

11 years, 10 months

3
12
0 0

[Question] The Secure Monitor Code For PSCI

by Leo Yan

hi, Now ARM has defined PSCI for Trustzone; So where we can get monitor code or trustzone's s/w on TC2 for the reference? when we go through TC2 and ARM64's code, they have already supported PSCI yet for the smp boot operations and low power modes, so it will be clear for us if we can see two portions' code to get clear the whole flow. Thx in advance. -- Thx, Leo Yan

11 years, 10 months

2
2
0 0

[PATCH] regulator: core: Add missing stub for regulator_get_exclusive()

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Signed-off-by: Mark Brown <broonie(a)linaro.org> --- include/linux/regulator/consumer.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h index 3610df8..3b9b4da 100644 --- a/include/linux/regulator/consumer.h +++ b/include/linux/regulator/consumer.h @@ -217,6 +217,12 @@ devm_regulator_get(struct device *dev, const char *id) return NULL; } +static inline struct regulator *__must_check +devm_regulator_get_exclusive(struct device *dev, const char *id) +{ + return NULL; +} + static inline void regulator_put(struct regulator *regulator) { } -- 1.8.3.2

11 years, 10 months

1
0
0 0

[PATCH 01/11] spi: Provide core support for runtime PM during transfers

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Most SPI drivers that implement runtime PM support use identical code to do so: they acquire a runtime PM lock in prepare_transfer_hardware() and then they release it in unprepare_transfer_hardware(). The variations in this are mostly missing error checking and the choice to use autosuspend. Since these runtime PM calls are normally the only thing in the prepare and unprepare callbacks and the autosuspend API transparently does the right thing on devices with autosuspend disabled factor all of this out into the core with a flag to enable the behaviour. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/spi/spi.c | 16 ++++++++++++++++ include/linux/spi/spi.h | 4 ++++ 2 files changed, 20 insertions(+) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 46c3f56..61f71b9 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -553,6 +553,10 @@ static void spi_pump_messages(struct kthread_work *work) master->unprepare_transfer_hardware(master)) dev_err(&master->dev, "failed to unprepare transfer hardware\n"); + if (master->auto_runtime_pm) { + pm_runtime_mark_last_busy(master->dev.parent); + pm_runtime_put_autosuspend(master->dev.parent); + } return; } @@ -572,11 +576,23 @@ static void spi_pump_messages(struct kthread_work *work) master->busy = true; spin_unlock_irqrestore(&master->queue_lock, flags); + if (!was_busy && master->auto_runtime_pm) { + ret = pm_runtime_get_sync(master->dev.parent); + if (ret < 0) { + dev_err(&master->dev, "Failed to power device: %d\n", + ret); + return; + } + } + if (!was_busy && master->prepare_transfer_hardware) { ret = master->prepare_transfer_hardware(master); if (ret) { dev_err(&master->dev, "failed to prepare transfer hardware\n"); + + if (master->auto_runtime_pm) + pm_runtime_put(master->dev.parent); return; } } diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index be40c97..d73059a 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -256,6 +256,8 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv) * @busy: message pump is busy * @running: message pump is running * @rt: whether this queue is set to run as a realtime task + * @auto_runtime_pm: the core should ensure a runtime PM reference is held + * while the hardware is prepared * @prepare_transfer_hardware: a message will soon arrive from the queue * so the subsystem requests the driver to prepare the transfer hardware * by issuing this call @@ -380,11 +382,13 @@ struct spi_master { bool busy; bool running; bool rt; + bool auto_runtime_pm; int (*prepare_transfer_hardware)(struct spi_master *master); int (*transfer_one_message)(struct spi_master *master, struct spi_message *mesg); int (*unprepare_transfer_hardware)(struct spi_master *master); + /* gpio chip select */ int *cs_gpios; }; -- 1.8.3.2

11 years, 10 months

4
16
0 0

[PATCH 1/3] cpu topology: remove stale arch_provides_topology_pointers and define_siblings_show_map/list()

by Hanjun Guo

arch_provides_topology_pointers was introduced in commit 23ca4bba3 (x86: cleanup early per cpu variables/accesses v4) to indicate pointers to the topology cpumask_t maps are valid to avoid copying data on to/off of the stack. But later in commit fbd59a8d (cpumask: Use topology_core_cpumask()/ topology_thread_cpumask()), the pointers to the topology struct cpumask maps are always valid. After that commit, the only difference is that there is a redundant "unsigned int cpu = dev->id;" if arch_provides_topology_pointers defined, but dev->id is type 'u32' which devolves to 'unsigned int' on all supported arches. So this arch_provides_topology_pointers define is pointless and only cause obfuscation now, remove it. Tested on x86 machine, topology information in sys/devices/system/cpu/ cpuX/topology/ is the same after appling this patch set. Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> --- drivers/base/topology.c | 20 -------------------- 1 file changed, 20 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 2f5919e..94ffee3 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -62,25 +62,6 @@ static ssize_t show_cpumap(int type, const struct cpumask *mask, char *buf) } #endif -#ifdef arch_provides_topology_pointers -#define define_siblings_show_map(name) \ -static ssize_t show_##name(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - unsigned int cpu = dev->id; \ - return show_cpumap(0, topology_##name(cpu), buf); \ -} - -#define define_siblings_show_list(name) \ -static ssize_t show_##name##_list(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - unsigned int cpu = dev->id; \ - return show_cpumap(1, topology_##name(cpu), buf); \ -} - -#else #define define_siblings_show_map(name) \ static ssize_t show_##name(struct device *dev, \ struct device_attribute *attr, char *buf) \ @@ -95,7 +76,6 @@ static ssize_t show_##name##_list(struct device *dev, \ { \ return show_cpumap(1, topology_##name(dev->id), buf); \ } -#endif #define define_siblings_show_func(name) \ define_siblings_show_map(name); define_siblings_show_list(name) -- 1.7.9.5

11 years, 10 months

1
2
0 0

[PATCH 0/1] ARM: atomic64: fix endian-ness in atomic.h

by Victor Kamensky

Fixes atomic64_xxx functions endian-ness isussues as it was discussed on http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185898.html Patch itself follows in separate email. This cover letter describes what testing has been done Tested on pandaboard for both cases: LE and BE, CONFIG_GENERIC_ATOMIC64 was forcefully disabled. In BE case it was tested on top of Ben's other BE patches covered by (updates for be8 patch series). The following tests passed: 1) CONFIG_ATOMIC64_SELFTEST 2) The following module produced identical output for both LE, BE, and GENERIC_ATOMIC64 #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/atomic.h> atomic64_t a = {0}; #define STEP 0x40000000 void atomic64_add_test1 (void) { atomic64_add(STEP, &a); } void test_atomic64_add(void) { int i; printk("atomic64_add\n"); atomic64_set(&a, 0); printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { atomic64_add_test1(); printk("i = %2d: a = 0x%llx (%lld)\n", i, a.counter, a.counter); } } void atomic64_sub_test1 (void) { atomic64_sub(STEP, &a); } void test_atomic64_sub(void) { int i; printk("atomic64_sub\n"); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 20; i++) { atomic64_sub_test1(); printk("i = %2d: a = 0x%llx (%lld)\n", i, a.counter, a.counter); } } u64 atomic64_add_return_test1 (void) { return atomic64_add_return(STEP, &a); } void test_atomic64_add_return(void) { int i; u64 ret; printk("atomic64_add_return\n"); atomic64_set(&a, 0); printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { ret = atomic64_add_return_test1(); printk("i = %2d: a = 0x%llx (%lld), ret = %llx (%lld)\n", i, a.counter, a.counter, ret, ret); } } u64 atomic64_sub_return_test1 (void) { return atomic64_sub_return(STEP, &a); } void test_atomic64_sub_return(void) { int i; u64 ret; printk("atomic64_sub_return\n"); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 20; i++) { ret = atomic64_sub_return_test1(); printk("i = %2d: a = 0x%llx (%lld), ret = %llx (%lld)\n", i, a.counter, a.counter, ret, ret); } } void atomic64_dec_if_positive_test1 (void) { atomic64_dec_if_positive(&a); } void test1_atomic64_dec_if_positive (void) { int i; printk("atomic64_dec_if_positive test1\n"); atomic64_set(&a, 0x100000003); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { atomic64_dec_if_positive_test1(); printk("i = %2d: a = 0x%llx (%lld))\n", i, a.counter, a.counter); } } void test2_atomic64_dec_if_positive (void) { int i; printk("atomic64_dec_if_positive test2\n"); atomic64_set(&a, 0x3); /* value of a is set by previos test */ printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { atomic64_dec_if_positive_test1(); printk("i = %2d: a = 0x%llx (%lld))\n", i, a.counter, a.counter); } } void atomic64_add_unless_test1(long long u) { atomic64_add_unless(&a, STEP, u); } void test_atomic64_add_unless(void) { int i; u64 prev; printk("atomic64_add_unless\n"); atomic64_set(&a, 0); printk("a = 0x%llx (%lld)\n", a.counter, a.counter); for (i = 0; i < 10; i++) { prev = a.counter; atomic64_add_unless_test1(prev); printk("i = %2d: no change: prev = 0x%llx (%lld), a = 0x%llx (%lld)\n", i, prev, prev, a.counter, a.counter); atomic64_add_unless_test1(prev - 1); printk("i = %2d: change: prev = 0x%llx (%lld), a = 0x%llx (%lld)\n", i, prev, prev, a.counter, a.counter); } } int init_module (void) { test_atomic64_add(); test_atomic64_sub(); test_atomic64_add_return(); test_atomic64_sub_return(); test1_atomic64_dec_if_positive(); test2_atomic64_dec_if_positive(); test_atomic64_add_unless(); return 0; } void cleanup_module(void) { } MODULE_LICENSE("GPL"); Thanks, Victor Victor Kamensky (1): ARM: atomic64: fix endian-ness in atomic.h arch/arm/include/asm/atomic.h | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) -- 1.8.1.4

11 years, 10 months

2
2
0 0

RE: Arndale power management

by Comaschi, F.

Yes of course! Sorry for that ;) Best, Francesco ________________________________________ From: Mike Turquette [mturquette(a)linaro.org] Sent: Thursday, July 25, 2013 7:36 PM To: Comaschi, F. Subject: Re: Arndale power management Francesco, Can you reply to the list with your response? Please do not remove the list when responding. Regards, Mike On Wed, Jul 24, 2013 at 11:11 PM, Comaschi, F. <fcomaschi(a)tue.nl> wrote: > Dear Mike, > > thank you very much for your reply! > > the hack that you suggest is indeed what I have done so far just for testing. However, I was thinking, if we have some knowledge about the specific application that we are running, from a functional point of view (e.g., we are scanning a scene through a camera and we see that there's no movement, therefore we decide to lower the frequency), wouldn't it be useful to exploit this knowledge in order to implement our own DVFS policy in a more proactive way, rather than recurring to the available governors which I think are working in a more reactive way? > In that case, how would you suggest to interface with the OS from inside my application? Shall I make some "calls" to specific API's, or maybe writing my own governor? > > Thanks in advance for your attention! > > Best, > > Francesco > ________________________________________ > From: Mike Turquette [mturquette(a)linaro.org] > Sent: Thursday, July 25, 2013 3:58 AM > To: Viresh Kumar; Comaschi, F. > Cc: Lukasz Majewski; Lists linaro-kernel; cpufreq(a)vger.kernel.org; Chander Kashyap; Linux PM List > Subject: Re: Arndale power management > > Quoting Viresh Kumar (2013-07-15 23:43:03) >> Adding few more lists so that others can also help.. >> >> On 15 July 2013 20:00, Comaschi, F. <fcomaschi(a)tue.nl> wrote: >> > Dear Viresh, >> > >> > I am Francesco Comaschi, a researcher at Eindhoven University of Technology. My research group is interested in implementing custom power management policies on ARM-based platform (at the moment we are using an Arndale 5250 board featuring Exynos5 dual). We would like to make use of DVFS and to be able to measure power consumption on the board. >> >> Ok. >> >> > First of all, congratulations for the work that you and the other guys form the power management team are doing within the Linaro community, I always follow your progress, and so far you have been the only reliable source of information for everything I have been doing on the board. >> >> Thanks :) >> >> > If you do not mind, I would like to ask you a few questions: >> > 1) Is there a way to measure the board power consumption via software? I have read here: http://blogs.arm.com/software-enablement/925-linux-hwmon-power-management-a… that it is possible with the ARM Versatile boards, through the hwmon framework and lm_sensors. However, when I run lm_sensors on the Arndale board, no sensors were found. Do you know about any other possible ways to measure power in software? Maybe it is possible to communicate with the on-board PMIC? Maybe there are some registers where information about the power/voltage provided to the processor and the other components is available? >> >> On ARM Versatile express boards and the coretiles that come with it, >> we have sensors which are probed through hwmon framework in >> Linux. So, we have hardware IPs present on board which let us >> get some power figures per cluster for big LITTLE. >> >> I am not sure if Exynos have any such things on it. >> >> @Chander: Are you aware of any such features? >> >> > 2) Recently I have read Andy Green’s presentation “How to measure SoC power”. However, by measuring power on the PMIC input side through the ARM Energy Probe, probably I won't be able to see the effect of DVFS. Do you have any suggestions on how to measure the effect of DVFS, even through hardware measurements? >> >> You need probes on the voltage regulator which is feed the cores... >> But again, that is very much hardware specific. And I haven't worked >> on Exynos at all :) >> >> > 3) More in general, I do not know which is the best way to implement custom policies of DVFS. >> >> I didn't get you here. Are you talking about tuning of governors here? >> >> > Is it possible, maybe through appropriate API's, to access the cpu_idle and the cpu_freq framework from inside my application? Shall I work directly with the drivers of the PMIC? Is it possible to set the voltage directly from inside my application? > > Are you trying to create a DVFS policy from a userspace application? > Lots of people hack together something using the CPUfreq "userspace" > governor and writing to: > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor > > This is not something that should be shipped on a product but is useful > for learning and prototyping. It only affects the CPU and will not help > you craft DVFS policies on other peripherals/devices. > > Regards, > Mike > >> >> Something on the board must provide this to kernel. Kernel can't >> get it by itself. >> >> _______________________________________________ >> linaro-kernel mailing list >> linaro-kernel(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-kernel

11 years, 10 months

1
0
0 0

[RFC][PATCH 0/9] sched: Power scheduler design proposal

by Morten Rasmussen

Hi, This patch set is an initial prototype aiming at the overall power-aware scheduler design proposal that I previously described <http://permalink.gmane.org/gmane.linux.kernel/1508480>. The patch set introduces a cpu capacity managing 'power scheduler' which lives by the side of the existing (process) scheduler. Its role is to monitor the system load and decide which cpus that should be available to the process scheduler. Long term the power scheduler is intended to replace the currently distributed uncoordinated power management policies and will interface a unified platform specific power driver obtain power topology information and handle idle and P-states. The power driver interface should be made flexible enough to support multiple platforms including Intel and ARM. This prototype supports very simple task packing and adds cpufreq wrapper governor that allows the power scheduler to drive P-state selection. The prototype policy is absolutely untuned, but this will be addressed in the future. Scalability improvements, such as avoid iterating over all cpus, will also be addressed in the future. Thanks, Morten Morten Rasmussen (9): sched: Introduce power scheduler sched: Redirect update_cpu_power to sched/power.c sched: Make select_idle_sibling() skip cpu with a cpu_power of 1 sched: Make periodic load-balance disregard cpus with a cpu_power of 1 sched: Make idle_balance() skip cpus with a cpu_power of 1 sched: power: add power_domain data structure sched: power: Add power driver interface sched: power: Add initial frequency scaling support to power scheduler sched: power: cpufreq: Initial schedpower cpufreq governor arch/arm/Kconfig | 2 + drivers/cpufreq/Kconfig | 8 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq_schedpower.c | 119 +++++++++++++ include/linux/sched/power.h | 29 ++++ kernel/Kconfig.power | 3 + kernel/sched/Makefile | 1 + kernel/sched/fair.c | 43 +++-- kernel/sched/power.c | 307 ++++++++++++++++++++++++++++++++++ kernel/sched/sched.h | 24 +++ 10 files changed, 525 insertions(+), 12 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_schedpower.c create mode 100644 include/linux/sched/power.h create mode 100644 kernel/Kconfig.power create mode 100644 kernel/sched/power.c -- 1.7.9.5

11 years, 10 months

8
63
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel