[PATCH v3 4/7] ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
enable CONFIG_RESET_CONTROLLER in hisi_defconfig Signed-off-by: Jiancheng Xue --- arch/arm/configs/hisi_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig index b2e340b..ba62c07 100644 --- a/arch/arm/configs/hisi_defconfig +++ b/arch/arm/configs/hisi_defconfig @@ -75,6 +75,7 @@ CONFIG_DMADEVICES=y CONFIG_DW_DMAC=y CONFIG_PL330_DMA=y CONFIG_PWM=y +CONFIG_RESET_CONTROLLER=y CONFIG_PHY_HIX5HD2_SATA=y CONFIG_EXT4_FS=y CONFIG_TMPFS=y -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] stm: the number of masters should be (sw_end - sw_start + 1)
On Fri, Dec 11, 2015 at 3:31 PM, Alexander Shishkin wrote: > Chunyan Zhang writes: > >> sw_end represents the last software master, sw_start is index of the >> first master, so the number of software masters should be >> sw_end - sw_start + 1. > > Looks about right, but it needs to be in two separate patches. Will split this patch later. > >> Signed-off-by: Chunyan Zhang >> --- >> drivers/hwtracing/intel_th/sth.c | 2 +- >> drivers/hwtracing/stm/core.c | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/hwtracing/intel_th/sth.c >> b/drivers/hwtracing/intel_th/sth.c >> index 56101c3..28917d7 100644 >> --- a/drivers/hwtracing/intel_th/sth.c >> +++ b/drivers/hwtracing/intel_th/sth.c >> @@ -173,7 +173,7 @@ static int intel_th_sw_init(struct sth_device *sth) >> sth->stm.sw_start = reg & 0x; >> sth->stm.sw_end = reg >> 16; >> >> - sth->sw_nmasters = sth->stm.sw_end - sth->stm.sw_start; >> + sth->sw_nmasters = sth->stm.sw_end - sth->stm.sw_start + 1; >> dev_dbg(sth->dev, "sw_start: %x sw_end: %x masters: %x nchannels: >> %x\n", >> sth->stm.sw_start, sth->stm.sw_end, sth->sw_nmasters, >> sth->stm.sw_nchannels); >> diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c >> index 7f7bdb3..cb676f2 100644 >> --- a/drivers/hwtracing/stm/core.c >> +++ b/drivers/hwtracing/stm/core.c >> @@ -632,7 +632,7 @@ int stm_register_device(struct device *parent, struct >> stm_data *stm_data, >> if (!stm_data->packet || !stm_data->sw_nchannels) >> return -EINVAL; >> >> - nmasters = stm_data->sw_end - stm_data->sw_start; >> + nmasters = stm_data->sw_end - stm_data->sw_start + 1; >> stm = kzalloc(sizeof(*stm) + nmasters * sizeof(void *), GFP_KERNEL); > > Or even offsetof(struct stm_device, masters[stm_data->sw_end]). Ok, I can add this modification in next version, no need to make this being a separated patch, right? > >> if (!stm) >> return -ENOMEM; >> -- >> 1.9.1 > > This is a very old version on git, btw. :) Didn't notice this before :), I have been using the one that Ubuntu 14.04 provided. Thanks, Chunyan > > Thanks, > -- > Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/7] ARM: hisi: add dt_machine definition for Hi3519
add dt_machine definition for hi3519.
Signed-off-by: Jiancheng Xue
---
arch/arm/mach-hisi/hisilicon.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..010d8a2 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -81,3 +81,12 @@ static const char *const hip01_compat[] __initconst = {
DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
.dt_compat = hip01_compat,
MACHINE_END
+
+static const char *const hi3519_compat[] __initconst = {
+ "hisilicon,hi3519",
+ NULL,
+};
+
+DT_MACHINE_START(HI3519_DT, "Hisilicon Hi3519")
+ .dt_compat = hi3519_compat,
+MACHINE_END
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
* Paolo Bonzini wrote:
>
>
> On 10/12/2015 00:12, Andy Lutomirski wrote:
> > From: Andy Lutomirski
> >
> > The pvclock vdso code was too abstracted to understand easily and
> > excessively paranoid. Simplify it for a huge speedup.
> >
> > This opens the door for additional simplifications, as the vdso no
> > longer accesses the pvti for any vcpu other than vcpu 0.
> >
> > Before, vclock_gettime using kvm-clock took about 45ns on my machine.
> > With this change, it takes 29ns, which is almost as fast as the pure TSC
> > implementation.
> >
> > Signed-off-by: Andy Lutomirski
> > ---
> > arch/x86/entry/vdso/vclock_gettime.c | 81
> >
> > 1 file changed, 46 insertions(+), 35 deletions(-)
> >
> > diff --git a/arch/x86/entry/vdso/vclock_gettime.c
> > b/arch/x86/entry/vdso/vclock_gettime.c
> > index ca94fa649251..c325ba1bdddf 100644
> > --- a/arch/x86/entry/vdso/vclock_gettime.c
> > +++ b/arch/x86/entry/vdso/vclock_gettime.c
> > @@ -78,47 +78,58 @@ static notrace const struct pvclock_vsyscall_time_info
> > *get_pvti(int cpu)
> >
> > static notrace cycle_t vread_pvclock(int *mode)
> > {
> > - const struct pvclock_vsyscall_time_info *pvti;
> > + const struct pvclock_vcpu_time_info *pvti = _pvti(0)->pvti;
> > cycle_t ret;
> > - u64 last;
> > - u32 version;
> > - u8 flags;
> > - unsigned cpu, cpu1;
> > -
> > + u64 tsc, pvti_tsc;
> > + u64 last, delta, pvti_system_time;
> > + u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
> >
> > /*
> > -* Note: hypervisor must guarantee that:
> > -* 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> > -* 2. that per-CPU pvclock time info is updated if the
> > -*underlying CPU changes.
> > -* 3. that version is increased whenever underlying CPU
> > -*changes.
> > +* Note: The kernel and hypervisor must guarantee that cpu ID
> > +* number maps 1:1 to per-CPU pvclock time info.
> > +*
> > +* Because the hypervisor is entirely unaware of guest userspace
> > +* preemption, it cannot guarantee that per-CPU pvclock time
> > +* info is updated if the underlying CPU changes or that that
> > +* version is increased whenever underlying CPU changes.
> > *
> > +* On KVM, we are guaranteed that pvti updates for any vCPU are
> > +* atomic as seen by *all* vCPUs. This is an even stronger
> > +* guarantee than we get with a normal seqlock.
> > +*
> > +* On Xen, we don't appear to have that guarantee, but Xen still
> > +* supplies a valid seqlock using the version field.
> > +
> > +* We only do pvclock vdso timing at all if
> > +* PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> > +* mean that all vCPUs have matching pvti and that the TSC is
> > +* synced, so we can just look at vCPU 0's pvti.
> > */
> > - do {
> > - cpu = __getcpu() & VGETCPU_CPU_MASK;
> > - /* TODO: We can put vcpu id into higher bits of pvti.version.
> > -* This will save a couple of cycles by getting rid of
> > -* __getcpu() calls (Gleb).
> > -*/
> > -
> > - pvti = get_pvti(cpu);
> > -
> > - version = __pvclock_read_cycles(>pvti, , );
> > -
> > - /*
> > -* Test we're still on the cpu as well as the version.
> > -* We could have been migrated just after the first
> > -* vgetcpu but before fetching the version, so we
> > -* wouldn't notice a version change.
> > -*/
> > - cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> > - } while (unlikely(cpu != cpu1 ||
> > - (pvti->pvti.version & 1) ||
> > - pvti->pvti.version != version));
> > -
> > - if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> > +
> > + if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
> > *mode = VCLOCK_NONE;
> > + return 0;
> > + }
> > +
> > + do {
> > + version = pvti->version;
> > +
> > + /* This is also a read barrier, so we'll read version first. */
> > + tsc = rdtsc_ordered();
> > +
> > + pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
> > + pvti_tsc_shift = pvti->tsc_shift;
> > + pvti_system_time = pvti->system_time;
> > + pvti_tsc = pvti->tsc_timestamp;
> > +
> > + /* Make sure that the version double-check is last. */
> > + smp_rmb();
> > + } while (unlikely((version & 1) || version != pvti->version));
> > +
> > + delta = tsc - pvti_tsc;
> > + ret = pvti_system_time +
> > + pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
> > + pvti_tsc_shift);
> >
> > /* refer to tsc.c read_tsc() comment for rationale */
> > last = gtod->cycle_last;
> >
>
> Reviewed-by: Paolo Bonzini
Thanks. I've added your Reviewed-by to the 1/5 patch as well - to be able to
put
the whole series
Re: [PATCH v3 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver
Dear MyungJoo,
Almost device tree patches in this series are reviewed by Exynos maintainer.
Could you please review this series?
Best Regards,
Chanwoo Choi
On 2015년 12월 11일 14:07, Chanwoo Choi wrote:
> This patch adds the generic exynos bus frequency driver for AMBA AXI bus
> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
> have the common architecture for bus between DRAM and sub-blocks in SoC.
> This driver can support the generic bus frequency driver for Exynos SoCs.
>
> In devicetree, Each bus block has a bus clock, regulator, operation-point
> and devfreq-event devices which measure the utilization of each bus block.
>
> Signed-off-by: Chanwoo Choi
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon
> ---
> drivers/devfreq/Kconfig | 15 ++
> drivers/devfreq/Makefile| 1 +
> drivers/devfreq/exynos/Makefile | 1 +
> drivers/devfreq/exynos/exynos-bus.c | 449
>
> 4 files changed, 466 insertions(+)
> create mode 100644 drivers/devfreq/exynos/exynos-bus.c
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 64281bb2f650..55ec774f794c 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE
>
> comment "DEVFREQ Drivers"
>
> +config ARM_EXYNOS_BUS_DEVFREQ
> + bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
> + depends on ARCH_EXYNOS
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + select DEVFREQ_EVENT_EXYNOS_PPMU
> + select PM_DEVFREQ_EVENT
> + select PM_OPP
> + help
> + This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
> + Memory bus has one more group of memory bus (e.g, MIF and INT block).
> + Each memory bus group could contain many memoby bus block. It reads
> + PPMU counters of memory controllers by using DEVFREQ-event device
> + and adjusts the operating frequencies and voltages with OPP support.
> + This does not yet operate with optimal voltages.
> +
> config ARM_EXYNOS4_BUS_DEVFREQ
> bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
> depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
> !ARCH_MULTIPLATFORM
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 5134f9ee983d..375ebbb4fcfb 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
> obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
>
> # DEVFREQ Drivers
> +obj-$(CONFIG_ARCH_EXYNOS)+= exynos/
> obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/
> obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/
> obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra-devfreq.o
> diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
> index 49bc9175f923..4ec06d322996 100644
> --- a/drivers/devfreq/exynos/Makefile
> +++ b/drivers/devfreq/exynos/Makefile
> @@ -1,3 +1,4 @@
> # Exynos DEVFREQ Drivers
> +obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
> obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos_ppmu.o exynos4_bus.o
> obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos_ppmu.o exynos5_bus.o
> diff --git a/drivers/devfreq/exynos/exynos-bus.c
> b/drivers/devfreq/exynos/exynos-bus.c
> new file mode 100644
> index ..f1bc20839650
> --- /dev/null
> +++ b/drivers/devfreq/exynos/exynos-bus.c
> @@ -0,0 +1,449 @@
> +/*
> + * Generic Exynos Bus frequency driver with DEVFREQ Framework
> + *
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
> + * Author : Chanwoo Choi
> + *
> + * This driver support Exynos Bus frequency feature by using
> + * DEVFREQ framework and is based on drivers/devfreq/exynos/exynos4_bus.c.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DEFAULT_SATURATION_RATIO 40
> +
> +struct exynos_bus {
> + struct device *dev;
> +
> + struct devfreq *devfreq;
> + struct devfreq_event_dev **edev;
> + unsigned int edev_count;
> + struct mutex lock;
> +
> + struct dev_pm_opp *curr_opp;
> +
> + struct regulator *regulator;
> + struct clk *clk;
> + int ratio;
> +};
> +
> +/*
> + * Control the devfreq-event device to get the current state of bus
> + */
> +#define exynos_bus_ops_edev(ops) \
> +static int exynos_bus_##ops(struct exynos_bus *bus) \
> +{\
> + int i, ret; \
> +
[lkp] [x86/irq] 4c24cee6b2: IP-Config: Auto-configuration of network failed
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
commit 4c24cee6b2aeaee3dab896f76fef4fe79d9e4183 ("x86/irq: Enhance
__assign_irq_vector() to rollback in case of failure")
++++
|| 6dd7cb991f | 4c24cee6b2 |
++++
| boot_successes | 6 | 0 |
| boot_failures | 0 | 8 |
| IP-Config:Auto-configuration_of_network_failed | 0 | 6 |
| BUG:kernel_boot_hang | 0 | 2 |
++++
It appears that the Ethernet card doesn't work properly after your patch.
[ 15.342990] Waiting up to 110 more seconds for network.
[ 25.346987] Waiting up to 100 more seconds for network.
[ 35.350995] Waiting up to 90 more seconds for network.
[ 45.350993] Waiting up to 80 more seconds for network.
[ 55.351006] Waiting up to 70 more seconds for network.
[ 65.350992] Waiting up to 60 more seconds for network.
[ 75.355017] Waiting up to 50 more seconds for network.
[ 85.359009] Waiting up to 40 more seconds for network.
[ 95.363009] Waiting up to 30 more seconds for network.
[ 305.883015] Waiting up to 20 more seconds for network.
[ 315.887002] Waiting up to 10 more seconds for network.
[ 325.887524] Sending DHCP requests .. timed out!
[ 417.893036] IP-Config: Auto-configuration of network failed
[ 417.893852] ALSA device list:
[ 417.894270] No soundcards found.
[ 417.899649] Freeing unused kernel memory: 2884K (82574000 -
82845000)
Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.4.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
#
Re: [GIT PULL 00/11] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit d18929e9fde30c4d57ae57eb9a7f6f10b5808ca1: > > Merge tag 'perf-core-for-mingo' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2015-12-10 09:10:40 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo > > for you to fetch changes up to e7a7865cc0da306542db0b9205cb0a467f59e33d: > > perf symbols: Fix dso__load_sym to put dso (2015-12-10 16:29:32 -0300) > > > perf/core refactorings and fixes: > > Infrastructure: > > - Revert "perf tools: Improve setting of gcc debug option", -Og is broken, > GCC PR created (Jiri Olsa) > > - More reference count fixes (Masami Hiramatsu) > > - Untangle browser setup (--stdio, --tui, etc) from argument checking, > prep work to move the usage() code out of tools/perf for use by > other tools/ living utilities (Namhyung Kim) > > - Delete half-processed hist entries when exiting 'perf top' (Namhyung Kim) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (2): > perf top: Do show usage message when failing to create cpu/thread maps > Revert "perf tools: Improve setting of gcc debug option" > > Masami Hiramatsu (2): > perf tools: Make perf_session__register_idle_thread drop the refcount > perf symbols: Fix dso__load_sym to put dso > > Namhyung Kim (7): > perf annotate: Check argument before calling setup_browser() > perf annotate: Delay UI browser setup after initialization is done > perf kvm: Remove invocation of setup/exit_browser() > perf report: Check argument before calling setup_browser() > perf thread_map: Free strlist on constructor error path > perf tools: Get rid of exit_browser() from usage_with_options() > perf top: Delete half-processed hist entries when exit > > tools/perf/builtin-annotate.c | 33 - > tools/perf/builtin-kvm.c| 3 --- > tools/perf/builtin-report.c | 21 ++--- > tools/perf/builtin-top.c| 9 ++--- > tools/perf/config/Makefile | 2 -- > tools/perf/config/utilities.mak | 19 --- > tools/perf/util/hist.c | 26 +- > tools/perf/util/parse-options.c | 3 --- > tools/perf/util/session.c | 11 +++ > tools/perf/util/session.h | 2 +- > tools/perf/util/symbol-elf.c| 9 +++-- > tools/perf/util/thread_map.c| 1 + > 12 files changed, 73 insertions(+), 66 deletions(-) Pulled, thanks a lot Arnaldo! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET v2] ->follow_link() without dropping from RCU mode
On Fri, Dec 11 2015, Al Viro wrote:
> I would really love to be able to say
> set_delayed_call(done, kfree, p);
> but as it is I had to keep a wrapper - void kfree_link(void *). The problem
> is, you can't assign void f(const void *) to void (*p)(void *) - mismatch of
> qualifiers in the arguments makes the latter not assignment-compatible with
> the former. If there's a clever trick allowing to sidestep that, I'd be
> very happy; I don't know one. Any ideas not starting with "use C11" (or,
> worse yet, "use such and such C++ misfeature with arseloads of RTL required
> in order to implement it") would be welcome...
I _think_ this satisfies these very reasonable criteria. What you're
looking for is presumably __attribute__((__transparent_union__)). At
least this compiles without warnings at -Wall -Wextra and gives the
expected disassembly, and the gcc docs mention transparent_union at
least back to 4.0.4.
#include
struct delayed_call {
void (*fn)(void *);
void *arg;
};
union delayed_call_fn {
void (*fn)(void *);
void (*kfree_like)(const void *);
} __attribute__((__transparent_union__));
void
set_delayed_call(struct delayed_call *call, union delayed_call_fn u, void *arg)
{
call->fn = u.fn;
call->arg = arg;
}
void some_cb(void *);
void kfree(const void *);
extern struct delayed_call done;
void test(void)
{
set_delayed_call(, some_cb, NULL);
set_delayed_call(, kfree, NULL);
}
Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv6 PATCH 09/10] sched: deadline: use deadline bandwidth in scale_rt_capacity
Hi Vincent, On 12/10/2015 05:11 PM, Vincent Guittot wrote: [...] If yes, I think your approach is safe (and easier to implement - modulo a small issue when a task terminates of switches to other scheduling policies; I think there already are some "XXX" comments in the current code). However, it allows to save less energy (or reclaim less CPU time). For example, if I create a SCHED_DEADLINE task with runtime 90ms and period 100ms it will not allow to scale the CPU frequency even if it never executes (because is always blocked). Yes, i agree. If the task behavior is not aligned with its deadline parameters, we will over provisioned CPU capacity to the deadline scheduler. This metric is not used to select the OPP but to provisioned some CPU capacity to the deadline scheduler and to inform the CFS scheduler of the remaining capacity. Ah, sorry; I missed this point. + /* This is the "average utilization" for this runqueue */ + s64 avg_bw; }; Small nit: why "average" utilization? I think a better name would be "runqueue utilization" or "local utilization", or something similar... If I understand correctly (sorry if I missed something), this is not an average, but the sum of the utilisations of the tasks on this runqueue... No? I have used "average" because it doesn't reflect the active/actual utilization of the run-queue but the forecasted average bandwidth of the CPU that will be used by deadline task. Well, this is just nitpicking, so feel free to ignore (I just mentioned this point because I was initially confused by the "average" name). But I think this is "maximum", or "worst-case", not "average", because (as far as I can understand) this field indicates that SCHED_DEADLINE tasks will not be able to consume more than this fraction of CPU (if they try to consume more, the scheduler throttles them). I'm open to change the name if another one makes more sense In real-time literature this is often called simply "utilization" (or "worst-case utilization" by someone): when a task can have a variable execution time, its utilization is defined as WCET (maximum execution time) / period. Luca -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch/powerpc/Kconfig: fix typo in select statement
The 'I' in sanitize was missing:
s/ARCH_HAS_UBSAN_SANTIZE_ALL/ARCH_HAS_UBSAN_SANITIZE_ALL/
Fixes: 257e4ee82dbd ("powerpc: enable UBSAN support")
Signed-off-by: Valentin Rothberg
---
Detected with ./scripts/checkkconfigsymbols.py
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b0420a8c458e..4de86d145f17 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -157,7 +157,7 @@ config PPC
select EDAC_ATOMIC_SCRUB
select ARCH_HAS_DMA_SET_COHERENT_MASK
select HAVE_ARCH_SECCOMP_FILTER
- select ARCH_HAS_UBSAN_SANTIZE_ALL
+ select ARCH_HAS_UBSAN_SANITIZE_ALL
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2
On Fri, Dec 11, 2015 at 11:48:57AM +0900, Kamezawa Hiroyuki wrote: > On 2015/12/10 20:39, Vladimir Davydov wrote: > > In the legacy hierarchy we charge memsw, which is dubious, because: > > > > - memsw.limit must be >= memory.limit, so it is impossible to limit > > swap usage less than memory usage. Taking into account the fact that > > the primary limiting mechanism in the unified hierarchy is > > memory.high while memory.limit is either left unset or set to a very > > large value, moving memsw.limit knob to the unified hierarchy would > > effectively make it impossible to limit swap usage according to the > > user preference. > > > > - memsw.usage != memory.usage + swap.usage, because a page occupying > > both swap entry and a swap cache page is charged only once to memsw > > counter. As a result, it is possible to effectively eat up to > > memory.limit of memory pages *and* memsw.limit of swap entries, which > > looks unexpected. > > > > That said, we should provide a different swap limiting mechanism for > > cgroup2. > > > > This patch adds mem_cgroup->swap counter, which charges the actual > > number of swap entries used by a cgroup. It is only charged in the > > unified hierarchy, while the legacy hierarchy memsw logic is left > > intact. > > > > The swap usage can be monitored using new memory.swap.current file and > > limited using memory.swap.max. > > > > Signed-off-by: Vladimir Davydov > > setting swap.max=0 will work like mlock ? For anonymous memory - yes. Thanks, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
On 10.12.2015 18:25, Bjorn Helgaas wrote: > On Thu, Dec 10, 2015 at 08:02:05AM +0100, Michal Simek wrote: >> Hi Bjorn, >> >> On 10.12.2015 00:19, Bjorn Helgaas wrote: >>> [+cc Michal, Paul, Thierry, Stephen, Alexandre (see irq_dispose_mapping >>> questions below)] >>> >>> On Sun, Nov 29, 2015 at 05:33:53PM +0530, Bharat Kumar Gogada wrote: Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP. Signed-off-by: Bharat Kumar Gogada Signed-off-by: Ravi Kiran Gummaluri Acked-by: Rob Herring >>> >>> This needs either a MAINTAINERS update or an ack from Michal (whose >>> MAINTAINERS entry matches anything containing "xilinx"). >> >> We have done it in this way because driver owners are changing time to >> time and my entry cover it that I can pass it to appropriate person who >> is responsible for it. >> >> For this Maintainers part here is my: >> Acked-by: Michal Simek > > Thanks. > > For things under drivers/pci/host, I ask for an ack from the > individual maintainer before applying patches. As-is (without a > MAINTAINERS update) I'll be looking for acks from you, Michal, for all > future changes to pcie-xilinx-nwl.c. If you want something else, we > need a MAINTAINERS change. ok. No problem with it. I will get HW pretty soon and I will be able to do some testing my self when some others changes come. Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 02/10] Drivers: hv: utils: run polling callback always in interrupt context
> -Original Message-
> From: KY Srinivasan
> Sent: Friday, December 11, 2015 7:23
> > It looks the patch has not been Greg's tree yet.
> >
> > I have 2 questions about the patch:
> >
> > 1. hv_poll_channel() is invoked in fcopy_handle_handshake(), but not in
> > vss_handle_handshake() and kvp_handle_handshake().
> > Why -- I guess we missed the vss/kvp cases somehow?
> I will fix this.
Thanks, KY!
BTW, I fixed another small issue by https://lkml.org/lkml/2015/12/10/50
(The mail is attached for your convenience)
> > 2. With the patch, hv_fcopy_onchannelcallback() can be invoked in the
> > tasklet (i.e., vmbus_on_event(). NB: local irq is enabled), and in the
> > hard irq handler(the IPI handler, e.g.,
> > fcopy_poll_wrapper() -> fcopy_poll_wrapper()).
> >
> > Can the former be interrupted by the latter?
> > e.g., when the callback is running in the tasklet on vCPU0,
> > fcopy_timeout_func() or fcopy_on_msg() could send the IPI to
> > vCPU0 from another vCPU.
>
> Keep in mind that when the poll function is run, the state will not be
> HVUTIL_READY. The state will be set to HVUTIL_READY in the IPI
> handler. So, it is ok if the tasklet is interrupted by the IPI handler.
>
> K. Y
Got it.
BTW, in fcopy_handle_handshake(), IMO the line
fcopy_transaction.state = HVUTIL_READY;
just before
hv_poll_channel(fcopy_transaction.recv_channel, fcopy_poll_wrapper);
should be removed? Because in fcopy_poll_wrapper() we always have
the same line.
Ditto for kvp/vss.
Thanks,
-- Dexuan
--- Begin Message ---
I found this by chance. I don't have a specific bug caused by this.
Cc: Vitaly Kuznetsov
Cc: "K. Y. Srinivasan"
Signed-off-by: Dexuan Cui
Cc: sta...@vger.kernel.org
---
tools/hv/hv_vss_daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 96234b6..5d51d6f 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -254,7 +254,7 @@ int main(int argc, char *argv[])
syslog(LOG_ERR, "Illegal op:%d\n", op);
}
vss_msg->error = error;
- len = write(vss_fd, , sizeof(struct hv_vss_msg));
+ len = write(vss_fd, vss_msg, sizeof(struct hv_vss_msg));
if (len != sizeof(struct hv_vss_msg)) {
syslog(LOG_ERR, "write failed; error: %d %s", errno,
strerror(errno));
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdriverdev.linuxdriverproject.org%2fmailman%2flistinfo%2fdriverdev-devel=01%7c01%7cdecui%40064d.mgd.microsoft.com%7c6038ce2d24784746fa0408d30134f8d9%7c72f988bf86f141af91ab2d7cd011db47%7c1=6Hs1UNlA11wBtnU5XvHhpCgkUlIhWVMKxPHVj9UAZq8%3d
--- End Message ---
Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)
On Thu, Dec 10, 2015 at 07:29:34PM -0800, Andrew Pinski wrote: > On Thu, Dec 10, 2015 at 11:44 AM, David Danny wrote: > > > > Hi, > > > > We are getting soft lockup OOPs on Cavium CN88XX (A.K.A. ThunderX), which > > is an arm64 implementation. > > I get a slightly different OOPs and reverting > c55a6ffa6285e29f874ed403979472631ec70bff I was able to boot. > What I saw with osq_lock.c was that osq_wait_next is called for both > lock and unlock case so it might need both barriers. > The other question comes does atomic_cmpxchg_release have release > semantics when the compare fails? Right now it does not. > Out cmpxchg primites imply no barrier on failure, this is documented somewhere.. /me searches.. --- commit ed2de9f74ecbbf3063d29b2334e7b455d7f35189 Author: Will Deacon Date: Thu Jul 16 16:10:06 2015 +0100 locking/Documentation: Clarify failed cmpxchg() memory ordering semantics A failed cmpxchg does not provide any memory ordering guarantees, a property that is used to optimise the cmpxchg implementations on Alpha, PowerPC and arm64. This patch updates atomic_ops.txt and memory-barriers.txt to reflect this. Signed-off-by: Will Deacon Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Davidlohr Bueso Cc: Douglas Hatch Cc: H. Peter Anvin Cc: Jonathan Corbet Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Scott J Norton Cc: Thomas Gleixner Cc: Waiman Long Link: http://lkml.kernel.org/r/20150716151006.gh26...@arm.com Signed-off-by: Ingo Molnar diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index dab6da3382d9..b19fc34efdb1 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -266,7 +266,9 @@ with the given old and new values. Like all atomic_xxx operations, atomic_cmpxchg will only satisfy its atomicity semantics as long as all other accesses of *v are performed through atomic_xxx operations. -atomic_cmpxchg must provide explicit memory barriers around the operation. +atomic_cmpxchg must provide explicit memory barriers around the operation, +although if the comparison fails then no memory ordering guarantees are +required. The semantics for atomic_cmpxchg are the same as those defined for 'cas' below. diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 13feb697271f..18fc860df1be 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -2383,9 +2383,7 @@ about the state (old or new) implies an SMP-conditional general memory barrier explicit lock operations, described later). These include: xchg(); - cmpxchg(); atomic_xchg(); atomic_long_xchg(); - atomic_cmpxchg(); atomic_long_cmpxchg(); atomic_inc_return();atomic_long_inc_return(); atomic_dec_return();atomic_long_dec_return(); atomic_add_return();atomic_long_add_return(); @@ -2398,7 +2396,9 @@ about the state (old or new) implies an SMP-conditional general memory barrier test_and_clear_bit(); test_and_change_bit(); - /* when succeeds (returns 1) */ + /* when succeeds */ + cmpxchg(); + atomic_cmpxchg(); atomic_long_cmpxchg(); atomic_add_unless();atomic_long_add_unless(); These are used for such things as implementing ACQUIRE-class and RELEASE-class -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] stm: the number of masters should be (sw_end - sw_start + 1)
Chunyan Zhang writes: > sw_end represents the last software master, sw_start is index of the > first master, so the number of software masters should be > sw_end - sw_start + 1. Looks about right, but it needs to be in two separate patches. > Signed-off-by: Chunyan Zhang > --- > drivers/hwtracing/intel_th/sth.c | 2 +- > drivers/hwtracing/stm/core.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/intel_th/sth.c > b/drivers/hwtracing/intel_th/sth.c > index 56101c3..28917d7 100644 > --- a/drivers/hwtracing/intel_th/sth.c > +++ b/drivers/hwtracing/intel_th/sth.c > @@ -173,7 +173,7 @@ static int intel_th_sw_init(struct sth_device *sth) > sth->stm.sw_start = reg & 0x; > sth->stm.sw_end = reg >> 16; > > - sth->sw_nmasters = sth->stm.sw_end - sth->stm.sw_start; > + sth->sw_nmasters = sth->stm.sw_end - sth->stm.sw_start + 1; > dev_dbg(sth->dev, "sw_start: %x sw_end: %x masters: %x nchannels: %x\n", > sth->stm.sw_start, sth->stm.sw_end, sth->sw_nmasters, > sth->stm.sw_nchannels); > diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c > index 7f7bdb3..cb676f2 100644 > --- a/drivers/hwtracing/stm/core.c > +++ b/drivers/hwtracing/stm/core.c > @@ -632,7 +632,7 @@ int stm_register_device(struct device *parent, struct > stm_data *stm_data, > if (!stm_data->packet || !stm_data->sw_nchannels) > return -EINVAL; > > - nmasters = stm_data->sw_end - stm_data->sw_start; > + nmasters = stm_data->sw_end - stm_data->sw_start + 1; > stm = kzalloc(sizeof(*stm) + nmasters * sizeof(void *), GFP_KERNEL); Or even offsetof(struct stm_device, masters[stm_data->sw_end]). > if (!stm) > return -ENOMEM; > -- > 1.9.1 This is a very old version on git, btw. :) Thanks, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 18/20] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
On 2015년 12월 11일 16:18, Krzysztof Kozlowski wrote: > On 11.12.2015 14:07, Chanwoo Choi wrote: >> This patch adds the bus device-tree node of INT (internal) block >> to enable the bus frequency scaling. The following sub-blocks share >> the VDD_INT power source: >> - LEFTBUS (parent device) >> - RIGHTBUS >> - PERIL >> - LCD0 >> - FSYS >> - MCUISP / ISP >> - MFC >> >> The LEFTBUS is parent device with devfreq ondemand governor >> and the rest devices has the dependency on LEFTBUS bus. > > I pointed this previously. If you wish to leave the sentence in such > form then "rest of" and "have" not "has". It is my mistake. I'll modify it as following your comment: - "and the rest of devices depend on the LEFTBUS device." Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 17/20] ARM: dts: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU node
On 2015년 12월 11일 16:15, Krzysztof Kozlowski wrote: > On 11.12.2015 14:07, Chanwoo Choi wrote: >> This patch adds the exynos4412-ppmu-common.dtsi to duplicate PPMU node > > I think the goal of the patch was to remove duplication of nodes, not to > duplicate them. :) OK. I'll modify both subject and description of this patch. > > Except of that patch is okay: > > Reviewed-by: Krzysztof Kozlowski [snip] Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 3/5] memory: mediatek: Add SMI driver
On Tue, 2015-12-08 at 17:49 +0800, Yong Wu wrote: > This patch add SMI(Smart Multimedia Interface) driver. This driver > is responsible to enable/disable iommu and control the power domain > and clocks of each local arbiter. > > Signed-off-by: Yong Wu > --- Hi Matthias, Because drivers/memory/ don't have the maintainer, and our IOMMU, V4L2 and DRM rely on the SMI. From Joerg and Thierry[1], we need your help. Could you have a loot at our SMI while free? Look forward to any comment from you. Thanks. [1]http://lists.linuxfoundation.org/pipermail/iommu/2015-November/014981.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 20/20] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3
On 11.12.2015 14:07, Chanwoo Choi wrote:
> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
> (Internal) block to enable the bus frequency.
>
> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
> bus is parent device in INT block using VDD_INT.
>
> Signed-off-by: Chanwoo Choi
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47
> arch/arm/boot/dts/exynos4412-trats2.dts | 48
> +
> 2 files changed, 95 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 7bd65026761e..b6818aec7cf9 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -501,3 +501,50 @@
> {
> status = "okay";
> };
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
I meant put them in proper place, respecting alphabetical order. The 'b'
comes before 'w'.
As for the new nodes (bus_XXX) your previous sorting (first parent, then
passive) was also okay - it had sense. This is up to you. Just put
everything not at the end of file.
Best regards,
Krzysztof
> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 92438eb6eec6..0b8aff3b8cb7 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -1251,3 +1251,51 @@
> vtmu-supply = <_reg>;
> status = "okay";
> };
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 18/20] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the bus device-tree node of INT (internal) block > to enable the bus frequency scaling. The following sub-blocks share > the VDD_INT power source: > - LEFTBUS (parent device) > - RIGHTBUS > - PERIL > - LCD0 > - FSYS > - MCUISP / ISP > - MFC > > The LEFTBUS is parent device with devfreq ondemand governor > and the rest devices has the dependency on LEFTBUS bus. I pointed this previously. If you wish to leave the sentence in such form then "rest of" and "have" not "has". Best regards, Krzysztof > > Signed-off-by: Chanwoo Choi > Reviewed-by: Krzysztof Kozlowski > --- > arch/arm/boot/dts/exynos3250-rinato.dts | 41 > + > 1 file changed, 41 insertions(+) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 17/20] ARM: dts: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU node
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the exynos4412-ppmu-common.dtsi to duplicate PPMU node I think the goal of the patch was to remove duplication of nodes, not to duplicate them. :) Except of that patch is okay: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof > because exynos3250-rinato/monk, exynos4412-trats2/odroidu3 has the same > PPMU device tree node. > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos3250-monk.dts | 41 + > arch/arm/boot/dts/exynos3250-rinato.dts | 41 + > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 + > arch/arm/boot/dts/exynos4412-ppmu-common.dtsi | 49 > + > arch/arm/boot/dts/exynos4412-trats2.dts | 41 + > 5 files changed, 53 insertions(+), 120 deletions(-) > create mode 100644 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PICKME 0/2] cpufreq: New ST driver
On Fri, 11 Dec 2015, Viresh Kumar wrote: > On 10-12-15, 22:38, Rafael J. Wysocki wrote: > > Do they depend on anything special? > > My opp-binding-parsing patches which you applied to bleeding-edge. I thought these had already been applied. > Yes, Lee should have mentioned that explicitly. Aye, apologies for that. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] I2C: designware: fix IO timeout issue for AMD controller
Because of some hardware limitation, AMD I2C controller can't
trigger pending interrupt if interrupt status has been changed
after clearing interrupt status bits. Then, I2C will lost
interrupt and IO timeout.
According to hardware design, this patch implements a workaround
to disable i2c controller interrupt and re-enable i2c interrupt
before exiting ISR.
To reduce the performance impacts on other vendors, use unlikely
function to check flag in ISR.
---
Changes in v2:
- pass flags with ->driver_data
- unmask interrupt right after masking
Signed-off-by: Xiangliang Yu
---
drivers/i2c/busses/i2c-designware-core.c| 6 ++
drivers/i2c/busses/i2c-designware-core.h| 1 +
drivers/i2c/busses/i2c-designware-platdrv.c | 7 ++-
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 8c48b27..de7fbbb 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -813,6 +813,12 @@ static irqreturn_t i2c_dw_isr(int this_irq, void *dev_id)
tx_aborted:
if ((stat & (DW_IC_INTR_TX_ABRT | DW_IC_INTR_STOP_DET)) || dev->msg_err)
complete(>cmd_complete);
+ else if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK)) {
+ /* workaround to trigger pending interrupt */
+ stat = dw_readl(dev, DW_IC_INTR_MASK);
+ i2c_dw_disable_int(dev);
+ dw_writel(dev, stat, DW_IC_INTR_MASK);
+ }
return IRQ_HANDLED;
}
diff --git a/drivers/i2c/busses/i2c-designware-core.h
b/drivers/i2c/busses/i2c-designware-core.h
index 1d50898..9ffb63a 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -111,6 +111,7 @@ struct dw_i2c_dev {
#define ACCESS_SWAP0x0001
#define ACCESS_16BIT 0x0002
+#define ACCESS_INTR_MASK 0x0004
extern int i2c_dw_init(struct dw_i2c_dev *dev);
extern void i2c_dw_disable(struct dw_i2c_dev *dev);
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 809579e..f03ea71 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -93,6 +93,7 @@ static void dw_i2c_acpi_params(struct platform_device *pdev,
char method[],
static int dw_i2c_acpi_configure(struct platform_device *pdev)
{
struct dw_i2c_dev *dev = platform_get_drvdata(pdev);
+ const struct acpi_device_id *id;
dev->adapter.nr = -1;
dev->tx_fifo_depth = 32;
@@ -106,6 +107,10 @@ static int dw_i2c_acpi_configure(struct platform_device
*pdev)
dw_i2c_acpi_params(pdev, "FMCN", >fs_hcnt, >fs_lcnt,
>sda_hold_time);
+ id = acpi_match_device(pdev->dev.driver->acpi_match_table, >dev);
+ if (id && id->driver_data)
+ dev->accessor_flags |= (u32)id->driver_data;
+
return 0;
}
@@ -116,7 +121,7 @@ static const struct acpi_device_id dw_i2c_acpi_match[] = {
{ "INT3433", 0 },
{ "80860F41", 0 },
{ "808622C1", 0 },
- { "AMD0010", 0 },
+ { "AMD0010", ACCESS_INTR_MASK },
{ }
};
MODULE_DEVICE_TABLE(acpi, dw_i2c_acpi_match);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 16/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4210
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the bus nodes for Exynos4210 SoC. Exynos4210 SoC has > one power line for all buses to translate data between DRAM and sub-blocks. > > Following list specifies the detailed relation between DRAM and sub-blocks: > - DMC/ACP clock for DMC (Dynamic Memory Controller) > - ACLK200 clock for LCD0 > - ACLK100 clock for PERIL/PERIR/MFC(PCLK) > - ACLK160 clock for CAM/TV/LCD0/LCD1 > - ACLK133 clock for FSYS/GPS > - GDL/GDR clock for LEFTBUS/RIGHTBUS > - SCLK_MFC clock for MFC > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos4210.dtsi | 159 > ++ > 1 file changed, 159 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 15/20] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the bus noes using VDD_INT for Exynos4x12 SoC. > Exynos4x12 has the following AXI buses to translate data between > DRAM and sub-blocks. > > Following list specifies the detailed relation between DRAM and sub-blocks: > - ACLK100 clock for PERIL/PERIR/MFC(PCLK) > - ACLK160 clock for CAM/TV/LCD > : The minimum clock of ACLK160 should be over 160MHz. > When drop the clock under 160MHz, show the broken image. > - ACLK133 clock for FSYS > - GDL clock for LEFTBUS > - GDR clock for RIGHTBUS > - SCLK_MFC clock for MFC > > Signed-off-by: Chanwoo Choi > [linux.amoon: Tested on Odroid U3] > Tested-by: Anand Moon > --- > arch/arm/boot/dts/exynos4x12.dtsi | 106 > ++ > 1 file changed, 106 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 14/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12
On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.
"noes", pointed at v2.
> Exynos4x12 has the following AXI buses to translate data
> between DRAM and DMC/ACP/C2C.
>
> Signed-off-by: Chanwoo Choi
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon
> ---
> arch/arm/boot/dts/exynos4x12.dtsi | 68
> +++
> 1 file changed, 68 insertions(+)
The code itself:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 84a23f962946..99a0f4ca3d47 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -281,6 +281,74 @@
> clocks = < CLK_SMMU_LITE1>, < CLK_FIMC_LITE1>;
> #iommu-cells = <0>;
> };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_acp: bus_acp {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACP>;
> + clock-names = "bus";
> + operating-points-v2 = <_acp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_c2c: bus_c2c {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_C2C>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp@1 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp@13400 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <90>;
> + };
> + opp@16000 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <90>;
> + };
> + opp@26700 {
> + opp-hz = /bits/ 64 <26700>;
> + opp-microvolt = <95>;
> + };
> + opp@4 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <105>;
> + };
> + };
> +
> + bus_acp_opp_table: opp_table2 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp@1 {
> + opp-hz = /bits/ 64 <1>;
> + };
> + opp@13400 {
> + opp-hz = /bits/ 64 <13400>;
> + };
> + opp@16000 {
> + opp-hz = /bits/ 64 <16000>;
> + };
> + opp@26700 {
> + opp-hz = /bits/ 64 <26700>;
> + };
> + };
> };
>
> {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/9] ACPI: add struct acpi_amba_quirk for AMD pl330 specific device config
>-Original Message-
>From: Graeme Gregory [mailto:g...@slimlogic.co.uk]
>Sent: Friday, December 04, 2015 9:16 PM
>To: Wang, Annie
>Cc: Vinod Koul; Mika Westerberg; Joerg Roedel; Greg Kroah-Hartman; Rafael J.
>Wysocki; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
>ser...@vger.kernel.org; dmaeng...@vger.kernel.org; iommu@lists.linux-
>foundation.org; Borislav Petkov; Huang, Ray; Wan, Vincent; Xue, Ken; Li, Tony
>Subject: Re: [PATCH 3/9] ACPI: add struct acpi_amba_quirk for AMD pl330
>specific device config
>
>On Fri, Dec 04, 2015 at 11:24:20AM +0800, Wang Hongcheng wrote:
>> AMD pl330 is a UART DMA device, it shares one ACPI item with UART. So
>> a platform device and an acpi device will be created according to
>> AMD0020 ACPI dev. And its mem base address must have an offset. As a
>> result, MULTI_ATTACHED_QUIRK and MULTI_ATTACHED_QUIRK are used.
>>
>> Signed-off-by: Wang Hongcheng
>> ---
>> drivers/acpi/acpi_amba.c | 31 +++
>> drivers/acpi/acpi_apd.c | 56 +--
>-
>> include/linux/acpi.h | 13 +--
>> 3 files changed, 81 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c index
>> 4f0366a..8a5269c 100644
>> --- a/drivers/acpi/acpi_amba.c
>> +++ b/drivers/acpi/acpi_amba.c
>> @@ -31,6 +31,8 @@ ACPI_MODULE_NAME("amba");
>> * @periphid: AMBA device periphid.
>> * @fixed_rate: Clock frequency.
>> * @pdata: Platform data specific to the device.
>> + * @quirk: Specific device config, including device multiattach.
>> + * and mem base offset.
>> *
>> * Check if the given @adev can be represented as an AMBA device and, if
>> * that's the case, create and register an AMBA device, populate its
>> @@ -42,7 +44,8 @@ ACPI_MODULE_NAME("amba"); struct amba_device
>> *acpi_create_amba_device(struct acpi_device *adev,
>> unsigned int periphid,
>> unsigned long fixed_rate,
>> -void *pdata)
>> +void *pdata,
>> +struct acpi_amba_quirk *quirk)
>> {
>> struct amba_device *amba_dev = NULL;
>> struct device *parent;
>> @@ -54,12 +57,14 @@ struct amba_device *acpi_create_amba_device(struct
>acpi_device *adev,
>> unsigned int i;
>> unsigned int irq[AMBA_NR_IRQS];
>> struct clk *clk = ERR_PTR(-ENODEV);
>> +char amba_devname[100];
>>
>> /*
>> * If the ACPI node already has a physical device attached,
>> - * skip it.
>> + * skip it. Except some special devices such as AMD0020 which
>> + * needs attach physical devices two times.
>> */
>> -if (adev->physical_node_count)
>> +if (adev->physical_node_count && !(quirk->quirk &
>> +MULTI_ATTACHED_QUIRK))
>> return NULL;
>>
>> INIT_LIST_HEAD(_list);
>> @@ -85,7 +90,24 @@ struct amba_device *acpi_create_amba_device(struct
>acpi_device *adev,
>> memcpy(resource, rentry->res, sizeof(struct resource));
>> }
>>
>> -amba_dev = amba_device_alloc(dev_name(>dev),
>> +/*
>> + * The memory address of AMD pl330 has an offset of ACPI
>> + * mem resource.
>> + */
>> +if (quirk->quirk & BASE_OFFSET_QUIRK)
>> +resource->start += quirk->base_offset;
>> +
>> +/*
>> + * If the ACPI device already has a node attached. It must be
>> + * renamed.
>> + */
>> +if (quirk->quirk & MULTI_ATTACHED_QUIRK)
>> +sprintf(amba_devname, "%s%s", dev_name(>dev),
>"DMA");
>> +else
>> +memcpy(amba_devname, dev_name(>dev),
>> + strlen(dev_name(>dev)));
>> +
>> +amba_dev = amba_device_alloc(amba_devname,
>> resource->start,
>> resource_size(resource));
>>
>
>Isn't this basially an MFD in a rather odd fashion?
>
>I would have though having a device which just splits the resources then
>creates 2
>children would be a whole lot simpler?
>
>Graeme
It seems more complex, if I trans an ACPI device to pdev, then attach 2
platform child nodes,
and create an amba device refer to one of the childs. Too many trans.
Thanks,
Hongcheng(Annie)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 13/20] ARM: dts: Add bus nodes using VDD_INT for Exynos3250
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the bus nodes using VDD_INT for Exynos3250 SoC. > Exynos3250 has following AXI buses to translate data between > DRAM and sub-blocks. > > Following list specifies the detailed relation between DRAM and sub-blocks: > - ACLK400 clock for MCUISP > - ACLK266 clock for ISP > - ACLK200 clock for FSYS > - ACLK160 clock for LCD0 > - ACLK100 clock for PERIL > - GDL clock for LEFTBUS > - GDR clock for RIGHTBUS > - SCLK_MFC clock for MFC > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos3250.dtsi | 147 > ++ > 1 file changed, 147 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging:rtl8192u: fixes the following sparse warning:
On Fri, Dec 11, 2015 at 01:52:11PM +0800, Jandy Gou wrote:
> drivers/staging/rtl8192u/r8192U_core.c:3212:6: warning: symbol
> 'rtl819x_watchdog_wqcallback' was not declared. Should it be static?
> drivers/staging/rtl8192u/r8192U_core.c:3276:6: warning: symbol
> 'watch_dog_timer_callback' was not declared. Should it be static?
> drivers/staging/rtl8192u/r8192U_core.c:3282:5: warning: symbol
> '_rtl8192_up' was not declared. Should it be static?
> drivers/staging/rtl8192u/r8192U_core.c::5: warning: symbol
> 'rtl8192_close' was not declared. Should it be static?
> drivers/staging/rtl8192u/r8192U_core.c:3406:6: warning: symbol
> 'rtl8192_restart' was not declared. Should it be static?
> drivers/staging/rtl8192u/r8192U_core.c:4618:6: warning: symbol
> 'rtl8192_irq_rx_tasklet' was not declared. Should it be static?
> drivers/staging/rtl8192u/r8192U_core.c:4736:6: warning: symbol
> 'rtl8192_cancel_deferred_work' was not declared. Should it be static?
>
> Signed-off-by: Jandy Gou
> ---
This has already been done by commit:
bdc01d5711b3 ("staging: rtl8192u: Make core functions static")
And the commit date shows April.
Which tree are you using?
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm fixes
Hi Linus, Not too much this time. One nouveau workaround extended to a few more GPUs. Some amdgpu big endian fixes, and a regression fixer. Some vmwgfx fixes One ttm locking fix. One vgaarb fix. Dave. The following changes since commit aa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85: Merge branch 'for-linus-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml (2015-12-08 17:22:45 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 9f5bd30818c42c6c36a51f93b4df75a2ea2bd85e: vgaarb: fix signal handling in vga_get() (2015-12-11 14:04:44 +1000) Ben Skeggs (1): drm/nouveau/pmu: remove whitelist for PGOB-exit WAR, enable by default Chunming Zhou (1): drm/amdgpu: fix the lost duplicates checking Dan Carpenter (1): drm/vmwgfx: fix a warning message Dave Airlie (3): Merge branch 'linux-4.4' of https://github.com/skeggsb/linux into drm-fixes Merge tag 'vmwgfx-fixes-4.4-151208' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Kirill A. Shutemov (1): vgaarb: fix signal handling in vga_get() Oded Gabbay (3): radeon/cik: Fix GFX IB test on Big-Endian radeon: Fix VCE ring test for Big-Endian systems radeon: Fix VCE IB test on Big-Endian systems Thomas Hellstrom (2): drm/ttm: Fixed a read/write lock imbalance drm/vmwgfx: Implement the cursor_set2 callback v2 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 8 ++ drivers/gpu/drm/nouveau/include/nvkm/core/device.h | 1 - drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 35 +--- drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gk104.c| 4 +- drivers/gpu/drm/radeon/cik.c | 6 +- drivers/gpu/drm/radeon/radeon_vce.c| 100 ++--- drivers/gpu/drm/ttm/ttm_lock.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 1 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 1 + drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 64 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h| 7 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +- drivers/gpu/vga/vgaarb.c | 6 +- 16 files changed, 131 insertions(+), 112 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: goldfish: Coding Style Fix Comparison to NULL could
On Thu, Dec 10, 2015 at 06:31:09PM -0500, Benjamin Young wrote: > From 4b8ce6b3bd7effdfff2c95fbeb4a20cb93d5e9e5 Mon Sep 17 00:00:00 2001 > From: Benjamin Young > Date: Thu, 10 Dec 2015 17:31:00 -0500 > Subject: [PATCH] staging: goldfish: Coding Style Fix - spaces preferred around > that '+' Regarding all the three patches: The above header information should not be here. Regarding this patch: This is a repeat of the previous patch with the subject of the next patch. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/38] selftests/timers: fix write return value handlng
On Mon, Sep 21, 2015 at 6:33 AM, Andrzej Hajda wrote: > The function can return negative value. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 > > Signed-off-by: Andrzej Hajda Sheesh. Apologies for being so late on this. I just noticed I miss-filed this and it slipped through my to-queue list. Looks good. Thanks for sending this in. I'll queue it for 4.5 thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 03/20] ARM: dts: Add DMC bus node for Exynos3250
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 > SoC. > The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard > SDRAM devices. The bus includes the OPP tables and the source clock for DMC > block. > > Following list specifies the detailed relation between the clock and DMC > block: > - The source clock of DMC block : div_dmc > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos3250.dtsi | 34 ++ > 1 file changed, 34 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/20] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the documentation for generic exynos bus frequency > driver. > > Signed-off-by: Chanwoo Choi > --- > .../devicetree/bindings/devfreq/exynos-bus.txt | 93 > ++ > 1 file changed, 93 insertions(+) > create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt > Thanks, now it looks good to me. Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] printk: Hand over printing to console if printing too long
On (12/11/15 13:27), Sergey Senozhatsky wrote:
[..]
> > static bool cpu_stop_printing(int printed_chars)
> > {
> > /* Oops? Print everything now to maximize chances user will see it
> > */
> > if (oops_in_progress)
> > return false;
> > if (!printk_offload_chars || printed_chars < printk_offload_chars)
> > return false;
> > /*
> > * Make sure we load fresh value of printing_tasks_spinning. Matches
> > * the barrier in printing_task()
> > */
> > smp_rmb();
> > if (atomic_read(_tasks_spinning))
> > return true;
> > wake_up(_queue);
> >
> - return false;
> + return true;
> > }
*just as an idea*, I was thinking about having two different offload
limits -- for user space processes doing console_unlock() for whatever
reason (printk in syscall or because of console_lock, etc.) and for
KTHREADS. the kernel threads can have normal offload_limit, while user
space processes can return back from syscal sooner (doing only half of
printk worload, for example). but this is probably too `custom', though
sort of make some sense.
(compile tested only)
---
kernel/printk/printk.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 79915da..cff1dd1 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -330,6 +330,7 @@ static struct kernel_param_ops offload_chars_ops = {
* 0.1s maximum latency due to printing.
*/
static unsigned int __read_mostly printk_offload_chars = 1000;
+static unsigned int __read_mostly printk_offload_limits[2] = {500, 1000};
module_param_cb(offload_chars, _chars_ops, _offload_chars,
S_IRUGO | S_IWUSR);
@@ -343,10 +344,14 @@ MODULE_PARM_DESC(offload_chars, "offload printing to
console to a different"
*/
static bool cpu_stop_printing(int printed_chars)
{
+ bool type = current->flags & PF_KTHREAD;
+
/* Oops? Print everything now to maximize chances user will see it */
if (oops_in_progress)
return false;
- if (!printk_offload_chars || printed_chars < printk_offload_chars)
+ if (!printk_offload_chars)
+ return false;
+ if (printed_chars < printk_offload_limits[type])
return false;
/*
* Make sure we load fresh value of printing_tasks_spinning. Matches
@@ -2995,6 +3000,12 @@ out_err:
return ret;
}
+static void offload_limits_set(void)
+{
+ printk_offload_limits[0] = printk_offload_chars >> 1;
+ printk_offload_limits[1] = printk_offload_chars;
+}
+
static int offload_chars_set(const char *val, const struct kernel_param *kp)
{
int ret;
@@ -3006,6 +3017,8 @@ static int offload_chars_set(const char *val, const
struct kernel_param *kp)
mutex_unlock(_kthread_mutex);
return ret;
}
+
+ offload_limits_set();
ret = printk_start_offload_kthreads();
mutex_unlock(_kthread_mutex);
return ret;
@@ -3014,11 +3027,13 @@ static int offload_chars_set(const char *val, const
struct kernel_param *kp)
static void printk_offload_init(void)
{
mutex_lock(_kthread_mutex);
+ offload_limits_set();
if (num_possible_cpus() <= 1) {
/* Offloading doesn't make sense. Disable print offloading. */
printk_offload_chars = 0;
- } else
+ } else {
printk_start_offload_kthreads();
+ }
mutex_unlock(_kthread_mutex);
}
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/9] drm/rockchip: Convert to support atomic API
On 2015年12月02日 22:18, Daniel Stone wrote:
Hi Mark,
Thanks for getting back to this.
On 1 December 2015 at 09:31, Mark yao wrote:
On 2015年12月01日 16:18, Daniel Stone wrote:
On 1 December 2015 at 03:26, Mark Yao wrote:
+ for_each_crtc_in_state(state, crtc, crtc_state, i) {
+ if (!crtc->state->active)
+ continue;
+
+ rockchip_crtc_wait_for_update(crtc);
+ }
I'd be much more comfortable if this passed in an explicit pointer to
state, or an address to wait for, rather than have wait_for_complete
dig out state with no locking. The latter is potentially racy for
async operations.
Hi Daniel
"if this passed in an explicit pointer to state, or an address to wait
for", I don't understand, can you point how it work?
Ah, OK. I mean that rockchip_crtc_wait_for_update takes a drm_crtc
pointer, and establishes the state from that (e.g.
crtc->primary->state). This can easily lead to confusion in async
contexts, as the states attached to a drm_crtc and a drm_plane can
change here while you wait for it.
It would be better if the call was:
for_each_plane_in_state(state, plane, plane_state, i) {
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
rockchip_crtc_wait_for_update(plane_state->crtc, plane_state);
}
This way it is very clear, and there is no confusion as to which
request we are waiting to complete.
In general, using crtc->state or plane->state is a very bad idea,
_except_ in the atomic_check function where you are calculating
changes (e.g. if (plane_state->fb->pitches[0] !=
plane->state->fb->pitches[0]) rockchip_plane_state->pitch_changed =
true). After atomic_check, you should always pass around pointers to
the plane state explicitly, and avoid using the pointers from drm_crtc
and drm_plane.
Does that help?
Hi Daniel
Sorry, I don't actually understand why crtc->state or plane->state is no
recommended
except atomic_check, on atomic_update, we need use plane->state, is that
a problem?
I guess that, drm_atomic_helper_swap_state would race with async operations,
so use crtc->state on async stack is not safe. is it correct?
I think we can make asynchronous commit serialize as tegra drm done to
avoid this problem:
86 /* serialize outstanding asynchronous commits */
87 mutex_lock(>commit.lock);
88 flush_work(>commit.work);
89
90 /*
91 * This is the point of no return - everything below never
fails except
92 * when the hw goes bonghits. Which means we can commit
the new state on
93 * the software side now.
94 */
95
96 drm_atomic_helper_swap_state(drm, state);
97
98 if (async)
99 tegra_atomic_schedule(tegra, state);
100 else
101 tegra_atomic_complete(tegra, state);
102
103 mutex_unlock(>commit.lock);
if (is_yuv) {
/*
* Src.x1 can be odd when do clip, but yuv plane start
point
* need align with 2 pixel.
*/
- val = (src.x1 >> 16) % 2;
- src.x1 += val << 16;
- src.x2 += val << 16;
+ uint32_t temp = (src->x1 >> 16) % 2;
+
+ src->x1 += temp << 16;
+ src->x2 += temp << 16;
}
I know this isn't new, but moving the plane around is bad. If the user
gives you a pixel boundary that you can't actually use, please reject
the configuration rather than silently trying to fix it up.
the origin src.x1 would align with 2 pixel, but when we move the dest
window, and do clip by output, the src.x1 may be clipped to odd.
regect this configuration may let user confuse, sometimes good, sometimes
bad.
For me, it is more confusing when the display shows something
different to what I have requested. In some media usecases, doing this
is a showstopper and will result in products failing acceptance
testing. Userspace can make a policy decision to try different
alignments to get _something_ to show (even if it's not what was
explicitly requested), but doing this in the kernel is inappropriate:
please just reject it, and have userspace fall back to another
composition method (e.g. GL) in these cases.
-static void vop_plane_destroy(struct drm_plane *plane)
+static void vop_atomic_plane_destroy_state(struct drm_plane *plane,
+ struct drm_plane_state *state)
{
- vop_disable_plane(plane);
- drm_plane_cleanup(plane);
+ struct vop_plane_state *vop_state = to_vop_plane_state(state);
+
+ if (state->fb)
+ drm_framebuffer_unreference(state->fb);
+
+ kfree(vop_state);
}
You can replace this hook with drm_atomic_helper_plane_destroy_state.
Hmm, only can hook with __drm_atomic_helper_plane_destroy_state.
Ah yes, you're right. But still, using that would be better than duplicating it.
Can you share your Weston environment to me, I'm interesting to test drm
rockchip on
Re: [PATCH] ARM: dts: Make CPU configuration more readable for exynos542x/5800
On 11.12.2015 15:21, Viresh Kumar wrote: > On 11-12-15, 15:17, Krzysztof Kozlowski wrote: >> Exynos5420 and Exynos5800 boards boot from big core (A15) but >> Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this > > s/Exynos5420/Exynos5422 Damn, one can get confused. Thanks for review! Krzysztof > and then you can add > > Reviewed-by: Viresh Kumar > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: Make CPU configuration more readable for exynos542x/5800
On 11-12-15, 15:17, Krzysztof Kozlowski wrote: > Exynos5420 and Exynos5800 boards boot from big core (A15) but > Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this s/Exynos5420/Exynos5422 and then you can add Reviewed-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: reorganize struct size_class to pack 4 bytes hole
Cc linux-mm and linux-kernel
On (12/11/15 13:20), Weijie Yang wrote:
>
> Reoder the pages_per_zspage field in struct size_class which can eliminate
> the 4 bytes hole between it and stats field.
>
Looks good to me.
Reviewed-by: Sergey Senozhatsky
> Signed-off-by: Weijie Yang
> ---
> mm/zsmalloc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 9f15bdd..e7414ce 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -213,10 +213,10 @@ struct size_class {
> int size;
> unsigned int index;
>
> - /* Number of PAGE_SIZE sized pages to combine to form a 'zspage' */
> - int pages_per_zspage;
> struct zs_size_stat stats;
>
> + /* Number of PAGE_SIZE sized pages to combine to form a 'zspage' */
> + int pages_per_zspage;
> /* huge object: pages_per_zspage == 1 && maxobj_per_zspage == 1 */
> bool huge;
> };
we also can re-order `struct zs_pool' -- `gfp_t flags' and `bool
shrinker_enabled'
will be fine together.
I can send a separate patch of we can fold the one below.
I'm good either way.
---
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 9f15bdd..2a3af25 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -246,19 +246,17 @@ struct zs_pool {
struct size_class **size_class;
struct kmem_cache *handle_cachep;
-
- gfp_t flags;/* allocation flags used when growing pool */
- atomic_long_t pages_allocated;
-
struct zs_pool_stats stats;
-
- /* Compact classes */
- struct shrinker shrinker;
+ atomic_long_t pages_allocated;
+ /* allocation flags used when growing pool */
+ gfp_t flags;
/*
* To signify that register_shrinker() was successful
* and unregister_shrinker() will not Oops.
*/
bool shrinker_enabled;
+ /* Compact classes */
+ struct shrinker shrinker;
#ifdef CONFIG_ZSMALLOC_STAT
struct dentry *stat_dentry;
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: Make CPU configuration more readable for exynos542x/5800
Exynos5420 and Exynos5800 boards boot from big core (A15) but
Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this
is property of the board - configurable by pulling up/down gpg2-1).
To make user-visible CPU ordering more consistent the 'cpus' node was
overridden by exynos5422-cpus.dtsi.
However this is a little bit ugly and error-prone. Overriding the CPU
child nodes requires to basically reverse what was done initially in
exynos5420.dtsi.
Instead, split CPU configuration entirely to separate files which should
be included by board DTS.
Suggested-by: Viresh Kumar
Signed-off-by: Krzysztof Kozlowski
---
Tested on Exynos5422 based Odroid XU4. Please kindly test on Exynos5420
or Exynos5800 boards.
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 1 +
arch/arm/boot/dts/exynos5420-cpus.dtsi| 92 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts| 1 +
arch/arm/boot/dts/exynos5420-smdk5420.dts | 1 +
arch/arm/boot/dts/exynos5420.dtsi | 72 +-
arch/arm/boot/dts/exynos5422-cpus.dtsi| 130 ++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 +
7 files changed, 170 insertions(+), 128 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos5420-cpus.dtsi
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 4ecef6981d5c..365eec6f6687 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5420.dtsi"
+#include "exynos5420-cpus.dtsi"
#include
#include
#include
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi
b/arch/arm/boot/dts/exynos5420-cpus.dtsi
new file mode 100644
index ..7aaf0313274f
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -0,0 +1,92 @@
+/*
+ * SAMSUNG EXYNOS5420 SoC cpu device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This file provides desired ordering for Exynos5420 and Exynos5800
+ * boards: CPU[0123] being the A15.
+ *
+ * The Exynos5420, 5422 and 5800 actually share the same CPU configuration
+ * but particular boards choose different booting order.
+ *
+ * Exynos5420 and Exynos5800 always boot from Cortex-A15. On Exynos5422
+ * booting cluster (big or LITTLE) is chosen by IROM code by reading
+ * the gpg2-1 GPIO. By default all Exynos5422 based boards choose booting
+ * from the LITTLE: Cortex-A7.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/ {
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x0>;
+ clock-frequency = <18>;
+ cci-control-port = <_control1>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x1>;
+ clock-frequency = <18>;
+ cci-control-port = <_control1>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x2>;
+ clock-frequency = <18>;
+ cci-control-port = <_control1>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x3>;
+ clock-frequency = <18>;
+ cci-control-port = <_control1>;
+ };
+
+ cpu4: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x100>;
+ clock-frequency = <10>;
+ cci-control-port = <_control0>;
+ };
+
+ cpu5: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x101>;
+ clock-frequency = <10>;
+ cci-control-port = <_control0>;
+ };
+
+ cpu6: cpu@102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x102>;
+ clock-frequency = <10>;
+ cci-control-port = <_control0>;
+ };
+
+ cpu7: cpu@103 {
+
[PATCH] mm: mempool: Factor out mempool_refill()
This patch factors out mempool_refill() from mempool_resize(). It's reasonable
that the mempool user wants to refill the pool immdiately when it has chance
e.g. inside a sleepible context, so that next time in the IRQ context the pool
would have much more available elements to allocate.
After the refactor, mempool_refill() can also executes with mempool_resize()
/mempool_alloc/mempool_free() or another mempool_refill().
Signed-off-by: Zhi Wang
---
include/linux/mempool.h | 1 +
mm/mempool.c| 61 -
2 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/include/linux/mempool.h b/include/linux/mempool.h
index 69b6951..71f7460 100644
--- a/include/linux/mempool.h
+++ b/include/linux/mempool.h
@@ -30,6 +30,7 @@ extern mempool_t *mempool_create_node(int min_nr,
mempool_alloc_t *alloc_fn,
gfp_t gfp_mask, int nid);
extern int mempool_resize(mempool_t *pool, int new_min_nr);
+extern void mempool_refill(mempool_t *pool);
extern void mempool_destroy(mempool_t *pool);
extern void * mempool_alloc(mempool_t *pool, gfp_t gfp_mask);
extern void mempool_free(void *element, mempool_t *pool);
diff --git a/mm/mempool.c b/mm/mempool.c
index 004d42b..139c477 100644
--- a/mm/mempool.c
+++ b/mm/mempool.c
@@ -223,6 +223,47 @@ mempool_t *mempool_create_node(int min_nr, mempool_alloc_t
*alloc_fn,
EXPORT_SYMBOL(mempool_create_node);
/**
+ * mempool_refill - refill an existing memory pool immediately
+ * @pool: pointer to the memory pool which was allocated via
+ * mempool_create().
+ *
+ * This function tries to refill the pool with new elements
+ * immediately. Similar with mempool_resize(), it cannot be
+ * guaranteed that the pool will be fully filled immediately.
+ *
+ * Note, the caller must guarantee that no mempool_destroy is called
+ * while this function is running. mempool_alloc() & mempool_free()
+ * might be called (eg. from IRQ contexts) while this function executes.
+ */
+void mempool_refill(mempool_t *pool)
+{
+ void *element;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ if (pool->curr_nr >= pool->min_nr) {
+ spin_unlock_irqrestore(>lock, flags);
+ return;
+ }
+
+ while (pool->curr_nr < pool->min_nr) {
+ spin_unlock_irqrestore(>lock, flags);
+ element = pool->alloc(GFP_KERNEL, pool->pool_data);
+ if (!element)
+ return;
+ spin_lock_irqsave(>lock, flags);
+ if (pool->curr_nr < pool->min_nr) {
+ add_element(pool, element);
+ } else {
+ spin_unlock_irqrestore(>lock, flags);
+ pool->free(element, pool->pool_data); /* Raced */
+ return;
+ }
+ }
+}
+EXPORT_SYMBOL(mempool_refill);
+
+/**
* mempool_resize - resize an existing memory pool
* @pool: pointer to the memory pool which was allocated via
* mempool_create().
@@ -256,7 +297,8 @@ int mempool_resize(mempool_t *pool, int new_min_nr)
spin_lock_irqsave(>lock, flags);
}
pool->min_nr = new_min_nr;
- goto out_unlock;
+ spin_unlock_irqrestore(>lock, flags);
+ goto out;
}
spin_unlock_irqrestore(>lock, flags);
@@ -279,22 +321,9 @@ int mempool_resize(mempool_t *pool, int new_min_nr)
pool->elements = new_elements;
pool->min_nr = new_min_nr;
- while (pool->curr_nr < pool->min_nr) {
- spin_unlock_irqrestore(>lock, flags);
- element = pool->alloc(GFP_KERNEL, pool->pool_data);
- if (!element)
- goto out;
- spin_lock_irqsave(>lock, flags);
- if (pool->curr_nr < pool->min_nr) {
- add_element(pool, element);
- } else {
- spin_unlock_irqrestore(>lock, flags);
- pool->free(element, pool->pool_data); /* Raced */
- goto out;
- }
- }
-out_unlock:
spin_unlock_irqrestore(>lock, flags);
+
+ mempool_refill(pool);
out:
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files
On Thu, Dec 10, 2015 at 05:38:23PM -0600, Rob Herring wrote: > Platform dts files need to be reviewed primarily by the platform > maintainers as dts files typically go in thru their trees. Add the missing > paths where there are existing maintainers listed. > > Signed-off-by: Rob Herring > --- > ARM/Marvell Dove/MV78xx0/Orion SOC support > @@ -1406,7 +1415,9 @@ M: David Brown > L: linux-arm-...@vger.kernel.org > L: linux-...@vger.kernel.org > S: Maintained > +F: arch/arm/boot/dts/qcom-* > F: arch/arm/mach-qcom/ > +F: arch/arm64/boot/dts/qcom/* > F: drivers/soc/qcom/ > F: drivers/tty/serial/msm_serial.h > F: drivers/tty/serial/msm_serial.c for QCOM, Acked-by: Andy Gross -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 2/2] arm: dts: Add APQ8084 SMEM nodes
From: Andy Gross
This patch adds all the required nodes to support SMEM on APQ8084
Signed-off-by: Andy Gross
Acked-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index fcffeca..3d3b394 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -10,6 +10,17 @@
compatible = "qcom,apq8084";
interrupt-parent = <>;
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ smem_mem: smem_region@fa0 {
+ reg = <0xfa0 0x20>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -89,6 +100,15 @@
clock-frequency = <1920>;
};
+ smem {
+ compatible = "qcom,smem";
+
+ qcom,rpm-msg-ram = <_msg_ram>;
+ memory-region = <_mem>;
+
+ hwlocks = <_mutex 3>;
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -225,6 +245,22 @@
reg = <0xfc40 0x4000>;
};
+ tcsr_mutex_regs: syscon@fd484000 {
+ compatible = "syscon";
+ reg = <0xfd484000 0x2000>;
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <_mutex_regs 0 0x80>;
+ #hwlock-cells = <1>;
+ };
+
+ rpm_msg_ram: memory@fc428000 {
+ compatible = "qcom,rpm-msg-ram";
+ reg = <0xfc428000 0x4000>;
+ };
+
tlmm: pinctrl@fd51 {
compatible = "qcom,apq8084-pinctrl";
reg = <0xfd51 0x4000>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 1/2] arm64: dts: qcom: Add MSM8916 SMEM nodes
From: Andy Gross
This patch adds the nodes necessary to support the SMEM driver on MSM8916
platforms.
Signed-off-by: Andy Gross
Acked-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 8d184ff..fe4541f 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -37,6 +37,22 @@
reg = <0 0 0 0>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ reserve_aligned@8600 {
+ reg = <0x0 0x8600 0x0 0x030>;
+ no-map;
+ };
+
+ smem_mem: smem_region@8630 {
+ reg = <0x0 0x8630 0x0 0x010>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -74,6 +90,15 @@
;
};
+ smem {
+ compatible = "qcom,smem";
+
+ memory-region = <_mem>;
+ qcom,rpm-msg-ram = <_msg_ram>;
+
+ hwlocks = <_mutex 3>;
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -103,6 +128,22 @@
reg = <0x180 0x8>;
};
+ tcsr_mutex_regs: syscon@1905000 {
+ compatible = "syscon";
+ reg = <0x1905000 0x2>;
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <_mutex_regs 0 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
+ rpm_msg_ram: memory@6 {
+ compatible = "qcom,rpm-msg-ram";
+ reg = <0x6 0x8000>;
+ };
+
blsp1_uart1: serial@78af000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0x78af000 0x200>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 0/2] Add SMEM nodes for APQ8084 and MSM8916
This patch set adds the SMEM nodes for the APQ8084 and MSM8916 platforms. These patches were originally part of: https://lkml.org/lkml/headers/2015/9/24/561 I split these two patches out because these were the only DTS patches that required modifications. The rest have been accepted. I continued to add the previous change log for continuity sake. Changes since v3: - Moved smem node outside of soc and fixed up the rpm-msg-ram Changes since v2: - Fixed some missed review comments - Corrected the SMD RPM example binding indentation Changes since v1: - Fixed various review comments - Removed MSM8974 patches as there was already an outstanding patch Andy Gross (2): arm64: dts: qcom: Add MSM8916 SMEM nodes arm: dts: Add APQ8084 SMEM nodes arch/arm/boot/dts/qcom-apq8084.dtsi | 36 ++ arch/arm64/boot/dts/qcom/msm8916.dtsi | 41 +++ 2 files changed, 77 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 34/60] PCI: Simplify res reference using in __assign_resources_sorted()
There are couples of dev_res->res reference, to make code more readable
use res instead of dev_res->res directly.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 0fc9659..715e627 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -458,6 +458,7 @@ static void __assign_resources_sorted(struct list_head
*head,
struct pci_dev_resource *dev_res, *tmp_res;
unsigned long fail_type;
resource_size_t add_align;
+ struct resource *res;
/* Check if optional add_size is there */
if (!realloc_head || list_empty(realloc_head))
@@ -473,8 +474,8 @@ static void __assign_resources_sorted(struct list_head
*head,
/* Update res in head list with add_size in realloc_head list */
list_for_each_entry(dev_res, head, list) {
- dev_res->res->end += get_res_add_size(realloc_head,
- dev_res->res);
+ res = dev_res->res;
+ res->end += get_res_add_size(realloc_head, res);
/*
* There are two kinds of additional resources in the list:
@@ -483,16 +484,16 @@ static void __assign_resources_sorted(struct list_head
*head,
* 2. resource with IORESOURCE_SIZEALIGN
*update size above already change alignment.
*/
- if (!(dev_res->res->flags & IORESOURCE_STARTALIGN))
+ if (!(res->flags & IORESOURCE_STARTALIGN))
continue;
- add_align = get_res_add_align(realloc_head, dev_res->res);
+ add_align = get_res_add_align(realloc_head, res);
if (add_align) {
- resource_size_t r_size = resource_size(dev_res->res);
+ resource_size_t r_size = resource_size(res);
- dev_res->res->start = add_align;
- dev_res->res->end = add_align + r_size - 1;
+ res->start = add_align;
+ res->end = add_align + r_size - 1;
}
}
@@ -514,21 +515,21 @@ static void __assign_resources_sorted(struct list_head
*head,
/* check failed type */
fail_type = pci_fail_res_type_mask(_fail_head);
/* remove not need to be released assigned res from head list etc */
- list_for_each_entry_safe(dev_res, tmp_res, head, list)
- if (dev_res->res->parent &&
- !pci_need_to_release(fail_type, dev_res->res)) {
+ list_for_each_entry_safe(dev_res, tmp_res, head, list) {
+ res = dev_res->res;
+ if (res->parent && !pci_need_to_release(fail_type, res)) {
/* remove it from realloc_head list */
- remove_from_list(realloc_head, dev_res->res);
- remove_from_list(_head, dev_res->res);
+ remove_from_list(realloc_head, res);
+ remove_from_list(_head, res);
list_del(_res->list);
kfree(dev_res);
}
+ }
free_list(_fail_head);
/* Release assigned resource */
list_for_each_entry(dev_res, head, list) {
- struct resource *res = dev_res->res;
-
+ res = dev_res->res;
if (res->parent) {
dev_printk(KERN_DEBUG, _res->dev->dev,
"BAR %d: released %pR\n",
@@ -539,8 +540,7 @@ static void __assign_resources_sorted(struct list_head
*head,
}
/* Restore start/end/flags from saved list */
list_for_each_entry(save_res, _head, list) {
- struct resource *res = save_res->res;
-
+ res = save_res->res;
res->start = save_res->start;
res->end = save_res->end;
res->flags = save_res->flags;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 56/60] PCI: Add debug print out for min_align and alt_size
Put all print out for all children align/size and result align/size
together.
We can print out device name at same time with min_align/alt_size
calculation.
So we can shut off debug print out from get_res_add_size() and
get_res_add_align().
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 76 -
1 file changed, 56 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 081eb08..901d2f6 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -159,11 +159,6 @@ static resource_size_t get_res_add_size(struct list_head
*head,
if (!dev_res || !dev_res->add_size)
return 0;
- dev_printk(KERN_DEBUG, _res->dev->dev,
- "BAR %d: %pR get_res_add_size add_size %#llx\n",
- (int)(res - _res->dev->resource[0]),
- res, (unsigned long long)dev_res->add_size);
-
return dev_res->add_size;
}
@@ -176,11 +171,6 @@ static resource_size_t get_res_add_align(struct list_head
*head,
if (!dev_res || !dev_res->min_align)
return 0;
- dev_printk(KERN_DEBUG, _res->dev->dev,
- "BAR %d: %pR get_res_add_align min_align %#llx\n",
- (int)(res - _res->dev->resource[0]),
- res, (unsigned long long)dev_res->min_align);
-
return dev_res->min_align;
}
@@ -1271,6 +1261,8 @@ struct align_test_res {
struct resource res;
resource_size_t size;
resource_size_t align;
+ struct device *dev;
+ int idx;
};
static void free_align_test_list(struct list_head *head)
@@ -1284,7 +1276,8 @@ static void free_align_test_list(struct list_head *head)
}
static int add_to_align_test_list(struct list_head *head,
- resource_size_t align, resource_size_t size)
+ resource_size_t align, resource_size_t size,
+ struct device *dev, int idx)
{
struct align_test_res *tmp;
@@ -1294,6 +1287,8 @@ static int add_to_align_test_list(struct list_head *head,
tmp->align = align;
tmp->size = size;
+ tmp->dev = dev;
+ tmp->idx = idx;
list_add_tail(>list, head);
@@ -1359,6 +1354,19 @@ static resource_size_t calculate_mem_align(struct
list_head *head,
resource_size_t min_align, good_align, aligned_size, start;
int count = 0;
+ list_for_each_entry(p, head, list)
+ count++;
+
+ printk(KERN_DEBUG " ===BEGIN===calculate_mem_align\n");
+ if (count) {
+ printk(KERN_DEBUG " align/size:\n");
+ list_for_each_entry(p, head, list)
+ dev_printk(KERN_DEBUG, p->dev,
+ "BAR %d: %08llx/%08llx\n", p->idx,
+ (unsigned long long)p->align,
+ (unsigned long long)p->size);
+ }
+
if (max_align <= align_low) {
good_align = align_low;
goto out;
@@ -1366,9 +1374,6 @@ static resource_size_t calculate_mem_align(struct
list_head *head,
good_align = max_align;
- list_for_each_entry(p, head, list)
- count++;
-
if (count <= 1)
goto out;
@@ -1393,6 +1398,11 @@ static resource_size_t calculate_mem_align(struct
list_head *head,
} while (min_align > align_low);
out:
+ printk(KERN_DEBUG " min_align/aligned_size: %08llx/%08llx\n",
+ (unsigned long long)good_align,
+ (unsigned long long)ALIGN(size, good_align));
+ printk(KERN_DEBUG " ===END===calculate_mem_align==\n");
+
return good_align;
}
@@ -1410,6 +1420,16 @@ static resource_size_t calculate_mem_alt_size(struct
list_head *head,
list_for_each_entry(p, head, list)
count++;
+ printk(KERN_DEBUG " ===BEGIN===calculate_mem_alt_size=\n");
+ if (count) {
+ printk(KERN_DEBUG " align/size:\n");
+ list_for_each_entry(p, head, list)
+ dev_printk(KERN_DEBUG, p->dev,
+ "BAR %d: %08llx/%08llx\n", p->idx,
+ (unsigned long long)p->align,
+ (unsigned long long)p->size);
+ }
+
if (count <= 1)
goto out;
@@ -1434,6 +1454,11 @@ static resource_size_t calculate_mem_alt_size(struct
list_head *head,
}
out:
+ printk(KERN_DEBUG " alt_align/alt_size: %08llx/%08llx\n",
+ (unsigned long long)max_align,
+ (unsigned long long)good_size);
+ printk(KERN_DEBUG " ===END===calculate_mem_alt_size===\n");
+
return good_size;
}
@@ -1516,7 +1541,7 @@ static int
Re: [PATCH] clk: samsung: exynos542x: fix MFC clock hierarchy parent
Hi, 2015-12-08 22:29 GMT+09:00 Marek Szyprowski : > Proper source for MFC block is mout_user_aclk333 (in datasheet named > USER_MUX_ACLK_333), not the output of CLKDIV_ACLK_333 MUX. > > Signed-off-by: Marek Szyprowski > --- > drivers/clk/samsung/clk-exynos5420.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Tomasz Figa Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 46/60] PCI: Don't add too much optional size for hotplug bridge io
Same as patch for MMIO (PCI: Don't add too much optional size for hotplug
bridge MMIO), and this one is for io port.
It will compare required+optional with min_sum_size to get smaller
optional size.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index c8b3ea6..0ece6b6 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1177,7 +1177,6 @@ static resource_size_t window_alignment(struct pci_bus
*bus,
*
* @bus : the bus
* @min_size : the minimum io window that must to be allocated
- * @add_size : additional optional io window
* @realloc_head : track the additional io window on this list
*
* Sizing the IO windows of the PCI-PCI bridge is trivial,
@@ -1186,9 +1185,11 @@ static resource_size_t window_alignment(struct pci_bus
*bus,
* We must be careful with the ISA aliasing though.
*/
static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size,
- resource_size_t add_size, struct list_head *realloc_head)
+struct list_head *realloc_head)
{
struct pci_dev *dev;
+ resource_size_t min_sum_size = 0;
+ resource_size_t sum_add_size;
struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO,
IORESOURCE_IO);
resource_size_t size = 0, size0 = 0, size1 = 0;
@@ -1198,6 +1199,11 @@ static void pbus_size_io(struct pci_bus *bus,
resource_size_t min_size,
if (!b_res)
return;
+ if (realloc_head) {
+ min_sum_size = min_size;
+ min_size = 0;
+ }
+
min_align = window_alignment(bus, IORESOURCE_IO);
list_for_each_entry(dev, >devices, bus_list) {
int i;
@@ -1227,10 +1233,11 @@ static void pbus_size_io(struct pci_bus *bus,
resource_size_t min_size,
size0 = calculate_iosize(size, min_size, size1,
resource_size(b_res), min_align);
- if (children_add_size > add_size)
- add_size = children_add_size;
- size1 = (!realloc_head || (realloc_head && !add_size)) ? size0 :
- calculate_iosize(size, min_size, add_size + size1,
+ sum_add_size = children_add_size + size + size1;
+ if (sum_add_size < min_sum_size)
+ sum_add_size = min_sum_size;
+ size1 = !realloc_head ? size0 :
+ calculate_iosize(size, min_size, sum_add_size - size,
resource_size(b_res), min_align);
if (!size0 && !size1) {
if (b_res->start || b_res->end)
@@ -1758,7 +1765,7 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct
list_head *realloc_head)
{
struct pci_dev *dev;
unsigned long mask, prefmask, type2 = 0, type3 = 0;
- resource_size_t min_mem_size = 0, additional_io_size = 0;
+ resource_size_t min_mem_size = 0, min_io_size = 0;
struct resource *b_res;
int ret;
@@ -1794,13 +1801,12 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct
list_head *realloc_head)
case PCI_CLASS_BRIDGE_PCI:
if (bus->self->is_hotplug_bridge) {
- additional_io_size = pci_hotplug_io_size;
+ min_io_size = pci_hotplug_io_size;
min_mem_size = pci_hotplug_mem_size;
}
/* Fall through */
default:
- pbus_size_io(bus, realloc_head ? 0 : additional_io_size,
-additional_io_size, realloc_head);
+ pbus_size_io(bus, min_io_size, realloc_head);
/*
* If there's a 64-bit prefetchable MMIO window, compute
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 27/60] PCI: Optimize bus align/size calculation for optional during sizing
Current add_align always use max align, that make required+optional
to get allocated more than needed in some cases.
Now we have new calculate_mem_align(), so we could use it for
add_align calculation.
Need to create separated list for required+optional align/size info.
After that we can get smaller add_align/size, and we have more chance
to make required+optional to get allocated sucessfully.
The result for bridge that have Intel 4x10g card installed:
pci :20:03.2: bridge window [mem 0x-0x000f 64bit pref]
to [bus 2a-31] calculate_mem for required
align/size:
0080/0080, 0080/0080, 0080/0080,
0080/0080, 8000/8000, 8000/8000,
8000/8000, 8000/8000
original min_align/min_size: 0040/0240
new min_align/min_size: 0040/0240
pci :20:03.2: bridge window [mem 0x-0x000f 64bit pref]
to [bus 2a-31] calculate_mem for required+optional
align/size:
0080/0080, 0080/0080, 0080/0080,
0080/0080, 0001/0020, 0001/0020,
0001/0020, 0001/0020, 8000/8000,
8000/8000, 8000/8000, 8000/8000,
4000/0008, 4000/0008, 4000/0008,
4000/0008
original code min_align/min_size: 0080/0300
new min_align/min_size: 0010/02b0
so required align/size: 0x40/0x240, and
new required+optional align/size: 0x10/0x2b0, and it is much better
than original required+optional align/size: 0x80/0x300
and even have smaller min_align than required.
-v2: remove not used size1 in calculate_memsize
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81431
Reported-by: TJ
Signed-off-by: Yinghai Lu
drivers/pci/setup-bus.c | 82 +---
1 file changed, 51 insertions(+), 31 deletions(-)
---
drivers/pci/setup-bus.c | 82 ++---
1 file changed, 51 insertions(+), 31 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 6e67608..d8db9e3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -944,7 +944,6 @@ static resource_size_t calculate_iosize(resource_size_t
size,
static resource_size_t calculate_memsize(resource_size_t size,
resource_size_t min_size,
- resource_size_t size1,
resource_size_t old_size,
resource_size_t align)
{
@@ -954,7 +953,7 @@ static resource_size_t calculate_memsize(resource_size_t
size,
old_size = 0;
if (size < old_size)
size = old_size;
- size = ALIGN(size + size1, align);
+ size = ALIGN(size, align);
return size;
}
@@ -1217,26 +1216,23 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
struct list_head *realloc_head)
{
struct pci_dev *dev;
- resource_size_t min_align, align, size, size0, size1;
- resource_size_t max_align = 0;
+ resource_size_t min_align = 0, min_add_align = 0;
+ resource_size_t max_align = 0, max_add_align = 0;
+ resource_size_t size = 0, size0 = 0, size1 = 0, sum_add_size = 0;
struct resource *b_res = find_free_bus_resource(bus,
mask | IORESOURCE_PREFETCH, type);
- resource_size_t children_add_size = 0;
- resource_size_t children_add_align = 0;
- resource_size_t add_align = 0;
LIST_HEAD(align_test_list);
+ LIST_HEAD(align_test_add_list);
if (!b_res)
return -ENOSPC;
- size = 0;
-
list_for_each_entry(dev, >devices, bus_list) {
int i;
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
struct resource *r = >resource[i];
- resource_size_t r_size;
+ resource_size_t r_size, align;
int flags = pci_resource_pref_compatible(dev, r);
if (r->parent || (flags & IORESOURCE_PCI_FIXED) ||
@@ -1244,19 +1240,23 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
(flags & mask) != type2 &&
(flags & mask) != type3))
continue;
+
r_size = resource_size(r);
+ align = pci_resource_alignment(dev, r);
#ifdef CONFIG_PCI_IOV
/* put SRIOV requested res to the optional list */
if (realloc_head && i >= PCI_IOV_RESOURCES &&
i <= PCI_IOV_RESOURCE_END) {
- add_align = max(pci_resource_alignment(dev, r),
add_align);
+ add_to_align_test_list(_test_add_list,
+ align, r_size);
[PATCH v9 43/60] PCI: Add alt_size ressource allocation support
On system with several pcie switches, BIOS allocate very tight resources
to the bridge bar, and it is not aligned to min_align as kernel allocation
code.
For example:
02:03.0---0c:00.0---0d:04.0---18:00.0
18:00.0 need 0x1000, and 0x0001.
BIOS only allocate 0x1010 to 0d:04.0 and above bridges.
Later after using /sys/bus/pci/devices/:0c:00.0/remove to remove 0c:00.0,
rescan with /sys/bus/pci/rescan can not allocate 0x1800 to 0c:00.0.
as current min_align solution will need 0x1800.
Another example:
00:1c.0---02:00.0---03:01.0---04:00.0---05:19.0---06:00.0
06:00.0 need 0x400 and 0x80.
BIOS only allocate 0x480 to 05:19.0 and 04:00.0.
when 05:19.0 get removed via /sys/bus/pci/devices/:05:19.0/remove,
rescan with /sys/bus/pci/rescan will fail.
pci :05:19.0: BAR 14: no space for [mem size 0x0600]
pci :05:19.0: BAR 14: failed to assign [mem size 0x0600]
pci :06:00.0: BAR 2: no space for [mem size 0x0400 64bit]
pci :06:00.0: BAR 2: failed to assign [mem size 0x0400 64bit]
pci :06:00.0: BAR 0: no space for [mem size 0x0080]
pci :06:00.0: BAR 0: failed to assign [mem size 0x0080]
current code try to use align 0x200 and size 0x600, but parent
bridge only have 0x480.
Introduce alt_align/alt_size and store them in realloc list in addition
to addon info, and will try it after min_align/min_size allocation fails.
The alt_align is max_align, and alt_size is aligned size with bridge
minimum window alignment.
On my test setup:
00:1c.7---61:00.0---62:00.0
62:00.0 needs 0x80 and 0x2, and 00:1c.7 only have 9M allocated
for mmio, with this patch we have
pci :61:00.0: bridge window [mem 0x0040-0x00ff] to [bus 62]
add_size 0 add_align 0 alt_size 90 alt_align 80
req_size c0 req_align 40
pci :61:00.0: BAR 14: no space for [mem size 0x00c0]
pci :61:00.0: BAR 14: failed to assign [mem size 0x00c0]
pci :61:00.0: BAR 14: assigned [mem 0xdf00-0xdf8f]
pci :62:00.0: BAR 0: assigned [mem 0xdf00-0xdf7f pref]
pci :62:00.0: BAR 1: assigned [mem 0xdf80-0xdf81]
pci :61:00.0: PCI bridge to [bus 62]
pci :61:00.0: bridge window [io 0x6000-0x6fff]
pci :61:00.0: bridge window [mem 0xdf00-0xdf8f]
pci :00:1c.7: PCI bridge to [bus 61-68]
pci :00:1c.7: bridge window [io 0x6000-0x6fff]
pci :00:1c.7: bridge window [mem 0xdf00-0xdf8f]
So for 61:00.0 first try with 12M fails, and second try with 9M the
alt_size works. Later 62:00.0 get correct resource allocated too.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100451
Reported-by: Yijing Wang
Tested-by: Yijing Wang
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 203 +---
1 file changed, 191 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 1df6345..51c3b3d 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -323,7 +323,7 @@ static void reassign_resources_sorted(struct list_head
*realloc_head,
{
struct resource *res;
struct pci_dev_resource *add_res, *tmp;
- resource_size_t add_size, align;
+ resource_size_t add_size, align, r_size;
int idx;
list_for_each_entry_safe(add_res, tmp, realloc_head, list) {
@@ -339,12 +339,23 @@ static void reassign_resources_sorted(struct list_head
*realloc_head,
idx = res - _res->dev->resource[0];
add_size = add_res->add_size;
align = add_res->min_align;
- if (!resource_size(res)) {
+ if (!add_size || !align) /* alt_size only */
+ goto out;
+
+ r_size = resource_size(res);
+ if (!r_size) {
res->start = align;
res->end = res->start + add_size - 1;
if (pci_assign_resource(add_res->dev, idx))
reset_resource(res);
} else {
+ /* could just assigned with alt, add difference ? */
+ resource_size_t size;
+
+ size = add_res->end - add_res->start + 1;
+ if (r_size < size)
+ add_size += size - r_size;
+
res->flags |= add_res->flags &
(IORESOURCE_STARTALIGN|IORESOURCE_SIZEALIGN);
if (pci_reassign_resource(add_res->dev, idx,
@@ -583,6 +594,104 @@ static bool
__assign_resources_required_optional_sorted(struct list_head *head,
return false;
}
+static bool __has_alt(struct list_head *head,
+ struct list_head *realloc_head)
+{
+ int alt_count = 0;
+ struct pci_dev_resource *dev_res, *alt_res;
+
+ if (!realloc_head)
+ return false;
+
+ /*
[PATCH v9 31/60] PCI: Rename pdev_sort_resources() to pdev_assign_resources_prepare()
pdev_sort_resources() etc was checking devices resources and putting
resources that need to assign to one list in sorted order.
Now we don't do sorting in those functions anymore, so change to
pdev_assign_resources_prepare() instead.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index cba7ccc..194d5da 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -205,8 +205,8 @@ static resource_size_t __pci_resource_alignment(
return r_align;
}
-/* Sort resources by alignment */
-static void pdev_sort_resources(struct pci_dev *dev,
+/* check resources and save to the list */
+static void pdev_assign_resources_prepare(struct pci_dev *dev,
struct list_head *realloc_head,
struct list_head *head)
{
@@ -242,7 +242,7 @@ static void pdev_sort_resources(struct pci_dev *dev,
}
}
-static void __dev_sort_resources(struct pci_dev *dev,
+static void __dev_assign_resources_prepare(struct pci_dev *dev,
struct list_head *realloc_head,
struct list_head *head)
{
@@ -260,7 +260,7 @@ static void __dev_sort_resources(struct pci_dev *dev,
return;
}
- pdev_sort_resources(dev, realloc_head, head);
+ pdev_assign_resources_prepare(dev, realloc_head, head);
}
static inline void reset_resource(struct resource *res)
@@ -566,7 +566,7 @@ static void pdev_assign_resources_sorted(struct pci_dev
*dev,
{
LIST_HEAD(head);
- __dev_sort_resources(dev, add_head, );
+ __dev_assign_resources_prepare(dev, add_head, );
__assign_resources_sorted(, add_head, fail_head);
}
@@ -579,7 +579,7 @@ static void pbus_assign_resources_sorted(const struct
pci_bus *bus,
LIST_HEAD(head);
list_for_each_entry(dev, >devices, bus_list)
- __dev_sort_resources(dev, realloc_head, );
+ __dev_assign_resources_prepare(dev, realloc_head, );
__assign_resources_sorted(, realloc_head, fail_head);
}
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[no subject]
Are you in need of private or business loans for various purposes? if yes,apply now -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 11
Hi all, Changes since 20151210: *crickets* Non-merge commits (relative to Linus' tree): 4775 5512 files changed, 192545 insertions(+), 83027 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (a80c47daa818 Merge tag 'sound-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (6d1a2adef782 ARC: [axs10x] cap ethernet phy to 100 Mbit/sec) Merging arm-current/fixes (f5e985580978 ARM: 8475/1: SWP emulation: Restore original *data when failed) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (dc9c41bd9ece Revert "powerpc/eeh: Don't unfreeze PHB PE after reset") Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (2c302e7e4105 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging net/master (b0a8d1a0b6e5 net: ezchip: fix address space confusion in nps_enet.c) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless unnitialized variable warnings) Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups on boot) Merging mac80211/master (b7bb11000860 rfkill: copy the name into the rfkill struct) Merging sound-current/for-linus (5328e1ea87fb ALSA: hda/ca0132 - quirk for Alienware 17 2015) Merging pci-current/for-linus (5bd242f824e2 Revert "PCI: hisi: Add HiSilicon SoC Hip05 PCIe driver") Merging driver-core.current/driver-core-linus (31ade3b83e18 Linux 4.4-rc3) Merging tty.current/tty-linus (31ade3b83e18 Linux 4.4-rc3) Merging usb.current/usb-linus (73b39bb0a0fe Merge tag 'fixes-for-v4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no DMA controller set) Merging usb-serial-fixes/usb-linus (a0e80fbd56b4 USB: serial: Another Infineon flash loader USB ID) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (9225c0b7b976 staging: lustre: echo_copy.._lsm() dereferences userland pointers directly) Merging char-misc.current/char-misc-linus (e8c77bda05e5 fpga manager: Fix firmware resource leak on error) Merging input-current/for-linus (1cf44efa1e4f Input: arizona-haptic - fix disabling of haptics device) Merging crypto-current/master (70d906bc1750 crypto: skcipher - Copy iv from desc even for 0-len walks) Merging ide/master (1b1050cdc5cd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (ae5515d66362 Revert: "vfio: Include No-IOMMU mode") Merging kselftest-fixes/fixes (2ce47b44b25d selft
[Resend 0/2] Add support for APQ8084 and MSM8916 Regulators
This patch set is a resend of the regulator portion of the patches found at: https://lkml.org/lkml/2015/9/24/561 This adds support for the PMA8084 regulators found on APQ8084 platforms and the PM8916 regulators found on MSM8916 platforms. There are no changes from the version referenced above, this is just a resend. Andy Gross (2): regulator: qcom-smd: Add PM8916 support regulator: qcom-smd: Add support for PMA8084 .../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 53 +++ drivers/regulator/qcom_smd-regulator.c | 159 + 2 files changed, 212 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Resend 1/2] regulator: qcom-smd: Add PM8916 support
From: Andy Gross
This patch adds support and documentation for the PM8916 regulators
found on MSM8916 platforms.
Acked-by: Bjorn Andersson
Signed-off-by: Andy Gross
---
.../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 18 ++
drivers/regulator/qcom_smd-regulator.c | 64 ++
2 files changed, 82 insertions(+)
diff --git
a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
index 7084474..e74ffe1 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
@@ -17,6 +17,7 @@ Regulator nodes are identified by their compatible:
Value type:
Definition: must be one of:
"qcom,rpm-pm8841-regulators"
+ "qcom,rpm-pm8916-regulators"
"qcom,rpm-pm8941-regulators"
- vdd_s1-supply:
@@ -35,6 +36,19 @@ Regulator nodes are identified by their compatible:
- vdd_s1-supply:
- vdd_s2-supply:
- vdd_s3-supply:
+- vdd_s4-supply:
+- vdd_l1_l2_l3-supply:
+- vdd_l4_l5_l6-supply:
+- vdd_l7-supply:
+- vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18-supply:
+ Usage: optional (pm8916 only)
+ Value type:
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
- vdd_l1_l3-supply:
- vdd_l2_lvs1_2_3-supply:
- vdd_l4_l11-supply:
@@ -57,6 +71,10 @@ of the pmics below.
pm8841:
s1, s2, s3, s4, s5, s6, s7, s8
+pm8916:
+ s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
+ l14, l15, l16, l17, l18
+
pm8941:
s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
diff --git a/drivers/regulator/qcom_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
index 6fa0c7d..8464ead 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -211,6 +211,43 @@ static const struct regulator_desc pm8941_switch = {
.ops = _switch_ops,
};
+static const struct regulator_desc pm8916_pldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(75, 0, 208, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 209,
+ .ops = _smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8916_nldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(375000, 0, 93, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 94,
+ .ops = _smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8916_buck_lvo_smps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(375000, 0, 95, 12500),
+ REGULATOR_LINEAR_RANGE(75, 96, 127, 25000),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 128,
+ .ops = _smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8916_buck_hvo_smps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(155, 0, 31, 25000),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 32,
+ .ops = _smps_ldo_ops,
+};
+
struct rpm_regulator_data {
const char *name;
u32 type;
@@ -231,6 +268,32 @@ static const struct rpm_regulator_data
rpm_pm8841_regulators[] = {
{}
};
+static const struct rpm_regulator_data rpm_pm8916_regulators[] = {
+ { "s1", QCOM_SMD_RPM_SMPA, 1, _buck_lvo_smps, "vdd_s1" },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, _buck_lvo_smps, "vdd_s2" },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, _buck_lvo_smps, "vdd_s3" },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, _buck_hvo_smps, "vdd_s4" },
+ { "l1", QCOM_SMD_RPM_LDOA, 1, _nldo, "vdd_l1_l2_l3" },
+ { "l2", QCOM_SMD_RPM_LDOA, 2, _nldo, "vdd_l1_l2_l3" },
+ { "l3", QCOM_SMD_RPM_LDOA, 3, _nldo, "vdd_l1_l2_l3" },
+ { "l4", QCOM_SMD_RPM_LDOA, 4, _pldo, "vdd_l4_l5_l6" },
+ { "l5", QCOM_SMD_RPM_LDOA, 5, _pldo, "vdd_l4_l5_l6" },
+ { "l6", QCOM_SMD_RPM_LDOA, 6, _pldo, "vdd_l4_l5_l6" },
+ { "l7", QCOM_SMD_RPM_LDOA, 7, _pldo, "vdd_l7" },
+ { "l8", QCOM_SMD_RPM_LDOA, 8, _pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18" },
+ { "l9", QCOM_SMD_RPM_LDOA, 9, _pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18" },
+ { "l10", QCOM_SMD_RPM_LDOA, 10, _pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
+ { "l11", QCOM_SMD_RPM_LDOA, 11, _pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
+ { "l12", QCOM_SMD_RPM_LDOA, 12, _pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
+ { "l13", QCOM_SMD_RPM_LDOA, 13, _pldo,
"vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18"},
+ {
[Resend 2/2] regulator: qcom-smd: Add support for PMA8084
From: Andy Gross
This patch adds support and documentation for the PMA8084 regulators
found on APQ8084 platforms.
Signed-off-by: Andy Gross
Acked-by: Bjorn Andersson
---
.../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 35
drivers/regulator/qcom_smd-regulator.c | 95 ++
2 files changed, 130 insertions(+)
diff --git
a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
index e74ffe1..22b3506 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
@@ -19,6 +19,7 @@ Regulator nodes are identified by their compatible:
"qcom,rpm-pm8841-regulators"
"qcom,rpm-pm8916-regulators"
"qcom,rpm-pm8941-regulators"
+ "qcom,rpm-pma8084-regulators"
- vdd_s1-supply:
- vdd_s2-supply:
@@ -64,6 +65,35 @@ Regulator nodes are identified by their compatible:
Definition: reference to regulator supplying the input pin, as
described in the data sheet
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_s4-supply:
+- vdd_s5-supply:
+- vdd_s6-supply:
+- vdd_s7-supply:
+- vdd_s8-supply:
+- vdd_s9-supply:
+- vdd_s10-supply:
+- vdd_s11-supply:
+- vdd_s12-supply:
+- vdd_l1_l11-supply:
+- vdd_l2_l3_l4_l27-supply:
+- vdd_l5_l7-supply:
+- vdd_l6_l12_l14_l15_l26-supply:
+- vdd_l8-supply:
+- vdd_l9_l10_l13_l20_l23_l24-supply:
+- vdd_l16_l25-supply:
+- vdd_l17-supply:
+- vdd_l18-supply:
+- vdd_l19-supply:
+- vdd_l21-supply:
+- vdd_l22-supply:
+ Usage: optional (pma8084 only)
+ Value type:
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
The regulator node houses sub-nodes for each regulator within the device. Each
sub-node is identified using the node's name, with valid values listed for each
of the pmics below.
@@ -80,6 +110,11 @@ pm8941:
l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
lvs3, 5vs1, 5vs2
+pma8084:
+ s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5,
+ l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
+ l21, l22, l23, l24, l25, l26, l27, lvs1, lvs2, lvs3, lvs4, 5vs1
+
The content of each sub-node is defined by the standard binding for regulators
-
see regulator.txt.
diff --git a/drivers/regulator/qcom_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
index 8464ead..56a17ec 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -153,6 +153,49 @@ static const struct regulator_ops rpm_switch_ops = {
.is_enabled = rpm_reg_is_enabled,
};
+static const struct regulator_desc pma8084_hfsmps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(375000, 0, 95, 12500),
+ REGULATOR_LINEAR_RANGE(155, 96, 158, 25000),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 159,
+ .ops = _smps_ldo_ops,
+};
+
+static const struct regulator_desc pma8084_ftsmps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(35, 0, 184, 5000),
+ REGULATOR_LINEAR_RANGE(70, 185, 339, 1),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 340,
+ .ops = _smps_ldo_ops,
+};
+
+static const struct regulator_desc pma8084_pldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(75, 0, 30, 25000),
+ REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 100,
+ .ops = _smps_ldo_ops,
+};
+
+static const struct regulator_desc pma8084_nldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(75, 0, 63, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 64,
+ .ops = _smps_ldo_ops,
+};
+
+static const struct regulator_desc pma8084_switch = {
+ .ops = _switch_ops,
+};
+
static const struct regulator_desc pm8x41_hfsmps = {
.linear_ranges = (struct regulator_linear_range[]) {
REGULATOR_LINEAR_RANGE( 375000, 0, 95, 12500),
@@ -335,10 +378,62 @@ static const struct rpm_regulator_data
rpm_pm8941_regulators[] = {
{}
};
+static const struct rpm_regulator_data rpm_pma8084_regulators[] = {
+ { "s1", QCOM_SMD_RPM_SMPA, 1, _ftsmps, "vdd_s1" },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, _ftsmps, "vdd_s2" },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, _hfsmps, "vdd_s3" },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, _hfsmps, "vdd_s4" },
+ { "s5", QCOM_SMD_RPM_SMPA, 5, _hfsmps, "vdd_s5" },
+ { "s6", QCOM_SMD_RPM_SMPA, 6, _ftsmps, "vdd_s6" },
+ {
[PATCH] Staging:rtl8192u: fixes the following sparse warning:
drivers/staging/rtl8192u/r8192U_core.c:3212:6: warning: symbol
'rtl819x_watchdog_wqcallback' was not declared. Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:3276:6: warning: symbol
'watch_dog_timer_callback' was not declared. Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:3282:5: warning: symbol
'_rtl8192_up' was not declared. Should it be static?
drivers/staging/rtl8192u/r8192U_core.c::5: warning: symbol
'rtl8192_close' was not declared. Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:3406:6: warning: symbol
'rtl8192_restart' was not declared. Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:4618:6: warning: symbol
'rtl8192_irq_rx_tasklet' was not declared. Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:4736:6: warning: symbol
'rtl8192_cancel_deferred_work' was not declared. Should it be static?
Signed-off-by: Jandy Gou
---
drivers/staging/rtl8192u/r8192U_core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index a4795af..1343322 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3209,7 +3209,7 @@ static void rtl819x_update_rxcounts(struct r8192_priv
*priv, u32 *TotalRxBcnNum,
}
-void rtl819x_watchdog_wqcallback(struct work_struct *work)
+static void rtl819x_watchdog_wqcallback(struct work_struct *work)
{
struct delayed_work *dwork = container_of(work, struct delayed_work,
work);
struct r8192_priv *priv = container_of(dwork, struct r8192_priv,
watch_dog_wq);
@@ -3273,13 +3273,13 @@ void rtl819x_watchdog_wqcallback(struct work_struct
*work)
}
-void watch_dog_timer_callback(unsigned long data)
+static void watch_dog_timer_callback(unsigned long data)
{
struct r8192_priv *priv = ieee80211_priv((struct net_device *) data);
queue_delayed_work(priv->priv_wq, >watch_dog_wq, 0);
mod_timer(>watch_dog_timer, jiffies +
MSECS(IEEE80211_WATCH_DOG_TIME));
}
-int _rtl8192_up(struct net_device *dev)
+static int _rtl8192_up(struct net_device *dev)
{
struct r8192_priv *priv = ieee80211_priv(dev);
int init_status = 0;
@@ -3330,7 +3330,7 @@ int rtl8192_up(struct net_device *dev)
}
-int rtl8192_close(struct net_device *dev)
+static int rtl8192_close(struct net_device *dev)
{
struct r8192_priv *priv = ieee80211_priv(dev);
int ret;
@@ -3403,7 +3403,7 @@ void rtl8192_commit(struct net_device *dev)
}
-void rtl8192_restart(struct work_struct *work)
+static void rtl8192_restart(struct work_struct *work)
{
struct r8192_priv *priv = container_of(work, struct r8192_priv,
reset_wq);
struct net_device *dev = priv->ieee80211->dev;
@@ -4615,7 +4615,7 @@ static void rtl8192_rx_cmd(struct sk_buff *skb)
}
}
-void rtl8192_irq_rx_tasklet(struct r8192_priv *priv)
+static void rtl8192_irq_rx_tasklet(struct r8192_priv *priv)
{
struct sk_buff *skb;
struct rtl8192_rx_info *info;
@@ -4733,7 +4733,7 @@ fail:
}
//detach all the work and timer structure declared or inititialize in
r8192U_init function.
-void rtl8192_cancel_deferred_work(struct r8192_priv *priv)
+static void rtl8192_cancel_deferred_work(struct r8192_priv *priv)
{
cancel_work_sync(>reset_wq);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
> Subject: Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL
> PCIe Host Controller
>
> [+cc Marc for irq_dispose_mapping() question]
>
> On Thu, Dec 10, 2015 at 02:10:34PM +, Bharat Kumar Gogada wrote:
> I'm trying to figure out what the difference is between these two checks and
> why you have both of them:
>
> > + if (bus->number == pcie->root_busno && devfn > 0)
> > + if (bus->primary == pcie->root_busno && devfn > 0)
>
> If I understand correctly, pcie->root_busno is the bus number of the Root
> Port device (likely 00). I think the "bus->number ==
> pcie->root_busno && devfn > 0" check means that the Root Port, e.g.,
> 00:00.0, is the only device allowed on bus 00. Often a Root Complex contains
> several Root Ports and other integrated devices that typically are on bus 00.
> But in your case, I think you're saying there is only the single Root Port
> and no
> other devices.
>
> I think that first check takes care of everything on bus 00, so I'm trying to
> figure out what the second check is for. Assume your Root Port is device
> 00:00.0 and it is a bridge to [bus 01-ff]. Then we have two pci_bus structs
> with these values:
>
> bus->number = 00
> bus->primary = 00
> bus->busn_res = [bus 00-ff]
>
> bus->number = 01
> bus->primary = 00
> bus->busn_res = [bus 01-ff]
>
> Because of the first check, 00:00.0 is the only possible device on bus 00, and
> because of the second check, 01:00.0 is the only possible device on bus 01.
> Therefore, you don't support a multifunction device connected to the Root
> Port. Right?
>
We support multifunction devices also, so this check should not be there, will
remove this check in next patch.
> > > > + return false;
> > > > +
> > > > + return true;
> > > > +}
> > > > + * nwl_setup_sspl - Set Slot Power limit
> > > > + *
> > > > + * @pcie: PCIe port information
> > > > + */
> > > > +static int nwl_setup_sspl(struct nwl_pcie *pcie)
> > >
> > The Set_Slot_Power_Limit Message includes a one DW data payload. The
> > data payload is copied from the Slot Capabilities register of the
> > Downstream Port and is written into the Device Capabilities register
> > of the Upstream Port on the other side of the Link. Bits 9:8 of the
> > data payload map to the Slot Power Limit Scale field and bits 7:0 map
> > to the Slot Power Limit Value field. Bits 31:10 of the data payload
> > must be set to all 0's by the Transmitter and ignored by the Receiver.
>
> > This Message is sent automatically by the Downstream Port (of a Root
> > Complex or a Switch) when one of the following events occurs:
> > -> On a Configuration Write to the Slot Capabilities register (see
> > Section 7.8.9) when the Data Link Layer reports DL_Up status.
>
> I interpret this as meaning "the *hardware* automatically sends a
> Set_Slot_Power_Limit Message." There's no mention of software doing
> anything other than the configuration write.
>
> If your hardware doesn't do that, I think it's a defect. It's fine to work
> around
> it, but we should have a comment to that effect so people don't copy the
> code to new drivers that don't need it.
Our hardware is not capable of doing it, so we are doing it software. Yes I
will add some comments.
>
> It's a little strange that 7.8.9 talks about writing to this register when
> all of its
> fields are HwInit and supposedly read-only. I had assumed devices would
> use strapping or implementation-specific registers to set the Slot Power
> values, but maybe some devices use direct writes to Slot Capabilities instead.
>
> BTW, I noticed a related lspci bug: it didn't decode the Capture Slot Power
> Limit in Device Capabilities of Endpoints. I posted a fix for that
> separately.
>
> The Slot Power Limit (in Slot Capabilities) indicates how much power the slot
> can supply to a downstream device. That's a function of the platform design,
> so it seems like this is something you want to set via DT or some other
> mechanism that knows about the platform.
> Intercepting all config writes and updating it with whatever the caller
> supplies
> doesn't sound wise. The value might be coming from setpci or some other
> source with no knowledge of the platform.
Agreed, but this is what can be done, it is difficult to determine who does
what.
>
> > > > + status = nwl_bridge_readl(pcie, TX_PCIE_MSG)
> > > > + & MSG_DONE_BIT;
> > > > + if (status) {
> > > > + status = nwl_bridge_readl(pcie,
> > > TX_PCIE_MSG)
> > > > + & MSG_DONE_STATUS_BIT;
>
> > > It's not clear to me whether you need to re-read TX_PCIE_MSG here.
> >
> > MSG_DONE_BIT qualifies MSG_DONE_STATUS_BIT; so value of
> > MSG_DONE_STATUS_BIT is valid only when MSG_DONE_BIT = 1
>
> That doesn't answer the question of whether another read is required.
> In fact, I would
RE: [PATCH] x86/efi-bgrt: Fix kernel panic when mapping BGRT data
>>On Thu, Dec 10, 2015 at 10:27:01AM -0800, Sai Praneeth Prakhya wrote:
>> From: Sai Praneeth
>>
>> Starting with this commit 35eb8b81edd4 ("x86/efi: Build our own page
>> table structures") efi regions have a separate page directory called
>> "efi_pgd". In order to access any efi region we have to first shift
>>%cr3 to this page table. In the bgrt code we are trying to copy
>> bgrt_header and image, but these regions fall under "EFI_BOOT_SERVICES_DATA"
>> and to access these regions we have to shift %cr3 to efi_pgd and not
>> doing so will cause page fault as shown below.
>>
>> [0.251599] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
>> [0.259126] Freeing SMP alternatives memory: 32K (8230e000 -
>> 82316000)
>> [0.271803] BUG: unable to handle kernel paging request at
>> fffefce35002
>> [0.279740] IP: [] efi_bgrt_init+0x144/0x1fd
>> [0.286383] PGD 300f067 PUD 0
>> [0.289879] Oops: [#1] SMP
>> [0.293566] Modules linked in:
>> [0.297039] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>> 4.4.0-rc1-eywa-eywa-built-in-47041+ #2
>> [0.306619] Hardware name: Intel Corporation Skylake Client
>> platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B01.150114
>> 11/11/2015
>> [0.320925] task: 820134c0 ti: 8200 task.ti:
>> 8200
>> [0.329420] RIP: 0010:[] []
>> efi_bgrt_init+0x144/0x1fd
>> [0.338821] RSP: :82003f18 EFLAGS: 00010246
>> [0.344852] RAX: fffefce35000 RBX: fffefce35000 RCX:
>> fffefce2b000
>> [0.352952] RDX: 8a82b000 RSI: 8235bb80 RDI:
>> 8a835000
>> [0.361050] RBP: 82003f30 R08: 8a865000 R09:
>> ff202850
>> [0.369149] R10: 811ad62f R11: R12:
>>
>> [0.377248] R13: 88016dbaea40 R14: 822622c0 R15:
>> 82003fb0
>> [0.385348] FS: () GS:88016d80()
>> knlGS:
>> [0.394533] CS: 0010 DS: ES: CR0: 80050033
>> [0.401054] CR2: fffefce35002 CR3: 0300c000 CR4:
>> 003406f0
>> [0.409153] DR0: DR1: DR2:
>>
>> [0.417252] DR3: DR6: fffe0ff0 DR7:
>> 0400
>> [0.425350] Stack:
>> [0.427638] 82256900 88016dbaea40
>> 82003f40
>> [0.436086] 821bbce0 82003f88 8219c0c2
>>
>> [0.444533] 8219ba4a 822622c0 00083000
>>
>> [0.452978] Call Trace:
>> [0.455763] [] efi_late_init+0x9/0xb
>> [0.461697] [] start_kernel+0x463/0x47f
>> [0.467928] [] ? set_init_arg+0x55/0x55
>> [0.474159] [] ? early_idt_handler_array+0x120/0x120
>> [0.481669] [] x86_64_start_reservations+0x2a/0x2c
>> [0.488982] [] x86_64_start_kernel+0x13d/0x14c
>> [0.495897] Code: 00 41 b4 01 48 8b 78 28 e8 09 36 01 00 48 85 c0 48 89
>> c3 75 13 48 c7 c7 f8 ac d3 81 31 c0 e8 d7 3b fb fe e9 b5 00 00 00 45 84 e4
>> <44> 8b 6b 02 74 0d be 06 00 00 00 48 89 df e8 ae 34 0$
>> [0.518151] RIP [] efi_bgrt_init+0x144/0x1fd
>> [0.524888] RSP
>> [0.528851] CR2: fffefce35002
>> [0.532615] ---[ end trace 7b06521e6ebf2aea ]---
>> [0.537852] Kernel panic - not syncing: Attempted to kill the idle task!
>>
>> As said above one way to fix this bug is to shift %cr3 to efi_pgd but
>> we are not doing that way because it leaks inner details of how we
>> switch to EFI page tables into a new call site and it also adds duplicate
>> code.
>> Instead, we remove the call to efi_lookup_mapped_addr() and always
>> perform early_mem*() instead of early_io*() because we want to remap
>> RAM regions and not I/O regions.
>>
>> We also delete efi_lookup_mapped_addr() because it is impossible to
>> use it without also doing the page table switch to efi_pgd.
>The original motivation for efi_lookup_mapped_addr came from early_ioremap
>printing a warning if used on an address range >already mapped as RAM. Does
>early_mem* handle that case correctly without a warning?
Thanks a lot Josh for letting me know that. I don't think early_memremap() does
that because early_memremap() and early_ioremap() both use __early_ioremap()
but with different page protections (and I am not sure how those protections
effect warning, but I will check that). Waiting for comments from Matt and
Boris.
>Because not all firmware places the BGRT image in boot services memory; some
>firmware places the BGRT image variously in BIOS >reserved memory, ACPI
>reclaim >space, or other strange places.
>
>- Josh Triplett
I think we should not support buggy firmware implementations because it's same
as encouraging them, instead we could let user know that he has got a buggy
firmware and we skip bgrt code as if bgrt was disabled and carry on
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof
On 11 December 2015 at 09:53, Krzysztof Kozlowski
wrote:
> On 11.12.2015 13:07, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 22 November 2015 at 05:43, Krzysztof Kozlowski
>> wrote:
>>> 2015-11-22 3:14 GMT+09:00 Anand Moon :
Hi Krzysztof,
>
> [...]
>
>>> Yes, now you pasted the same warning I did...
>>>
>>> This is still the same issue. I already wrote it:
1. BUG: sleeping function called from invalid context
2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>
>>> We can repeat it many times but that won't change anything...
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Would you consider below changes to fix the above issue.
>> I have tested this change by enabling CONFIG_DEBUG_ATOMIC_SLEEP
>> And I don't observed issue.
>>
>> 1. BUG: sleeping function called from invalid context
>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>
>> Please share your thought on this changes.
>>
>> root@odroidxu4:/usr/src/odroidxu3-4.y-devel# git diff drivers/pwm/core.c
>> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
>> index d24ca5f..f3f6cf9 100644
>> --- a/drivers/pwm/core.c
>> +++ b/drivers/pwm/core.c
>> @@ -506,6 +506,9 @@ int pwm_enable(struct pwm_device *pwm)
>> if (!pwm)
>> return -EINVAL;
>>
>> + if (!mutex_is_locked(>lock))
>> + return -EINVAL;
>> +
>> mutex_lock(>lock);
>>
>> if (!test_and_set_bit(PWMF_ENABLED, >flags)) {
>
> First of all, Thierry suggested way of fixing this:
> "Any objections to simply removing it and make all users use a workqueue
> or some such if they need to control a PWM as a result of an interrupt
> trigger?"
You are correct, current design need to be changes.
> what is wrong with his approach?
>
pwm->lock is locked but it never get unlocked, although the code looks correct.
> Second, you are writing something that looks like mutex-try-lock...
> which will fail the pwm_enable(). IMHO this *hides* the real issue and
> does not solve anything (except hiding also the warning).
Thanks for the inputs. I have realized my mistake.
>
> Best regards,
> Krzysztof
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option
Dear Xishi, > Hi Taku, > > Whether it is possible that we rewrite the fallback function in buddy system > when zone_movable and mirrored_kernelcore are both enabled? What does "when zone_movable and mirrored_kernelcore are both enabled?" mean ? My patchset just provides a new way to create ZONE_MOVABLE. Sincerely, Taku Izumi > > It seems something like that we add a new zone but the name is zone_movable, > not zone_mirror. And the prerequisite is that we won't enable these two > features(movable memory and mirrored memory) at the same time. Thus we can > reuse the code of movable zone. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region
On Fri, 11 Dec 2015 09:35:10 +0530 Pratyush Anand wrote: > On Wed, Dec 9, 2015 at 3:53 PM, Russell King - ARM Linux wrote: > > [...] > > >> > > dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2); > >> > > + /* > >> > > + * ensure that the ATU enable has been happaned before accessing > >> > > + * pci configuration/io spaces through dw_pcie_cfg_[read|write]. > >> > > + */ > >> > > + wmb(); > >> > > } > >> > > > >> > >> > >> My understnading is that since writel() of dw_pcie_writel_rc() in > >> above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which > >> will follow) goes through same device (ie PCIe host here). So, it is > >> guaranteed that 1st writel() will be executed before later > >> readl()/writel(). If that is true then we do not need any explicit > >> barrier here. > >> > >> Arnd, Russel: whats your opinion here. > > ^l > > Sorry :( > > > > > writel() has a barrier _before_ the access but not after. > > > > The fact is that there's nothing which guarantees that the write will hit > > the hardware in a timely manner (forget any rules about PCI config space, > > the PCI ordering rules apply to the PCI bus, not to the ARM buses.) > > > > If you need this write to have hit the hardware before continuing, you > > need to read back from the same register. > > OK, so better to replace wmb() with read back of control register. > > > > > I'm just looking at this driver, trying to decipher what it's doing. It > > _looks_ to me like it's reprogramming one of the outbound windows (IO?) > > so that configuration space can be accessed. Doesn't this have the > > effect of disabling access to the IO segment of the PCI bus from the > > host CPU? > > > > What protections are there against other CPUs in the system issuing a > > PCI I/O read/write while this outbound window is programmed as > > configuration space? > > > Yes, that is an issue with this driver. Most of the host controller > has 4 or more viewpoints, and it is very easy to handle for them. But > there are few which has only two viewpoints. Do not know how to solve > it, so that it works for all. > The default outbound iATU number is two, this may be the reason why the driver is written in current style. And two outbound iATUs may be common for pcie dw users because ASIC people just follow the default configuration ;). In our case, Marvell Berlin SoCs have two outbound iATUs. Thanks, Jisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files
Rob Herring writes: > Platform dts files need to be reviewed primarily by the platform > maintainers as dts files typically go in thru their trees. Add the missing > paths where there are existing maintainers listed. > > Signed-off-by: Rob Herring > --- > MAINTAINERS | 20 +++- ... > @@ -8627,6 +8642,7 @@ L: linux-arm-ker...@lists.infradead.org (moderated > for non-subscribers) > T: git git://github.com/hzhuang1/linux.git > T: git git://github.com/rjarzmik/linux.git > S: Maintained > +F: arch/arm/boot/dts/pxa* > F: arch/arm/mach-pxa/ > F: drivers/dma/pxa* > F: drivers/pcmcia/pxa2xx* Acked-by: Robert Jarzmik Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc/nvram: Fix an incorrect partition merge
Hi, all I do some tests *without* my fix patch. after reboot, I saw logs below. [0.271236] WARNING: nvram partition checksum was 58, should be 24! [0.271239] Terminating nvram partition scan If I do tests *with* my fix patch, logs are: [0.291419] NVRAM Partitions- [0.291422] indx sig chkslen name [0.291425]0 51 15 512 ibm,CPU0log [0.291428] 8192 51 94 128 ibm,CPU1log [0.291431] 1024070 fc 256 common [0.291434] 14336a0 b5 131 ibm,rtas-log [0.291437] 16432a0 4f 251 lnx,oops-log [0.291440] 204487f 26 2818 HOW TO REPRODUCE this warning?: root@ubuntu:/home/pp/host# ./a.out 0 xinhui 4096 root@ubuntu:/home/pp/host# ./a.out 0 xinhui2 4096 root@ubuntu:/home/pp/host# ./a.out 0 xinhui3 4096 root@ubuntu:/home/pp/host# ./a.out 1 xinhui2 root@ubuntu:/home/pp/host# ./a.out 1 xinhui3 root@ubuntu:/home/pp/host# ./a.out 1 xinhui then logs from dmesg are: [ 844.205337] XINHUI: dev_nvram_ioctl, [xinhui],[0] [ 844.205449] NVRAM Partitions- [ 844.205482] indx sig chkslen name [ 844.205510]0 51 15 512 ibm,CPU0log [ 844.205541] 8192 51 94 128 ibm,CPU1log [ 844.205573] 1024070 fc 256 common [ 844.205604] 14336a0 b5 131 ibm,rtas-log [ 844.205636] 16432a0 4f 251 lnx,oops-log [ 844.205667] 204487f 5e 2818 free space [ 851.636438] XINHUI: dev_nvram_ioctl, [xinhui],[4096] [ 851.636534] NVRAM Partitions- [ 851.636573] indx sig chkslen name [ 851.636614]0 51 15 512 ibm,CPU0log [ 851.636651] 8192 51 94 128 ibm,CPU1log [ 851.636688] 1024070 fc 256 common [ 851.636725] 14336a0 b5 131 ibm,rtas-log [ 851.636762] 16432a0 4f 251 lnx,oops-log [ 851.636798] 20448ef 89 257 xinhui [ 851.636836] 245607f 5c 2561 free space [ 855.354409] XINHUI: dev_nvram_ioctl, [xinhui2],[4096] [ 855.354600] NVRAM Partitions- [ 855.354639] indx sig chkslen name [ 855.354671]0 51 15 512 ibm,CPU0log [ 855.354708] 8192 51 94 128 ibm,CPU1log [ 855.355499] 1024070 fc 256 common [ 855.356186] 14336a0 b5 131 ibm,rtas-log [ 855.356816] 16432a0 4f 251 lnx,oops-log [ 855.357429] 20448ef 89 257 xinhui [ 855.357966] 24560ef bb 257 xinhui2 [ 855.358466] 286727f 5a 2304 free space [ 857.866574] XINHUI: dev_nvram_ioctl, [xinhui3],[4096] [ 857.867449] NVRAM Partitions- [ 857.868250] indx sig chkslen name [ 857.869082]0 51 15 512 ibm,CPU0log [ 857.869901] 8192 51 94 128 ibm,CPU1log [ 857.870727] 1024070 fc 256 common [ 857.871569] 14336a0 b5 131 ibm,rtas-log [ 857.872392] 16432a0 4f 251 lnx,oops-log [ 857.873202] 20448ef 89 257 xinhui [ 857.874019] 24560ef bb 257 xinhui2 [ 857.874811] 28672ef bc 257 xinhui3 [ 857.875568] 327847f 58 2047 free space [ 1015.661796] XINHUI: dev_nvram_ioctl, [xinhui2],[16383] [ 1015.662670] NVRAM Partitions- [ 1015.663457] indx sig chkslen name [ 1015.664150]0 51 15 512 ibm,CPU0log [ 1015.664788] 8192 51 94 128 ibm,CPU1log [ 1015.665396] 1024070 fc 256 common [ 1015.665948] 14336a0 b5 131 ibm,rtas-log [ 1015.666470] 16432a0 4f 251 lnx,oops-log [ 1015.666977] 20448ef 89 257 xinhui [ 1015.667455] 245607f 1b 257 [ 1015.667914] 28672ef bc 257 xinhui3 [ 1015.668359] 327847f 58 2047 free space [ 1017.452055] XINHUI: dev_nvram_ioctl, [xinhui3],[16383] [ 1017.452902] NVRAM Partitions- [ 1017.453731] indx sig chkslen name [ 1017.454531]0 51 15 512 ibm,CPU0log [ 1017.455341] 8192 51 94 128 ibm,CPU1log [ 1017.456121] 1024070 fc 256 common [ 1017.456916] 14336a0 b5 131 ibm,rtas-log [ 1017.457705] 16432
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11-12-15, 14:28, Krzysztof Kozlowski wrote: > Actually I think there is no nice way of making this as separate paths. > As Javier's mentioned, there aren't many differences. Currently the CPU > ordering is the only difference in DT. > > Making it as separate path would create hierarchy like: > - exynos5420-based-board.dts >\- include: exynos5420.dtsi > \- include: exynos5.dtsi >\- include: exynos5420-cpu.dtsi (the cpus are not in exynos5420.dtsi) > > - exynos5422-based-board.dts >\- include: exynos5420.dtsi > \- include: exynos5.dtsi >\- include: exynos5422-cpu.dtsi (the cpus are not in exynos5420.dtsi) > > which of course is okay... except we keep the definition of CPUs > completely outside of main Exynos5420 DTSI. Then we have to include both > DTSI for each new DTS. So what? There isn't anything wrong in this case and is just the right thing to do, IMHO. We have just kept the CPU devices separately, simple. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 RESEND] usb: Use memdup_user to reuse the code
From: Rahul Pathak
Fixing coccicheck warning which recommends to use memdup_user instead
to reimplement its code, using memdup_user simplifies the code
./drivers/usb/core/devio.c:1398:11-18: WARNING opportunity for memdup_user
Signed-off-by: Rahul Pathak
---
Changes after v1: setting isopkt=NULL for proper kfree() call
---
drivers/usb/core/devio.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 38ae877c..844407c 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1395,11 +1395,10 @@ static int proc_do_submiturb(struct usb_dev_state *ps,
struct usbdevfs_urb *uurb
number_of_packets = uurb->number_of_packets;
isofrmlen = sizeof(struct usbdevfs_iso_packet_desc) *
number_of_packets;
- isopkt = kmalloc(isofrmlen, GFP_KERNEL);
- if (!isopkt)
- return -ENOMEM;
- if (copy_from_user(isopkt, iso_frame_desc, isofrmlen)) {
- ret = -EFAULT;
+ isopkt = memdup_user(iso_frame_desc, isofrmlen);
+ if (IS_ERR(isopkt)) {
+ ret = PTR_ERR(isopkt);
+ isopkt = NULL;
goto error;
}
for (totlen = u = 0; u < number_of_packets; u++) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 13/60] PCI: Add has_mem64 for struct host_bridge
Add has_mem64 for struct host_bridge, on root bus that does not support
mmio64 above 4g, will not set that.
We will use that info next two following patches:
1. Don't treat non-pref mmio64 as pref mmio, so will not put
it under bridge's pref range when rescan the devices
2. will keep pref mmio64 and pref mmio32 under bridge pref bar.
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
---
drivers/pci/probe.c | 7 +++
include/linux/pci.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6faabe3..b89daef 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2194,6 +2194,13 @@ struct pci_bus *pci_create_root_bus(struct device
*parent, int bus,
} else
bus_addr[0] = '\0';
dev_info(>dev, "root bus resource %pR%s\n", res, bus_addr);
+
+ if (resource_type(res) == IORESOURCE_MEM) {
+ if ((res->end - offset) > 0x)
+ bridge->has_mem64 = 1;
+ if ((res->start - offset) > 0x)
+ res->flags |= IORESOURCE_MEM_64;
+ }
}
down_write(_bus_sem);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index f96f86a..c135edc 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -413,6 +413,7 @@ struct pci_host_bridge {
void (*release_fn)(struct pci_host_bridge *);
void *release_data;
unsigned int ignore_reset_delay:1; /* for entire hierarchy */
+ unsigned int has_mem64:1;
/* Resource alignment requirements */
resource_size_t (*align_resource)(struct pci_dev *dev,
const struct resource *res,
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 10/60] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource
For device resource PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource, so set IORESOUCE_MEM_64 for 64bit resource during OF device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241 Signed-off-by: Yinghai Lu Cc: Grant Likely Cc: Rob Herring Cc: devicet...@vger.kernel.org Tested-by: Khalid Aziz --- drivers/of/address.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/of/address.c b/drivers/of/address.c index 9582c57..95c39c8 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -128,9 +128,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr) flags |= IORESOURCE_IO; break; case 0x02: /* 32 bits */ - case 0x03: /* 64 bits */ flags |= IORESOURCE_MEM; break; + case 0x03: /* 64 bits */ + flags |= IORESOURCE_MEM | IORESOURCE_MEM_64; + break; } if (w & 0x4000) flags |= IORESOURCE_PREFETCH; -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 25/60] PCI: Use correct align for optional only resources during sorting
During sorting before assign, we only put resource with non-zero align
in the sorted list, so for optional resources that required size is 0 and
only have optional parts, we need to have correct align.
While treating SRIOV as optional resources, we always read alignment for
SRIOV bars every time, so they are ok.
Hotplug bridge resources are using STARTALIGN so it is ok when size is 0
if we have correct start for them.
Later we want to treat the ROM BAR as optional resource, and it has
SIZEALIGN, so align=size will be 0. We need to find a way to get align
for them.
We can use optional resource align instead in that case, and it
is ok for SRIOV path and hotplug bridge resource path.
We need to pass realloc list from sizing stage to sorting stage, and
get entry from realloc list and calculate align from the entry.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81431
Reported-by: TJ
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 49 ++---
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 6f6cf25..31334a1 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -145,9 +145,42 @@ static resource_size_t get_res_add_align(struct list_head
*head,
return dev_res->min_align;
}
+static resource_size_t __pci_resource_alignment(
+ struct pci_dev *dev,
+ struct resource *r,
+ struct list_head *realloc_head)
+{
+ resource_size_t r_align = pci_resource_alignment(dev, r);
+ resource_size_t orig_start, orig_end;
+ struct pci_dev_resource *dev_res;
+
+ if (r_align || !realloc_head)
+ return r_align;
+
+ dev_res = res_to_dev_res(realloc_head, r);
+ if (!dev_res || !dev_res->add_size)
+ return r_align;
+
+ orig_start = r->start;
+ orig_end = r->end;
+ r->end += dev_res->add_size;
+ if ((r->flags & IORESOURCE_STARTALIGN)) {
+ resource_size_t r_size = resource_size(r);
+
+ r->start = dev_res->min_align;
+ r->end = r->start + r_size - 1;
+ }
+ r_align = pci_resource_alignment(dev, r);
+ r->start = orig_start;
+ r->end = orig_end;
+
+ return r_align;
+}
/* Sort resources by alignment */
-static void pdev_sort_resources(struct pci_dev *dev, struct list_head *head)
+static void pdev_sort_resources(struct pci_dev *dev,
+struct list_head *realloc_head,
+struct list_head *head)
{
int i;
@@ -165,7 +198,7 @@ static void pdev_sort_resources(struct pci_dev *dev, struct
list_head *head)
if (!(r->flags) || r->parent)
continue;
- r_align = pci_resource_alignment(dev, r);
+ r_align = __pci_resource_alignment(dev, r, realloc_head);
if (!r_align) {
dev_warn(>dev, "BAR %d: %pR has bogus alignment\n",
i, r);
@@ -183,8 +216,9 @@ static void pdev_sort_resources(struct pci_dev *dev, struct
list_head *head)
list_for_each_entry(dev_res, head, list) {
resource_size_t align;
- align = pci_resource_alignment(dev_res->dev,
-dev_res->res);
+ align = __pci_resource_alignment(dev_res->dev,
+dev_res->res,
+realloc_head);
if (r_align > align) {
n = _res->list;
@@ -197,6 +231,7 @@ static void pdev_sort_resources(struct pci_dev *dev, struct
list_head *head)
}
static void __dev_sort_resources(struct pci_dev *dev,
+struct list_head *realloc_head,
struct list_head *head)
{
u16 class = dev->class >> 8;
@@ -213,7 +248,7 @@ static void __dev_sort_resources(struct pci_dev *dev,
return;
}
- pdev_sort_resources(dev, head);
+ pdev_sort_resources(dev, realloc_head, head);
}
static inline void reset_resource(struct resource *res)
@@ -507,7 +542,7 @@ static void pdev_assign_resources_sorted(struct pci_dev
*dev,
{
LIST_HEAD(head);
- __dev_sort_resources(dev, );
+ __dev_sort_resources(dev, add_head, );
__assign_resources_sorted(, add_head, fail_head);
}
@@ -520,7 +555,7 @@ static void pbus_assign_resources_sorted(const struct
pci_bus *bus,
LIST_HEAD(head);
list_for_each_entry(dev, >devices, bus_list)
- __dev_sort_resources(dev, );
+ __dev_sort_resources(dev, realloc_head, );
__assign_resources_sorted(, realloc_head, fail_head);
}
--
[PATCH v9 36/60] PCI: Cache window alignment value during bus sizing
There are several calling to window_alignment(), and we will have more
for alt_size support, cache the value instead of keeping on getting it.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 936564f..e5b3d8c 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1241,6 +1241,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
mask | IORESOURCE_PREFETCH, type);
LIST_HEAD(align_test_list);
LIST_HEAD(align_test_add_list);
+ resource_size_t window_align;
if (!b_res)
return -ENOSPC;
@@ -1250,6 +1251,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
min_size = 0;
}
+ window_align = window_alignment(bus, b_res->flags);
+
list_for_each_entry(dev, >devices, bus_list) {
int i;
@@ -1312,10 +1315,10 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
}
}
- max_align = max(max_align, window_alignment(bus, b_res->flags));
+ max_align = max(max_align, window_align);
if (size || min_size) {
min_align = calculate_mem_align(_test_list, max_align,
-size, window_alignment(bus, b_res->flags));
+ size, window_align);
size0 = calculate_memsize(size, min_size,
resource_size(b_res), min_align);
}
@@ -1326,7 +1329,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
if (sum_add_size > size && realloc_head) {
min_add_align = calculate_mem_align(_test_add_list,
max_add_align, sum_add_size,
- window_alignment(bus, b_res->flags));
+ window_align);
size1 = calculate_memsize(sum_add_size, min_size,
resource_size(b_res), min_add_align);
}
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 20/60] PCI: Treat optional as required in first try for bridge rescan
For rescan bridge/bus that children are removed before, we should treat
optional as required just like root bus the boot time in 19aa7ee432ce
(PCI: make re-allocation try harder by reassigning ranges higher in
the heirarchy).
The reason: allocate required and expand to optional path do not
put failed resource to fail list, so will lose required info before
next try.
So we are using following way:
1. First and following try before last try:
We don't keep realloc list so treat every optional as required.
allocate for required+optional and put failed in the fail list.
then size info (include must and optonal separatedly) will be kept
for next try.
2. last try:
a: try to allocate required+optional to see if all get allocated.
b: try to allocate required then expand to optional.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index fcc6d62..e4972f5 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1846,25 +1846,34 @@ void __init pci_assign_unassigned_resources(void)
void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
{
struct pci_bus *parent = bridge->subordinate;
- LIST_HEAD(add_list); /* list of resources that
+ LIST_HEAD(realloc_head); /* list of resources that
want additional resources */
+ struct list_head *add_list = NULL;
int tried_times = 0;
LIST_HEAD(fail_head);
struct pci_dev_resource *fail_res;
int retval;
unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
+ int pci_try_num = 2;
again:
- __pci_bus_size_bridges(parent, _list);
- __pci_bridge_assign_resources(bridge, _list, _head);
- pci_bus_check_realloc(_list);
+ /*
+* last try will use add_list, otherwise will try good to have as
+* must have, so can realloc parent bridge resource
+*/
+ if (tried_times + 1 == pci_try_num)
+ add_list = _head;
+ __pci_bus_size_bridges(parent, add_list);
+ __pci_bridge_assign_resources(bridge, add_list, _head);
+ if (add_list)
+ pci_bus_check_realloc(add_list);
tried_times++;
if (list_empty(_head))
goto enable_all;
- if (tried_times >= 2) {
+ if (tried_times >= pci_try_num) {
/* still fail, don't need to try more */
free_list(_head);
goto enable_all;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 33/60] PCI: Add debug printout during releasing partial assigned resources
We try to assign required+optional at first, and we only accept the result
if all resources get allocated. Otherwise will release assigned in the
list, and try to assign required and expand to optional.
We have to do that to make sure any required has priority over any optional.
When that happens, we only print out "assigned" info, that is confusing
as it looks like same range is assigned to two peer resources at the same
time.
Add printout for releasing so we have whole picture in debug messages.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index e9e67bc..0fc9659 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -526,9 +526,17 @@ static void __assign_resources_sorted(struct list_head
*head,
free_list(_fail_head);
/* Release assigned resource */
- list_for_each_entry(dev_res, head, list)
- if (dev_res->res->parent)
- release_resource(dev_res->res);
+ list_for_each_entry(dev_res, head, list) {
+ struct resource *res = dev_res->res;
+
+ if (res->parent) {
+ dev_printk(KERN_DEBUG, _res->dev->dev,
+ "BAR %d: released %pR\n",
+ (int)(res - _res->dev->resource[0]),
+ res);
+ release_resource(res);
+ }
+ }
/* Restore start/end/flags from saved list */
list_for_each_entry(save_res, _head, list) {
struct resource *res = save_res->res;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11.12.2015 13:53, Javier Martinez Canillas wrote:
> Hello Viresh,
>
> On 12/11/2015 01:38 AM, Viresh Kumar wrote:
>> On 11-12-15, 13:18, Krzysztof Kozlowski wrote:
>>> We had such configuration before (before df09df6f9ac3). I don't see any
>>> benefit in what you described. Where is the "thing" to be fixed? It is
>>> mixed up. The contiguous ordering is easier to read and more natural.
>>
>> This is what you are doing today (keeping on one CPU per cluster to
>> simplify it):
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> compatible = "arm,cortex-a15";
>> reg = <0x0>;
>> clock-frequency = <18>;
>> cci-control-port = <_control1>;
>> };
>>
>> cpu4: cpu@100 {
>> device_type = "cpu";
>> compatible = "arm,cortex-a7";
>> reg = <0x100>;
>> clock-frequency = <10>;
>> cci-control-port = <_control0>;
>> };
>>
>>
>> Then you overwrite it with:
>>
>> {
>> device_type = "cpu";
>> compatible = "arm,cortex-a7";
>> reg = <0x100>;
>> clock-frequency = <10>;
>> cci-control-port = <_control0>;
>> };
>>
>> {
>> device_type = "cpu";
>> compatible = "arm,cortex-a15";
>> reg = <0x0>;
>> clock-frequency = <18>;
>> cci-control-port = <_control1>;
>> };
>>
>>
>> Don't you think this isn't the right way of solving problems?
>>
>> The DT overwrite feature isn't there to do such kind of stuff, though
>> it doesn't stop you from doing that.
>>
>
> I still fail to understand why the override is not a good way to solve
> the issue.
>
>> Either you should keep separate paths for both the SoCs, or can solve
>
> There's no point IMHO to duplicate the HW description since is the only
> difference between the Exynos5422 and Exynos5800 SoCs AFAIK.
Actually I think there is no nice way of making this as separate paths.
As Javier's mentioned, there aren't many differences. Currently the CPU
ordering is the only difference in DT.
Making it as separate path would create hierarchy like:
- exynos5420-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5.dtsi
\- include: exynos5420-cpu.dtsi (the cpus are not in exynos5420.dtsi)
- exynos5422-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5.dtsi
\- include: exynos5422-cpu.dtsi (the cpus are not in exynos5420.dtsi)
which of course is okay... except we keep the definition of CPUs
completely outside of main Exynos5420 DTSI. Then we have to include both
DTSI for each new DTS.
Other idea is to create artificial "exynos5420-common":
- exynos5420-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5420-common.dtsi
\- include: exynos5.dtsi
\- include: exynos5420-cpu.dtsi
- exynos5422-based-board.dts
\- include: exynos5422.dtsi
\- include: exynos5420-common.dtsi
\- include: exynos5.dtsi
\- include: exynos5422-cpu.dtsi
This is also confusing...
Any third idea?
Best regards,
KRzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 04/20] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk
This patch adds the DMC (Dynamic Memory Controller) bus frequency node
which includes the devfreq-events and regulator properties. The bus
frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
with ondemand governor.
The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
the DMC block.
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250-monk.dts | 6 ++
arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 443a35085846..456844a81189 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -156,6 +156,12 @@
};
};
+_dmc {
+ devfreq-events = <_dmc0_3>, <_dmc1_3>;
+ vdd-supply = <_reg>;
+ status = "okay";
+};
+
{
cpu0-supply = <_reg>;
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 3e64d5dcdd60..d6bb990ce931 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -147,6 +147,12 @@
};
};
+_dmc {
+ devfreq-events = <_dmc0_3>, <_dmc1_3>;
+ vdd-supply = <_reg>;
+ status = "okay";
+};
+
{
cpu0-supply = <_reg>;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor
This patch-set includes the two features as following. The generic exynos bus
frequency driver is able to support almost Exynos SoCs for bus frequency
scaling. And the new passive governor is able to make the dependency on
between devices for frequency/voltage scaling. I had posted the patch-set[2]
with the similiar concept. This is is revised version for exynos bus frequency.
- Generic exynos bus frequency driver
- New passive governor of DEVFREQ framework
Depend on:
- next-20151210 tag of linux-next (master branch).
- Merge the latest devfreq patches on devfreq.git[2] (for-rafael branch).
[1] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
for-rafael)
[2] https://lkml.org/lkml/2015/1/7/872
: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
Changes from v2:
(https://lkml.org/lkml/2015/12/8/869)
- Fix typo on documentation
- Modify the more appropriate sentence on patch description
- Add the detailed description about both parent and passive bus device
- Modify the DMC frequency for Exynos4x12 DMC bus (200MHz -> 267MHz)
- Modify the voltage of 200MHz was included in Exynos3250 DMC bus (800mV ->
825mV)
- Rename OPP nodes as 'opp@'
- Delete the duplicate 'opp-microvolt' property of passive devfreq device
- Reorder the 'bus_xxx' device tree node alphabetically in
exynos3250-rinato/monk.dts
- Reorder the 'bus_xxx' device tree node alphabetically in
exynos4412-trats/odroidu3
- Add new exynos4412-ppmu-common.dtsi to remove the duplicate PPMU dt node
on rinato/monk/trats2/odroid-u3 board
- Add the log message if bus device is registered to devfreq framework
successfully
- Add the reviewed-by tag from Krzysztof Kozlowski
- Add the tested-by tag from Anand Moon on Odroid U3
- Add 'SAMSUNG BUS FREQUENCY DRIVER' entry to MAINTAINERS
Changes from v1:
(https://lkml.org/lkml/2015/11/26/260)
- Check whether the instance of regulator is NULL or not
when executing regulator_disable() because of only parent
devfreq device has the regulator instance. After fixing it,
the wake-up from suspend state is well working. (patch1)
- Fix bug which checks 'bus-clk' instead of 'bus->regulator'
after calling devm_clk_get() (on patch1)
- Update the documentation to remove the description about
DEVFREQ-EVENT subsystem (on patch2)
- Add the full name of DMC (Dynamic Memory Controller) (on patch2)
- Modify the detailed correlation of buses for Exynos3250
on documentation (patch2)
- Add the MFC bus node for Exynos3250 (on patch11, patch12)
- Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
- Add the PPMU node for exynos4412-odroidu3
- Add the support of bus frequency for exynos4412-odroidu3
Detailed descirption for patch-set:
1. Add generic exynos bus frequency driver
: This patch-set adds the generic exynos bus frequency driver for AXI bus
of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
architecture for bus between DRAM and sub-blocks in SoC.
There are the different buses according to Exynos SoC because Exynos SoC
has the differnt sub-blocks and bus speed. In spite of this difference
among Exynos SoCs, this driver is able to support almost Exynos SoC by adding
unique data of each bus in the devicetree file.
In devicetree, each bus node has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.
For example,
- The bus of DMC block in exynos3250.dtsi are listed below:
bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
clocks = <_dmc CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <_dmc_opp_table>;
status = "disabled";
};
bus_dmc_opp_table: opp_table1 {
compatible = "operating-points-v2";
opp-shared;
opp@5000 {
opp-hz = /bits/ 64 <5000>;
opp-microvolt = <80>;
};
opp@1 {
opp-hz = /bits/ 64 <1>;
opp-microvolt = <80>;
};
opp@13400 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};
opp@2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <825000>;
};
opp@4 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <875000>;
};
};
- Usage case to handle the frequency and voltage of bus on runtime
in exynos3250-rinato.dts are listed below:
_dmc {
devfreq-events = <_dmc0_3>, <_dmc1_3>;
vdd-supply = &l
[PATCH v9 04/60] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
For device resource PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource, so set IORESOUCE_MEM_64 for 64bit resource during of device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241 Signed-off-by: Yinghai Lu Cc: "David S. Miller" Cc: sparcli...@vger.kernel.org Tested-by: Khalid Aziz --- arch/sparc/kernel/of_device_32.c | 5 +++-- arch/sparc/kernel/of_device_64.c | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/sparc/kernel/of_device_32.c b/arch/sparc/kernel/of_device_32.c index 185aa96..3e9f273 100644 --- a/arch/sparc/kernel/of_device_32.c +++ b/arch/sparc/kernel/of_device_32.c @@ -83,11 +83,12 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags) case 0x01: flags |= IORESOURCE_IO; break; - case 0x02: /* 32 bits */ - case 0x03: /* 64 bits */ flags |= IORESOURCE_MEM; break; + case 0x03: /* 64 bits */ + flags |= IORESOURCE_MEM | IORESOURCE_MEM_64; + break; } if (w & 0x4000) flags |= IORESOURCE_PREFETCH; diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c index 7bbdc26..defee61 100644 --- a/arch/sparc/kernel/of_device_64.c +++ b/arch/sparc/kernel/of_device_64.c @@ -146,11 +146,12 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags) case 0x01: flags |= IORESOURCE_IO; break; - case 0x02: /* 32 bits */ - case 0x03: /* 64 bits */ flags |= IORESOURCE_MEM; break; + case 0x03: /* 64 bits */ + flags |= IORESOURCE_MEM | IORESOURCE_MEM_64; + break; } if (w & 0x4000) flags |= IORESOURCE_PREFETCH; -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 06/20] PM / devfreq: Add devfreq_get_devfreq_by_phandle()
This patch adds the new devfreq_get_devfreq_by_phandle() OF helper function
which can find the instance of devfreq device by using phandle ("devfreq").
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
drivers/devfreq/devfreq.c | 44
include/linux/devfreq.h | 9 +
2 files changed, 53 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 15e58779e4c0..78ea4cdaa82c 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "governor.h"
static struct class *devfreq_class;
@@ -686,6 +687,49 @@ struct devfreq *devm_devfreq_add_device(struct device *dev,
}
EXPORT_SYMBOL(devm_devfreq_add_device);
+#ifdef CONFIG_OF
+/*
+ * devfreq_get_devfreq_by_phandle - Get the devfreq device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of devfreq
+ *
+ * return the instance of devfreq device
+ */
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct devfreq *devfreq;
+
+ if (!dev)
+ return ERR_PTR(-EINVAL);
+
+ if (!dev->of_node)
+ return ERR_PTR(-EINVAL);
+
+ node = of_parse_phandle(dev->of_node, "devfreq", index);
+ if (!node)
+ return ERR_PTR(-ENODEV);
+
+ mutex_lock(_list_lock);
+ list_for_each_entry(devfreq, _list, node) {
+ if (devfreq->dev.parent
+ && devfreq->dev.parent->of_node == node) {
+ mutex_unlock(_list_lock);
+ return devfreq;
+ }
+ }
+ mutex_unlock(_list_lock);
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+#else
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif /* CONFIG_OF */
+EXPORT_SYMBOL_GPL(devfreq_get_devfreq_by_phandle);
+
/**
* devm_devfreq_remove_device() - Resource-managed devfreq_remove_device()
* @dev: the device to add devfreq feature.
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 95c54578a1b4..cf972befca2b 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -211,6 +211,9 @@ extern int devm_devfreq_register_opp_notifier(struct device
*dev,
extern void devm_devfreq_unregister_opp_notifier(struct device *dev,
struct devfreq *devfreq);
+extern struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev,
+ int index);
+
/**
* devfreq_update_stats() - update the last_status pointer in struct devfreq
* @df:the devfreq instance whose status needs updating
@@ -322,6 +325,12 @@ static inline void
devm_devfreq_unregister_opp_notifier(struct device *dev,
{
}
+static inline struct devfreq *devfreq_get_devfreq_by_phandle(struct device
*dev,
+ int index)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline int devfreq_update_stats(struct devfreq *df)
{
return -EINVAL;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/20] PM / devfreq: Add new passive governor
This patch adds the new passive governor for DEVFREQ framework. The following
governors are already present and used for DVFS (Dynamic Voltage and Frequency
Scaling) drivers. The following governors are independently used for one device
driver which don't give the influence to other device drviers and also don't
receive the effect from other device drivers.
- ondemand / performance / powersave / userspace
The passive governor depends on operation of parent driver with specific
governos extremely and is not able to decide the new frequency by oneself.
According to the decided new frequency of parent driver with governor,
the passive governor uses it to decide the appropriate frequency for own
device driver. The passive governor must need the following information
from device tree:
- the source clock and OPP tables
- the instance of parent device
For exameple,
there are one more devfreq device drivers which need to change their source
clock according to their utilization on runtime. But, they share the same
power line (e.g., regulator). So, specific device driver is operated as parent
with ondemand governor and then the rest device driver with passive governor
is influenced by parent device.
Suggested-by: Myungjoo Ham
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
drivers/devfreq/Kconfig| 9
drivers/devfreq/Makefile | 1 +
drivers/devfreq/devfreq.c | 47
drivers/devfreq/governor_passive.c | 108 +
include/linux/devfreq.h| 15 ++
5 files changed, 180 insertions(+)
create mode 100644 drivers/devfreq/governor_passive.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 55ec774f794c..d03f635a93e1 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -64,6 +64,15 @@ config DEVFREQ_GOV_USERSPACE
Otherwise, the governor does not change the frequnecy
given at the initialization.
+config DEVFREQ_GOV_PASSIVE
+ tristate "Passive"
+ help
+ Sets the frequency by other governors (simple_ondemand, performance,
+ powersave, usersapce) of a parent devfreq device. This governor
+ always has the dependency on the chosen frequency from paired
+ governor. This governor does not change the frequency by oneself
+ through sysfs entry.
+
comment "DEVFREQ Drivers"
config ARM_EXYNOS_BUS_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 375ebbb4fcfb..f81c313b4b79 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND) +=
governor_simpleondemand.o
obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE) += governor_performance.o
obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)+= governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
+obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
# DEVFREQ Drivers
obj-$(CONFIG_ARCH_EXYNOS) += exynos/
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 984c5e9e7bdd..15e58779e4c0 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -190,6 +190,31 @@ static struct devfreq_governor
*find_devfreq_governor(const char *name)
/* Load monitoring helper functions for governors use */
+static int update_devfreq_passive(struct devfreq *devfreq, unsigned long freq)
+{
+ struct devfreq *passive;
+ unsigned long rate;
+ int ret;
+
+ list_for_each_entry(passive, >passive_dev_list, passive_node) {
+ if (!passive->governor)
+ continue;
+ rate = freq;
+
+ ret = passive->governor->get_target_freq(passive, );
+ if (ret)
+ return ret;
+
+ ret = passive->profile->target(passive->dev.parent, , 0);
+ if (ret)
+ return ret;
+
+ passive->previous_freq = rate;
+ }
+
+ return 0;
+}
+
/**
* update_devfreq() - Reevaluate the device and configure frequency.
* @devfreq: the devfreq instance.
@@ -233,10 +258,18 @@ int update_devfreq(struct devfreq *devfreq)
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
}
+ if (!list_empty(>passive_dev_list)
+ && devfreq->previous_freq > freq)
+ update_devfreq_passive(devfreq, freq);
+
err = devfreq->profile->target(devfreq->dev.parent, , flags);
if (err)
return err;
+ if (!list_empty(>passive_dev_list)
+ && devfreq->previous_freq < freq)
+ update_devfreq_passive(devfreq, freq);
+
if (devfreq->profile->freq_table)
if (devfreq_update_status(devfreq, freq))
dev_err(>dev,
@@ -442,6 +475,10 @@ static void _remove_devfreq(struct devfreq *devfreq)
Re: new warning on sysrq kernel crash trigger
On Thu, Dec 10, 2015 at 03:57:09PM -0800, Ani Sinha wrote:
> Hi guys
>
> I am noticing a new warning in linux 3.18 which we did not see before
> in linux 3.4 :
>
> bash-4.1# echo c > /proc/sysrq-trigger
> [ 978.807185] BUG: sleeping function called from invalid context at
> ../arch/x86/mm/fault.c:1187
> [ 978.909816] in_atomic(): 0, irqs_disabled(): 0, pid: 4706, name: bash
> [ 978.987358] Preemption disabled at:[] printk+0x48/0x4a
>
>
> I have bisected this to the following change :
>
> commit 984d74a72076a12b400339973e8c98fd2fcd90e5
> Author: Rik van Riel
> Date: Fri Jun 6 14:38:13 2014 -0700
>
> sysrq: rcu-ify __handle_sysrq
>
>
> the rcu_read_lock() in handle_sysrq() bumps up
> current->rcu_read_lock_nesting. Hence, in __do_page_fault() when it
> calls might_sleep() in x86/mm/fault.c line 1191,
> preempt_count_equals(0) returns false and hence the warning is
> printed.
>
> One way to handle this would be to do something like this:
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index eef44d9..d4dbe22 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1132,7 +1132,7 @@ __do_page_fault(struct pt_regs *regs, unsigned
> long error_code,
> * If we're in an interrupt, have no user context or are running
> * in a region with pagefaults disabled then we must not take the fault
> */
> - if (unlikely(faulthandler_disabled() || !mm)) {
> + if (unlikely(faulthandler_disabled() || rcu_preempt_depth() || !mm)) {
This works if CONFIG_PREEMPT=y, but if CONFIG_PREEMPT=n, then
rcu_preempt_depth() unconditionally returns zero. And if
CONFIG_PREEMPT_COUNT=y && CONFIG_PREEMPT=n, you would still see
the might_sleep() splat.
Maybe use SRCU instead of RCU for this purpose?
Thanx, Paul
> bad_area_nosemaphore(regs, error_code, address);
> return;
> }
>
> I am wondering if this would be the right approach. I have tested that
> this patch does indeed suppress the warning. If you guys agree, I will
> send a patch. It's true that this is a trivial issue since we are
> intentionally crashing the kernel but in our case, this additional
> complaint from the kernel is confusing our test scripts and they are
> generating false positives.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 07/20] PM / devfreq: Show the related information according to governor type
This patch modifies the following sysfs entry of DEVFREQ framework
because the devfreq device using passive governor don't need the same
information of the devfreq device using rest governor.
- polling_interval: passive gov don't use the sampling rate.
- available_governors : passive gov don't be changed on runtime in this version.
- trans_stat : passive governor don't support trans_stat in this
version.
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
drivers/devfreq/devfreq.c | 31 +--
drivers/devfreq/governor.h| 7 +++
drivers/devfreq/governor_passive.c| 1 +
drivers/devfreq/governor_performance.c| 1 +
drivers/devfreq/governor_powersave.c | 1 +
drivers/devfreq/governor_simpleondemand.c | 1 +
drivers/devfreq/governor_userspace.c | 1 +
include/linux/devfreq.h | 2 ++
8 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 78ea4cdaa82c..18ad956fec93 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -597,7 +597,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
goto err_init;
}
- if (!strncmp(devfreq->governor_name, "passive", 7)) {
+ if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
struct devfreq *parent_devfreq =
((struct devfreq_passive_data *)data)->parent;
@@ -963,13 +963,23 @@ static ssize_t available_governors_show(struct device *d,
struct device_attribute *attr,
char *buf)
{
- struct devfreq_governor *tmp_governor;
+ struct devfreq *devfreq = to_devfreq(d);
ssize_t count = 0;
mutex_lock(_list_lock);
- list_for_each_entry(tmp_governor, _governor_list, node)
+ if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
count += scnprintf([count], (PAGE_SIZE - count - 2),
- "%s ", tmp_governor->name);
+ "%s ", devfreq->governor->name);
+ } else {
+ struct devfreq_governor *tmp_governor;
+
+ list_for_each_entry(tmp_governor, _governor_list, node)
{
+ if (tmp_governor->type == DEVFREQ_GOV_PASSIVE)
+ continue;
+ count += scnprintf([count], (PAGE_SIZE - count - 2),
+ "%s ", tmp_governor->name);
+ }
+ }
mutex_unlock(_list_lock);
/* Truncate the trailing space */
@@ -1006,6 +1016,11 @@ static DEVICE_ATTR_RO(target_freq);
static ssize_t polling_interval_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
+ struct devfreq *df = to_devfreq(dev);
+
+ if (df->governor->type == DEVFREQ_GOV_PASSIVE)
+ return sprintf(buf, "Not Supported.\n");
+
return sprintf(buf, "%d\n", to_devfreq(dev)->profile->polling_ms);
}
@@ -1020,6 +1035,9 @@ static ssize_t polling_interval_store(struct device *dev,
if (!df->governor)
return -EINVAL;
+ if (df->governor->type == DEVFREQ_GOV_PASSIVE)
+ return -EINVAL;
+
ret = sscanf(buf, "%u", );
if (ret != 1)
return -EINVAL;
@@ -1137,11 +1155,12 @@ static ssize_t trans_stat_show(struct device *dev,
int i, j;
unsigned int max_state = devfreq->profile->max_state;
+ if (max_state == 0 || devfreq->governor->type == DEVFREQ_GOV_PASSIVE)
+ return sprintf(buf, "Not Supported.\n");
+
if (!devfreq->stop_polling &&
devfreq_update_status(devfreq, devfreq->previous_freq))
return 0;
- if (max_state == 0)
- return sprintf(buf, "Not Supported.\n");
len = sprintf(buf, " From : To\n");
len += sprintf(buf + len, " :");
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fad7d6321978..43513a58f5bf 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -18,6 +18,13 @@
#define to_devfreq(DEV)container_of((DEV), struct devfreq, dev)
+/* Devfreq governor type */
+#define DEVFREQ_GOV_ONDEMAND 0x1
+#define DEVFREQ_GOV_PERFORMANCE0x2
+#define DEVFREQ_GOV_POWERSAVE 0x3
+#define DEVFREQ_GOV_USERSPACE 0x4
+#define DEVFREQ_GOV_PASSIVE0x4
+
/* Devfreq events */
#define DEVFREQ_GOV_START 0x1
#define DEVFREQ_GOV_STOP 0x2
diff --git a/drivers/devfreq/governor_passive.c
b/drivers/devfreq/governor_passive.c
index 7443ae4b92f9..adfdee9a9cd1 100644
---
Re: percpu irq APIs and perf
Hi Marc, On Thursday 10 December 2015 03:26 PM, Marc Zyngier wrote: > Hi Vinnet, > > On 10/12/15 09:25, Vineet Gupta wrote: >> Hi Marc / Daniel / Jason, >> >> I had a couple of questions about percpu irq API, hopefully you can help >> answer. >> >> On ARM, how do u handle requesting per cpu IRQs - specifically usage >> of request_percpu_irq() / enable_percpu_irq() API. >> It seems, for using them, we obviously need to explicitly set irq as >> percpu and as a consequence explicitly enable autoen (since former >> disables that). See arch/arc/kernel/irq.c: arc_request_percpu_irq() >> called by ARC per cpu timer setup. > Indeed. The interrupt controller code flags these interrupts as being > per-cpu, and we do rely on each CPU performing an enable_percpu_irq(). > > So the way the whole thing flows is as such: > - Interrupt controller (GIC) flags the PPIs (Private Peripheral > Interrupt) as per-CPU (hwirq 16 to 31 are replicated per CPU) very early > in the boot process Thx for your reply and the pointers irq-gic.c seems to be doing irq_set_status_flags(irq, IRQ_NOAUTOEN); So it is setting NOAUTOEN, which is already the case per side effect of irq_set_percpu_devid(). No harm in making it explicit. So this will make __setup_irq() skip irq_startup() and instead rely on enable_precpu_irq() to be called even for the local core. I think we can make percpu irq API a bit easier to use. (1) First thing which request_percpu_irq() does is check for irq_settings_is_per_cpu_devid(). Thus irq_set_percpu_devid() can be built into the API itself eliding the need to set it apriori. (2) It seems that disabling autoen by default for percpu irq makes sense as evident from drivers/net/ethernet/marvell/mvneta.c where users want to control this. However the comment there is misleading /* Even though the documentation says that request_percpu_irq * doesn't enable the interrupts automatically, it actually * does so on the local CPU. * * Make sure it's disabled. */ Either sme core code is clearing NOAUTOEN or calling enable_precpu_irq() making request_percpu_irq() enable it. IMHO it makes more sense to make autoen explicit in the API. Perhaps introduce a API flavour, which takes the autoen as arg. It could take flags to make it more extensible / future safe but that will be an overkill I think. Do let me know what you think and I can send RFC patches to same effect. Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 22/60] PCI: Don't release sibling bridge resources during hotplug
On hotplug path, we can not touch sibling bridges that is outside
of the slot.
That could happen when BIOS does not assign some bridge BARs and
later kernel can not assign resource to them in first try.
Check if fail dev is the parent bridge, then just use subordinate
bus instead use parent bus.
Reported-by: Andreas Noever
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index c2e3999..7f7f46c 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1902,10 +1902,16 @@ again:
* Try to release leaf bridge's resources that doesn't fit resource of
* child device under that bridge
*/
- list_for_each_entry(fail_res, _head, list)
- pci_bus_release_bridge_resources(fail_res->dev->bus,
+ list_for_each_entry(fail_res, _head, list) {
+ struct pci_bus *bus = fail_res->dev->bus;
+
+ if (fail_res->dev == bridge)
+ bus = bridge->subordinate;
+
+ pci_bus_release_bridge_resources(bus,
fail_res->flags & type_mask,
whole_subtree);
+ }
/* restore size and flags */
list_for_each_entry(fail_res, _head, list) {
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 21/60] PCI: Get new realloc size for bridge for last try
Current realloc path would not shrink bridge resource through
pbus_size_mem() checking with the old size.
That cause problem: when "required+optional" resource allocation fails,
the cached bridge resource size will prevent "required" resource to get
allocated smaller resource.
Clear the old resource size for last try or third and later try.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81431
Tested-by: TJ
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index e4972f5..c2e3999 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1739,6 +1739,17 @@ static enum enable_type pci_realloc_detect(struct
pci_bus *bus,
}
#endif
+static void reset_bridge_resource_size(struct pci_dev *dev,
+ struct resource *res)
+{
+ int idx = res - >resource[0];
+
+ if (idx >= PCI_BRIDGE_RESOURCES && idx <= PCI_BRIDGE_RESOURCE_END) {
+ res->start = 0;
+ res->end = res->start - 1;
+ }
+}
+
/*
* first try will not touch pci bridge res
* second and later try will clear small leaf bridge res
@@ -1823,8 +1834,13 @@ again:
res->start = fail_res->start;
res->end = fail_res->end;
res->flags = fail_res->flags;
- if (fail_res->dev->subordinate)
+ if (fail_res->dev->subordinate) {
res->flags = 0;
+ /* last or third times and later */
+ if (tried_times + 1 == pci_try_num ||
+ tried_times + 1 > 2)
+ reset_bridge_resource_size(fail_res->dev, res);
+ }
}
free_list(_head);
@@ -1898,8 +1914,11 @@ again:
res->start = fail_res->start;
res->end = fail_res->end;
res->flags = fail_res->flags;
- if (fail_res->dev->subordinate)
+ if (fail_res->dev->subordinate) {
res->flags = 0;
+ /* last time */
+ reset_bridge_resource_size(fail_res->dev, res);
+ }
}
free_list(_head);
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 09/60] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource, so set
IORESOUCE_MEM_64 for 64bit resource during of device resource flags
parsing.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Gavin Shan
Cc: Yijing Wang
Cc: Anton Blanchard
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/kernel/pci_of_scan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index 349ed11..d7305d7 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -44,8 +44,10 @@ static unsigned int pci_parse_of_flags(u32 addr0, int bridge)
if (addr0 & 0x0200) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
- flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
+ if (addr0 & 0x0100)
+ flags |= IORESOURCE_MEM_64
+| PCI_BASE_ADDRESS_MEM_TYPE_64;
if (addr0 & 0x4000)
flags |= IORESOURCE_PREFETCH
| PCI_BASE_ADDRESS_MEM_PREFETCH;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 09/20] PM / devfreq: exynos: Update documentation for bus devices using passive governor
This patch updates the documentation for passive bus devices and adds the detailed example of Exynos3250. Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/devfreq/exynos-bus.txt | 250 - 1 file changed, 247 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt index e32daef328da..a251f9120561 100644 --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt @@ -8,22 +8,46 @@ of each buses on runtime. When gathering the usage of each buses on runtime, the driver uses the PPMU (Platform Performance Monitoring Unit) which is able to measure the current load of sub-blocks. +The Exynos SoC includes the various sub-blocks which have the each AXI bus. +The each AXI bus has the owned source clock but, has not the only owned +power line. The power line might be shared among one more sub-blocks. +So, we can divide into two type of device as the role of each sub-block. +There are two type of bus devices as following: +- parent bus device +- passive bus device + +Basically, parent and passive bus device share the same power line. +The parent bus device can only change the voltage of shared power line +and the rest bus devices (passive bus device) depend on the decision of +the parent bus device. If there are three blocks which share the VDD_xxx +power line, Only one block should be parent device and then the rest blocks +should depend on the parent device as passive device. + + VDD_xxx |--- A block (parent) + |--- B block (passive) + |--- C block (passive) + There are a little different composition among Exynos SoC because each Exynos SoC has the different sub-blocks. So, this difference should be specified in devicetree file instead of each device driver. In result, this driver is able to support the bus frequency for all Exynos SoCs. -Required properties for bus device: +Required properties for all bus devices: - compatible: Should be "samsung,exynos-bus". - clock-names : the name of clock used by the bus, "bus". - clocks : phandles for clock specified in "clock-names" property. - operating-points-v2: the OPP table including frequency/voltage information to support DVFS (Dynamic Voltage/Frequency Scaling) feature. + +Required properties only for parent bus device: - vdd-supply: the regulator to provide the buses with the voltage. - devfreq-events: the devfreq-event device to monitor the current utilization of buses. -Optional properties for bus device: +Required properties only for passive bus device: +- devfreq: the parent bus device. + +Optional properties only for parent bus device: - exynos,saturation-ratio: the percentage value which is used to calibrate the performance count against total cycle count. @@ -32,7 +56,20 @@ Example1: power line (regulator). The MIF (Memory Interface) AXI bus is used to transfer data between DRAM and CPU and uses the VDD_MIF regualtor. - - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block + - MIF (Memory Interface) block + : VDD_MIF |--- DMC (Dynamic Memory Controller) + + - INT (Internal) block + : VDD_INT |--- LEFTBUS (parent device) + |--- PERIL + |--- MFC + |--- G3D + |--- RIGHTBUS + |--- FSYS + |--- LCD0 + |--- PERIR + |--- ISP + |--- CAM - MIF bus's frequency/voltage table --- @@ -45,6 +82,24 @@ Example1: |L5| 40 |875000 | --- + - INT bus's frequency/voltage table + -- + |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL ||VDD_INT | + | name| |LCD0| | | ||| + | | |FSYS| | | ||| + | | |MFC | | | ||| + -- + |Mode |*parent|passive |passive|passive|passive||| + -- + |Lv |Frequency ||Voltage | + -- + |L1 |5 |5 |5 |5 |5 ||90 | + |L2 |8 |8 |8 |8 |8 ||90 | + |L3 |10 |10 |10 |10 |10 ||100 | + |L4 |134000 |134000 |20 |20 | ||100 | + |L5 |20 |20 |40 |30 | ||100 | + -- + Example2 : The bus of DMC (Dynamic Memory Controller) block in
[PATCH v3 11/20] PM / devfreq: exynos: Remove unused exynos4/5 busfreq driver
This patch removes the unused exynos4/5 busfreq driver. Instead,
generic exynos-bus frequency driver support the all Exynos SoCs.
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig | 22 -
drivers/devfreq/exynos/Makefile |2 -
drivers/devfreq/exynos/exynos4_bus.c | 1055 --
drivers/devfreq/exynos/exynos4_bus.h | 110
drivers/devfreq/exynos/exynos5_bus.c | 431 --
drivers/devfreq/exynos/exynos_ppmu.c | 119
drivers/devfreq/exynos/exynos_ppmu.h | 86 ---
7 files changed, 1825 deletions(-)
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 88f7cc4539b8..e82b1d8cd200 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -91,28 +91,6 @@ config ARM_EXYNOS_BUS_DEVFREQ
and adjusts the operating frequencies and voltages with OPP support.
This does not yet operate with optimal voltages.
-config ARM_EXYNOS4_BUS_DEVFREQ
- bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
- depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
!ARCH_MULTIPLATFORM
- select DEVFREQ_GOV_SIMPLE_ONDEMAND
- select PM_OPP
- help
- This adds the DEVFREQ driver for Exynos4210 memory bus (vdd_int)
- and Exynos4212/4412 memory interface and bus (vdd_mif + vdd_int).
- It reads PPMU counters of memory controllers and adjusts
- the operating frequencies and voltages with OPP support.
- This does not yet operate with optimal voltages.
-
-config ARM_EXYNOS5_BUS_DEVFREQ
- tristate "ARM Exynos5250 Bus DEVFREQ Driver"
- depends on SOC_EXYNOS5250
- select DEVFREQ_GOV_SIMPLE_ONDEMAND
- select PM_OPP
- help
- This adds the DEVFREQ driver for Exynos5250 bus interface (vdd_int).
- It reads PPMU counters of memory controllers and adjusts the
- operating frequencies and voltages with OPP support.
-
config ARM_TEGRA_DEVFREQ
tristate "Tegra DEVFREQ Driver"
depends on ARCH_TEGRA_124_SOC
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
index 4ec06d322996..bc695ad81c7d 100644
--- a/drivers/devfreq/exynos/Makefile
+++ b/drivers/devfreq/exynos/Makefile
@@ -1,4 +1,2 @@
# Exynos DEVFREQ Drivers
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
-obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos_ppmu.o exynos4_bus.o
-obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
deleted file mode 100644
index da9509205169..
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ /dev/null
@@ -1,1055 +0,0 @@
-/* drivers/devfreq/exynos4210_memorybus.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- * MyungJoo Ham
- *
- * EXYNOS4 - Memory/Bus clock frequency scaling support in DEVFREQ framework
- * This version supports EXYNOS4210 only. This changes bus frequencies
- * and vddint voltages. Exynos4412/4212 should be able to be supported
- * with minor modifications.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include "exynos_ppmu.h"
-#include "exynos4_bus.h"
-
-#define MAX_SAFEVOLT 120 /* 1.2V */
-
-enum exynos4_busf_type {
- TYPE_BUSF_EXYNOS4210,
- TYPE_BUSF_EXYNOS4x12,
-};
-
-/* Assume that the bus is saturated if the utilization is 40% */
-#define BUS_SATURATION_RATIO 40
-
-enum busclk_level_idx {
- LV_0 = 0,
- LV_1,
- LV_2,
- LV_3,
- LV_4,
- _LV_END
-};
-
-enum exynos_ppmu_idx {
- PPMU_DMC0,
- PPMU_DMC1,
- PPMU_END,
-};
-
-#define EX4210_LV_MAX LV_2
-#define EX4x12_LV_MAX LV_4
-#define EX4210_LV_NUM (LV_2 + 1)
-#define EX4x12_LV_NUM (LV_4 + 1)
-
-/**
- * struct busfreq_opp_info - opp information for bus
- * @rate: Frequency in hertz
- * @volt: Voltage in microvolts corresponding to this OPP
- */
-struct busfreq_opp_info {
- unsigned long rate;
- unsigned long volt;
-};
-
-struct busfreq_data {
- enum exynos4_busf_type type;
- struct device *dev;
- struct devfreq *devfreq;
- bool disabled;
- struct regulator *vdd_int;
- struct regulator *vdd_mif; /* Exynos4412/4212 only */
- struct busfreq_opp_info curr_oppinfo;
- struct busfreq_ppmu_data ppmu_data;
-
- struct
[PATCH v3 12/20] MAINTAINERS: Add samsung bus frequency driver entry
This patch adds the 'SAMSUNG BUS FREQUENCY DRIVER' entry to review the patches as supporter. Patches will be picked up by DEVFREQ maintainer on devfreq git repository. Signed-off-by: Chanwoo Choi --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ff2d20173d98..89e645688a3c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3434,6 +3434,15 @@ F: drivers/devfreq/devfreq-event.c F: include/linux/devfreq-event.h F: Documentation/devicetree/bindings/devfreq/event/ +SAMSUNG BUS FREQUENCY DRIVER +M: Chanwoo Choi +L: linux...@vger.kernel.org +L: linux-samsung-...@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git +S: Supported +F: drivers/devfreq/exynos/exynos-bus.c +F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt + DEVICE NUMBER REGISTRY M: Torben Mathiasen W: http://lanana.org/docs/device-list/index.html -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 13/20] ARM: dts: Add bus nodes using VDD_INT for Exynos3250
This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
Exynos3250 has following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK400 clock for MCUISP
- ACLK266 clock for ISP
- ACLK200 clock for FSYS
- ACLK160 clock for LCD0
- ACLK100 clock for PERIL
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250.dtsi | 147 ++
1 file changed, 147 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 262b3b1995fd..5cc98cf13173 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -735,6 +735,153 @@
opp-microvolt = <875000>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_lcd0: bus_lcd0 {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_ACLK_160>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_fsys: bus_fsys {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_ACLK_200>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mcuisp: bus_mcuisp {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_ACLK_400_MCUISP>;
+ clock-names = "bus";
+ operating-points-v2 = <_mcuisp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_isp: bus_isp {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_ACLK_266>;
+ clock-names = "bus";
+ operating-points-v2 = <_isp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_peril: bus_peril {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_ACLK_100>;
+ clock-names = "bus";
+ operating-points-v2 = <_peril_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mfc: bus_mfc {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_SCLK_MFC>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_leftbus_opp_table: opp_table2 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@5000 {
+ opp-hz = /bits/ 64 <5000>;
+ opp-microvolt = <90>;
+ };
+ opp@8000 {
+ opp-hz = /bits/ 64 <8000>;
+ opp-microvolt = <90>;
+ };
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <100>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <100>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <100>;
+ };
+ };
+
+ bus_mcuisp_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@5000 {
+ opp-hz = /bits/ 64 <5000>;
+ };
+ opp@8000 {
+
[PATCH v3 15/20] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD
: The minimum clock of ACLK160 should be over 160MHz.
When drop the clock under 160MHz, show the broken image.
- ACLK133 clock for FSYS
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
arch/arm/boot/dts/exynos4x12.dtsi | 106 ++
1 file changed, 106 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 99a0f4ca3d47..e5173107ed44 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -349,6 +349,112 @@
opp-hz = /bits/ 64 <26700>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_display: bus_display {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_ACLK160>;
+ clock-names = "bus";
+ operating-points-v2 = <_display_opp_table>;
+ status = "disabled";
+ };
+
+ bus_fsys: bus_fsys {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_ACLK133>;
+ clock-names = "bus";
+ operating-points-v2 = <_fsys_opp_table>;
+ status = "disabled";
+ };
+
+ bus_peri: bus_peri {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_ACLK100>;
+ clock-names = "bus";
+ operating-points-v2 = <_peri_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mfc: bus_mfc {
+ compatible = "samsung,exynos-bus";
+ clocks = < CLK_SCLK_MFC>;
+ clock-names = "bus";
+ operating-points-v2 = <_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_leftbus_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <90>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <925000>;
+ };
+ opp@16000 {
+ opp-hz = /bits/ 64 <16000>;
+ opp-microvolt = <95>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <100>;
+ };
+ };
+
+ bus_display_opp_table: opp_table4 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@16000 {
+ opp-hz = /bits/ 64 <16000>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ };
+ };
+
+ bus_fsys_opp_table: opp_table5 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ };
+ };
+
+ bus_peri_opp_table: opp_table6 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@5000 {
+ opp-hz = /bits/ 64 <5000>;
+ };
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ };
+ };
};
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 17/20] ARM: dts: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU node
This patch adds the exynos4412-ppmu-common.dtsi to duplicate PPMU node
because exynos3250-rinato/monk, exynos4412-trats2/odroidu3 has the same
PPMU device tree node.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250-monk.dts | 41 +
arch/arm/boot/dts/exynos3250-rinato.dts | 41 +
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
arch/arm/boot/dts/exynos4412-ppmu-common.dtsi | 49 +
arch/arm/boot/dts/exynos4412-trats2.dts | 41 +
5 files changed, 53 insertions(+), 120 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 456844a81189..a4e525e5e6e4 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include "exynos3250.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
#include
#include
#include
@@ -464,46 +465,6 @@
status = "okay";
};
-_dmc0 {
- status = "okay";
-
- events {
- ppmu_dmc0_3: ppmu-event3-dmc0 {
- event-name = "ppmu-event3-dmc0";
- };
- };
-};
-
-_dmc1 {
- status = "okay";
-
- events {
- ppmu_dmc1_3: ppmu-event3-dmc1 {
- event-name = "ppmu-event3-dmc1";
- };
- };
-};
-
-_leftbus {
- status = "okay";
-
- events {
- ppmu_leftbus_3: ppmu-event3-leftbus {
- event-name = "ppmu-event3-leftbus";
- };
- };
-};
-
-_rightbus {
- status = "okay";
-
- events {
- ppmu_rightbus_3: ppmu-event3-rightbus {
- event-name = "ppmu-event3-rightbus";
- };
- };
-};
-
{
clock-frequency = <2400>;
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index d6bb990ce931..2a1c22598fdc 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include "exynos3250.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
#include
#include
#include
@@ -641,46 +642,6 @@
status = "okay";
};
-_dmc0 {
- status = "okay";
-
- events {
- ppmu_dmc0_3: ppmu-event3-dmc0 {
- event-name = "ppmu-event3-dmc0";
- };
- };
-};
-
-_dmc1 {
- status = "okay";
-
- events {
- ppmu_dmc1_3: ppmu-event3-dmc1 {
- event-name = "ppmu-event3-dmc1";
- };
- };
-};
-
-_leftbus {
- status = "okay";
-
- events {
- ppmu_leftbus_3: ppmu-event3-leftbus {
- event-name = "ppmu-event3-leftbus";
- };
- };
-};
-
-_rightbus {
- status = "okay";
-
- events {
- ppmu_rightbus_3: ppmu-event3-rightbus {
- event-name = "ppmu-event3-rightbus";
- };
- };
-};
-
{
clock-frequency = <2400>;
};
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 395c3ca9601e..cda1ec86dfba 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include "exynos4412.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
#include
/ {
diff --git a/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
b/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
new file mode 100644
index ..653904c5d479
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
@@ -0,0 +1,49 @@
+/*
+ * Device tree sources for Exynos4412 PPMU common device tree
+ *
+ * Copyright (c) 2015 Chanwoo Choi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+_dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+ };
+};
+
+_dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+};
+
+_leftbus {
+ status = "okay";
+
+ events {
+ ppmu_leftbus_3: ppmu-event3-leftbus {
+ event-name = "ppmu-event3-leftbus";
+ };
+ };
+};
+
+_rightbus {
+ status = "okay";
+
+ events {
+ ppmu_rightbus_3: ppmu-event3-rightbus {
+ event-name = "ppmu-event3-rightbus";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
[PATCH v9 00/60] PCI: Resource allocation cleanup for v4.5
Hi, After 5b28541552ef (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources), we have several reports on resource allocation failure, and we try to fix the problem with resource clip, and find more problems. One is realloc fail with two graphics cards above 4G. One is from sparc that have problem with clip as we don't parse mem64 for it. Other report is about pci remove/rescan does not work on some setup when BIOS tend to allocate small bus size. This patchset enhance resource allocation to address those problems. patch 1-10: parse MEM64 for sparc and other system with OF patch 11-15: MMIO64 allocation enhancement treat non-pref mmio64 if parent bridges are all pcie. restore old pref allocation logic if hostbridge does not support mmio64. patch 16-18: FIXED resource handling during realloc don't realloc resource if device firmware does not support bar change. patch 19-22: bridge MMIO allocation with hotplug and last try. treat optional as required on first try when hotplug. MMIO size set to 0 for last try during realloc patch 23-56: enhancement for mmio resource allocation: optimize bus mmio alignment calculation. optimize bus mmio optional alignment calculation. add support for alt size to prefer small bus size to small bus alignment. treat ROM bar as optional resource. during allocation, will pick up best fit resource, and allocate near end. patch 57: add pci=assign_pref_bars to clear and assign pref bars. patch 58-59: don't clear resource when allocation fails patch 60: don't try io port allocation if root bus does not have io port. I put latest copy at: git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-v4.5-next That is based on v4.4-rc4. Yijing and Wei Yang both tested the branch, and the patchset fixs rescan problem, and is working well on powerpc setup. Khalid Aziz tested on some sparc platforms that have different offset to mem space start or support 64bit mmio. Thanks Yinghai v2: - fix resource_disabled allocation from powerpc. - other warnings that were found by Fengguang's build robot. - io port alignment clean up. - rebased to v4.2-rc2. - better for two alt_size support. v3: - fix reset bridge resource on last try: only with bridge resources. - remove/rescan path checking with old_size. v4: - Update changelog according to Bjorn. - split calculate_size patch to two. - use required instead of must. v5: - update changelog. - add one debug patch. - add one patch that get resource allocation near end of avialable window. v6: - reorder patches according to Bjorn. v7: - add some patches that fix problems on sparc that Khalid Aziz found. v8: - update patch 2, 3 to remove the assumpation about mem64_offset == mem_offset. - add one patch for pci_find_root_bus_resource() to support above change. - update pref_compatible flags handling after pci_find_root_bus_resource(). - add patch for quirk that ignore BAR for M1533 PCI-ISA bridge. v9: rebased for v4.5 Yinghai Lu (60): PCI: Add pci_find_root_bus_resource() sparc/PCI: Use correct bus address to resource offset sparc/PCI: Reserve legacy mmio after PCI mmio sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing sparc/PCI: Keep resource idx order with bridge register number PCI: Kill wrong quirk about M7101 PCI: Ignore BAR for ALi M1533 PCI-ISA bridge powerpc/PCI: Keep resource idx order with bridge register number powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource PCI: Check pref compatible bit for mem64 resource of PCIe device PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64 PCI: Add has_mem64 for struct host_bridge PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64 PCI: Restore pref MMIO allocation logic for host bridge without mmio64 PCI: Don't release fixed resource for realloc PCI: Claim fixed resource during remove/rescan path PCI: Set resource to FIXED for LSI devices PCI: Separate realloc list checking after allocation PCI: Treat optional as required in first try for bridge rescan PCI: Get new realloc size for bridge for last try PCI: Don't release sibling bridge resources during hotplug PCI: Cleanup res_to_dev_res() printout PCI: Reuse res_to_dev_res() in reassign_resources_sorted() PCI: Use correct align for optional only resources during sorting PCI: Optimize bus min_align/size calculation during sizing PCI: Optimize bus align/size calculation for optional during sizing PCI: Don't add too much optional size for hotplug bridge MMIO PCI: Reorder resources list for required/optional resources PCI: Remove duplicated code for resource sorting PCI: Rename pdev_sort_resources() to pdev_assign_resources_prepare() PCI: Treat ROM resource as optional
[PATCH v9 08/60] powerpc/PCI: Keep resource idx order with bridge register number
Same as sparc version.
Make resource with consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even non-pref mmio is missing, or out of ordering in firmware reporting.
So hold i = 1 for non pref mmio, and i = 2 for pref mmio.
Signed-off-by: Yinghai Lu
---
arch/powerpc/kernel/pci_of_scan.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index 2e710c1..349ed11 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -255,7 +255,7 @@ void of_scan_pci_bridge(struct pci_dev *dev)
bus->resource[i] = res;
++res;
}
- i = 1;
+ i = 3;
for (; len >= 32; len -= 32, ranges += 8) {
flags = pci_parse_of_flags(of_read_number(ranges, 1), 1);
size = of_read_number([6], 2);
@@ -268,6 +268,12 @@ void of_scan_pci_bridge(struct pci_dev *dev)
" for bridge %s\n", node->full_name);
continue;
}
+ } else if ((flags & IORESOURCE_PREFETCH) &&
+ !bus->resource[2]->flags) {
+ res = bus->resource[2];
+ } else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) ==
+ IORESOURCE_MEM) && !bus->resource[1]->flags) {
+ res = bus->resource[1];
} else {
if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
printk(KERN_ERR "PCI: too many memory ranges"
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 07/60] PCI: Ignore BAR for ALi M1533 PCI-ISA bridge
Meelis reported strange conflicts on sparc v210:
pci 0001:00:07.0: can't claim BAR 2 [mem 0x7ff-0x7ff000f]: address
conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f]
pci 0001:00:06.0: can't claim BAR 0 [io 0x7fe0100-0x7fe010f]: address
conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 0 [io 0x7fe01000900-0x7fe01000907]: address
conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 1 [io 0x7fe01000918-0x7fe0100091f]: address
conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 2 [io 0x7fe01000910-0x7fe01000917]: address
conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 3 [io 0x7fe01000908-0x7fe0100090f]: address
conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 4 [io 0x7fe01000920-0x7fe0100092f]: address
conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
PCI: /pci@1e,60 can't claim Video RAM area [mem
0x7ff000a-0x7ff000b]: address conflict with 0001:00:07.0 [mem
0x7ff-0x7ff000f]
PCI: /pci@1e,60 can't claim System ROM [mem 0x7ff000f-0x7ff000f]:
address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f]
PCI: /pci@1e,60 can't claim Video ROM [mem 0x7ff000c-0x7ff000c7fff]:
address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f]
we have
pci_bus 0001:00: root bus resource [io 0x7fe0100-0x7fe01ff] (bus
address [0x-0xff])
pci_bus 0001:00: root bus resource [mem 0x7ff-0x7ff] (bus
address [0x-0x])
so pci bus address in the bars for 0001:00:07.0 has all 0s.
0001:00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA
Bridge [Aladdin IV/V/V+]
Region 0: [virtual] I/O ports at [size=64K]
Region 1: Memory at (32-bit, non-prefetchable) [size=1M]
Region 2: Memory at (32-bit, non-prefetchable) [size=1M]
00: b9 10 33 15 0f 00 10 02 00 00 01 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
According to http://www.versalogic.com/Support/Downloads/pdf/ali1543.pdf
page 28: The indices before 40h are read-only.
and we have all 0 from 0x10-0x2f, according to lspci.
So those BAR do not work as regular BAR, just clean flags, and ignore them all
the way include claim and sizing and alloc etc.
Reported-by: Meelis Roos
Signed-off-by: Yinghai Lu
---
drivers/pci/quirks.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 7354127..3618c06 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -433,6 +433,21 @@ static void quirk_amd_nl_class(struct pci_dev *pdev)
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL_USB,
quirk_amd_nl_class);
+
+/*
+ * ALi m1533 pci to isa bridge does not have BAR according to datasheet,
+ * clear the flags, so we will try to claim them or reallocate res.
+ */
+static void quirk_ali1533(struct pci_dev *dev)
+{
+ int i;
+
+ for (i = 0; i < PCI_ROM_RESOURCE; i++)
+ dev->resource[i].flags = 0;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M1533,
+quirk_ali1533);
+
static void piix4_io_quirk(struct pci_dev *dev, const char *name, unsigned int
port, unsigned int enable)
{
u32 devres;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 20/20] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3
THis patch adds the bus device tree nodes for both MIF (Memory) and INT
(Internal) block to enable the bus frequency.
The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
bus is parent device in INT block using VDD_INT.
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47
arch/arm/boot/dts/exynos4412-trats2.dts | 48 +
2 files changed, 95 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 7bd65026761e..b6818aec7cf9 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -501,3 +501,50 @@
{
status = "okay";
};
+
+_acp {
+ devfreq = <_dmc>;
+ status = "okay";
+};
+
+_c2c {
+ devfreq = <_dmc>;
+ status = "okay";
+};
+
+_dmc {
+ devfreq-events = <_dmc0_3>, <_dmc1_3>;
+ vdd-supply = <_reg>;
+ status = "okay";
+};
+
+_display {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
+
+_fsys {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
+
+_leftbus {
+ devfreq-events = <_leftbus_3>, <_rightbus_3>;
+ vdd-supply = <_reg>;
+ status = "okay";
+};
+
+_mfc {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
+
+_peri {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
+
+_rightbus {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 92438eb6eec6..0b8aff3b8cb7 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -1251,3 +1251,51 @@
vtmu-supply = <_reg>;
status = "okay";
};
+
+_acp {
+ devfreq = <_dmc>;
+ status = "okay";
+};
+
+_c2c {
+ devfreq = <_dmc>;
+ status = "okay";
+};
+
+_dmc {
+ devfreq-events = <_dmc0_3>, <_dmc1_3>;
+ vdd-supply = <_reg>;
+ status = "okay";
+};
+
+_display {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
+
+
+_fsys {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
+
+_leftbus {
+ devfreq-events = <_leftbus_3>, <_rightbus_3>;
+ vdd-supply = <_reg>;
+ status = "okay";
+};
+
+_mfc {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
+
+_peri {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
+
+_rightbus {
+ devfreq = <_leftbus>;
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 19/20] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3
This patch expands the voltage range of buck1/3 regulator due to as following:
- MIF (Memory Interface) bus frequency needs the range of '900 - 1050 mV'.
- INT (Internal) bus frequency needs the range of '900 - 1000 mV'.
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index cda1ec86dfba..7bd65026761e 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -356,8 +356,8 @@
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
- regulator-min-microvolt = <100>;
- regulator-max-microvolt = <100>;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <105>;
regulator-always-on;
regulator-boot-on;
};
@@ -372,7 +372,7 @@
buck3_reg: BUCK3 {
regulator-name = "vdd_int";
- regulator-min-microvolt = <100>;
+ regulator-min-microvolt = <90>;
regulator-max-microvolt = <100>;
regulator-always-on;
regulator-boot-on;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 14/60] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64
If host bridge does not have mmio64 above 4G, We don't need to
treat device non-pref mmio64 as as pref mmio64.
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
---
drivers/pci/setup-bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index d627218..0befb0a 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -742,7 +742,7 @@ int pci_claim_bridge_resource(struct pci_dev *bridge, int i)
static bool pci_up_path_over_pref_mem64(struct pci_bus *bus)
{
if (pci_is_root_bus(bus))
- return true;
+ return to_pci_host_bridge(bus->bridge)->has_mem64;
if (bus->self) {
int i;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 40/60] PCI: Separate required+optional assigning to another function
__assign_resources_sorted() is getting too big if we put alt_size support
into it. Split out required+optional assigning code to another function.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 47 +++
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index a8e3eaa..b813340 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -473,20 +473,9 @@ static void restore_resource(struct pci_dev_resource
*save_res,
res->flags = save_res->flags;
}
-static void __assign_resources_sorted(struct list_head *head,
-struct list_head *realloc_head,
-struct list_head *fail_head)
+static bool __assign_resources_required_optional_sorted(struct list_head *head,
+struct list_head *realloc_head)
{
- /*
-* Should not assign requested resources at first.
-* they could be adjacent, so later reassign can not reallocate
-* them one by one in parent resource window.
-* Try to assign requested + add_size at beginning
-* if could do that, could get out early.
-* if could not do that, we still try to assign requested at first,
-*then try to reassign add_size for some resources.
-*/
-
LIST_HEAD(save_head);
LIST_HEAD(local_fail_head);
struct pci_dev_resource *save_res;
@@ -495,12 +484,8 @@ static void __assign_resources_sorted(struct list_head
*head,
resource_size_t add_align;
struct resource *res;
- /* Check if optional add_size is there */
- if (!realloc_head || list_empty(realloc_head))
- goto requested_and_reassign;
-
if (!save_resources(head, _head))
- goto requested_and_reassign;
+ return false;
/* Update res in head list with add_size in realloc_head list */
list_for_each_entry(dev_res, head, list) {
@@ -539,7 +524,8 @@ static void __assign_resources_sorted(struct list_head
*head,
remove_from_list(realloc_head, dev_res->res);
free_list(_head);
free_list(head);
- return;
+
+ return true;
}
/* check failed type */
@@ -574,7 +560,28 @@ static void __assign_resources_sorted(struct list_head
*head,
free_list(_head);
-requested_and_reassign:
+ return false;
+}
+
+static void __assign_resources_sorted(struct list_head *head,
+struct list_head *realloc_head,
+struct list_head *fail_head)
+{
+ /*
+* Should not assign required resources at first.
+* they could be adjacent, so later reassign can not reallocate
+* them one by one in parent resource window.
+* Try to assign required + optional at beginning
+* if could do that, could get out early.
+* if could not do that, we still try to assign required at first,
+*then try to reassign add_size for some resources.
+*/
+
+ /* Check required+optional add */
+ if (realloc_head && !list_empty(realloc_head) &&
+ __assign_resources_required_optional_sorted(head, realloc_head))
+ return;
+
sort_resources(head);
/* Satisfy the must-have resource requests */
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 29/60] PCI: Reorder resources list for required/optional resources
We try to allocate required+optional before allocate required only and
expand with optional.
At first we update size and alignment for required+optional resource.
And after that we reorder them with new alignment, but current we only
do that STARTALIGN ones.
For SIZEALIGN type resource, after add back add_size, the alignment
get changed, so need to do sorting like STARTALIGN type resources.
Also we need to reorder the sorting back after we restore
resource to required only when required+optional fail to allocate for all.
So move out the reordering code from the loop to separated function,
and call it two times accordingly.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 62 +
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 53014e1..885b9f8 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -286,6 +286,31 @@ static inline void reset_resource(struct resource *res)
res->flags = 0;
}
+static void sort_resources(struct list_head *head)
+{
+ struct pci_dev_resource *res1, *tmp_res, *res2;
+
+ list_for_each_entry_safe(res1, tmp_res, head, list) {
+ resource_size_t align1, size1, align2, size2;
+
+ align1 = pci_resource_alignment(res1->dev, res1->res);
+ size1 = resource_size(res1->res);
+
+ /* reorder it */
+ list_for_each_entry(res2, head, list) {
+ if (res2 == res1)
+ break;
+
+ align2 = pci_resource_alignment(res2->dev, res2->res);
+ size2 = resource_size(res2->res);
+ if (is_before(align1, size1, align2, size2)) {
+ list_move_tail(>list, >list);
+ break;
+ }
+ }
+ }
+}
+
/**
* reassign_resources_sorted() - satisfy any additional resource requests
*
@@ -454,9 +479,9 @@ static void __assign_resources_sorted(struct list_head
*head,
LIST_HEAD(save_head);
LIST_HEAD(local_fail_head);
struct pci_dev_resource *save_res;
- struct pci_dev_resource *dev_res, *tmp_res, *dev_res2;
+ struct pci_dev_resource *dev_res, *tmp_res;
unsigned long fail_type;
- resource_size_t add_align, align;
+ resource_size_t add_align;
/* Check if optional add_size is there */
if (!realloc_head || list_empty(realloc_head))
@@ -471,47 +496,32 @@ static void __assign_resources_sorted(struct list_head
*head,
}
/* Update res in head list with add_size in realloc_head list */
- list_for_each_entry_safe(dev_res, tmp_res, head, list) {
+ list_for_each_entry(dev_res, head, list) {
dev_res->res->end += get_res_add_size(realloc_head,
dev_res->res);
/*
* There are two kinds of additional resources in the list:
-* 1. bridge resource -- IORESOURCE_STARTALIGN
-* 2. SR-IOV resource -- IORESOURCE_SIZEALIGN
-* Here just fix the additional alignment for bridge
+* 1. bridge resource with IORESOURCE_STARTALIGN
+*need to update start to change alignment
+* 2. resource with IORESOURCE_SIZEALIGN
+*update size above already change alignment.
*/
if (!(dev_res->res->flags & IORESOURCE_STARTALIGN))
continue;
add_align = get_res_add_align(realloc_head, dev_res->res);
- /*
-* The "head" list is sorted by the alignment to make sure
-* resources with bigger alignment will be assigned first.
-* After we change the alignment of a dev_res in "head" list,
-* we need to reorder the list by alignment to make it
-* consistent.
-*/
- if (add_align > dev_res->res->start) {
+ if (add_align) {
resource_size_t r_size = resource_size(dev_res->res);
dev_res->res->start = add_align;
dev_res->res->end = add_align + r_size - 1;
-
- list_for_each_entry(dev_res2, head, list) {
- align = pci_resource_alignment(dev_res2->dev,
- dev_res2->res);
- if (add_align > align) {
- list_move_tail(_res->list,
- _res2->list);
- break;
- }
- }
}
-
}
+ sort_resources(head);
+
[PATCH v9 32/60] PCI: Treat ROM resource as optional during realloc
Current on realloc path, we just ignore ROM resource if we can not assign
them in first try.
Treat ROM resources as optional resources,so try to allocate them together
with required ones, if can not assign them, could go with other required
resources only, and try to allocate them second time in expand path.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 194d5da..e9e67bc 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -377,18 +377,10 @@ static void assign_requested_resources_sorted(struct
list_head *head,
idx = res - _res->dev->resource[0];
if (resource_size(res) &&
pci_assign_resource(dev_res->dev, idx)) {
- if (fail_head) {
- /*
-* if the failed res is for ROM BAR, and it will
-* be enabled later, don't add it to the list
-*/
- if (!((idx == PCI_ROM_RESOURCE) &&
- (!(res->flags & IORESOURCE_ROM_ENABLE
- add_to_list(fail_head,
- dev_res->dev, res,
- 0 /* don't care */,
- 0 /* don't care */);
- }
+ if (fail_head)
+ add_to_list(fail_head, dev_res->dev, res,
+ 0 /* don't care */,
+ 0 /* don't care */);
reset_resource(res);
}
}
@@ -1186,6 +1178,19 @@ out:
return good_align;
}
+static inline bool is_optional(int i)
+{
+
+ if (i == PCI_ROM_RESOURCE)
+ return true;
+
+#ifdef CONFIG_PCI_IOV
+ if (i >= PCI_IOV_RESOURCES && i <= PCI_IOV_RESOURCE_END)
+ return true;
+#endif
+
+ return false;
+}
/**
* pbus_size_mem() - size the memory window of a given bus
*
@@ -1244,10 +1249,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
r_size = resource_size(r);
align = pci_resource_alignment(dev, r);
-#ifdef CONFIG_PCI_IOV
- /* put SRIOV requested res to the optional list */
- if (realloc_head && i >= PCI_IOV_RESOURCES &&
- i <= PCI_IOV_RESOURCE_END) {
+ /* put SRIOV/ROM res to realloc list */
+ if (realloc_head && is_optional(i)) {
add_to_align_test_list(_test_add_list,
align, r_size);
r->end = r->start - 1;
@@ -1257,7 +1260,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
max_add_align = align;
continue;
}
-#endif
+
if (align > (1ULL<<37)) { /*128 Gb*/
dev_warn(>dev, "disabling BAR %d: %pR (bad
alignment %#llx)\n",
i, r, (unsigned long long) align);
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
