Re: [PATCH -tip v3 03/11] [CLEANUP] perf-probe: Replace line_list with intlist
On Thu, 06 Feb 2014 05:32:09 +, Masami Hiramatsu wrote: > Replace line_list (struct line_node) with intlist for > reducing similar codes. Acked-by: Namhyung Kim Thanks, Namhyung -- 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: sti: Remove SOC_STIH415 and SOC_STIH416
Hi Paul, On 02/16/2014 08:05 PM, Paul Bolle wrote: The Kconfig symbols SOC_STIH415 and SOC_STIH416 were added in v3.11. They have never been used. They default to "y" but nothing cares. They can safely be removed. This is going to be used by the reset controller series from Srinivas: http://marc.info/?l=linux-arm-kernel&m=139143833415806&w=2 Regards, Maxime Signed-off-by: Paul Bolle --- Tested with "git grep". arch/arm/mach-sti/Kconfig | 23 --- 1 file changed, 23 deletions(-) diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig index d71654b..c360ae1 100644 --- a/arch/arm/mach-sti/Kconfig +++ b/arch/arm/mach-sti/Kconfig @@ -21,26 +21,3 @@ menuconfig ARCH_STI for discovery More information at Documentation/arm/STiH41x and at Documentation/devicetree - - -if ARCH_STI - -config SOC_STIH415 - bool "STiH415 STMicroelectronics Consumer Electronics family" - default y - help - This enables support for STMicroelectronics Digital Consumer - Electronics family StiH415 parts, primarily targeted at set-top-box - and other digital audio/video applications using Flattned Device - Trees. - -config SOC_STIH416 - bool "STiH416 STMicroelectronics Consumer Electronics family" - default y - help - This enables support for STMicroelectronics Digital Consumer - Electronics family StiH416 parts, primarily targeted at set-top-box - and other digital audio/video applications using Flattened Device - Trees. - -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/
Re: [PATCH -tip v3 01/11] [BUGFIX] perf-probe: Fix to do exit call for symbol maps
Hi Masami,
On Thu, 06 Feb 2014 05:32:04 +, Masami Hiramatsu wrote:
> Some perf-probe commands do symbol_init() but doesn't
> do exit call. This fixes that to call symbol_exit()
> and releases machine if needed.
> This also merges init_vmlinux() and init_user_exec()
> because both of them are doing similar things.
> (init_user_exec() just skips init vmlinux related
> symbol maps)
>
> Changes from v2:
> - Not to set symbol_conf.try_vmlinux_path in init_symbol_maps()
>(Thanks to Namhyung Kim!)
>
> Signed-off-by: Masami Hiramatsu
[SNIP]
> -int show_line_range(struct line_range *lr, const char *module)
> +static int __show_line_range(struct line_range *lr, const char *module)
> {
> int l = 1;
> struct line_node *ln;
> @@ -573,10 +568,6 @@ int show_line_range(struct line_range *lr, const char
> *module)
> char *tmp;
>
> /* Search a line range */
> - ret = init_vmlinux();
> - if (ret < 0)
> - return ret;
> -
> dinfo = open_debuginfo(module);
> if (!dinfo) {
> pr_warning("Failed to open debuginfo file.\n");
> @@ -646,6 +637,19 @@ end:
> return ret;
> }
>
> +int show_line_range(struct line_range *lr, const char *module)
> +{
> + int ret;
> +
> + ret = init_symbol_maps(false);
> + if (ret < 0)
> + return ret;
> + ret = __show_line_range(lr, module);
> + exit_symbol_maps();
Wouldn't it be better moving init/exit_symbol_maps() to a common
location if they're used by every operations?
Thanks,
Namhyung
> +
> + return ret;
> +}
> +
> static int show_available_vars_at(struct debuginfo *dinfo,
> struct perf_probe_event *pev,
> int max_vls, struct strfilter *_filter,
> @@ -707,14 +711,15 @@ int show_available_vars(struct perf_probe_event *pevs,
> int npevs,
> int i, ret = 0;
> struct debuginfo *dinfo;
>
> - ret = init_vmlinux();
> + ret = init_symbol_maps(false);
> if (ret < 0)
> return ret;
>
> dinfo = open_debuginfo(module);
> if (!dinfo) {
> pr_warning("Failed to open debuginfo file.\n");
> - return -ENOENT;
> + ret = -ENOENT;
> + goto out;
> }
>
> setup_pager();
> @@ -724,6 +729,8 @@ int show_available_vars(struct perf_probe_event *pevs,
> int npevs,
>externs);
>
> debuginfo__delete(dinfo);
> +out:
> + exit_symbol_maps();
> return ret;
> }
>
> @@ -1807,7 +1814,7 @@ int show_perf_probe_events(void)
> if (fd < 0)
> return fd;
>
> - ret = init_vmlinux();
> + ret = init_symbol_maps(false);
> if (ret < 0)
> return ret;
>
> @@ -1820,6 +1827,7 @@ int show_perf_probe_events(void)
> close(fd);
> }
>
> + exit_symbol_maps();
> return ret;
> }
>
> @@ -2135,12 +2143,7 @@ int add_perf_probe_events(struct perf_probe_event
> *pevs, int npevs,
> if (pkgs == NULL)
> return -ENOMEM;
>
> - if (!pevs->uprobes)
> - /* Init vmlinux path */
> - ret = init_vmlinux();
> - else
> - ret = init_user_exec();
> -
> + ret = init_symbol_maps(pevs->uprobes);
> if (ret < 0) {
> free(pkgs);
> return ret;
> @@ -2174,6 +2177,7 @@ end:
> zfree(&pkgs[i].tevs);
> }
> free(pkgs);
> + exit_symbol_maps();
>
> return ret;
> }
> @@ -2347,7 +2351,7 @@ static int available_kernel_funcs(const char *module)
> struct map *map;
> int ret;
>
> - ret = init_vmlinux();
> + ret = init_symbol_maps(false);
> if (ret < 0)
> return ret;
>
> @@ -2356,7 +2360,10 @@ static int available_kernel_funcs(const char *module)
> pr_err("Failed to find %s map.\n", (module) ? : "kernel");
> return -EINVAL;
> }
> - return __show_available_funcs(map);
> + ret = __show_available_funcs(map);
> + exit_symbol_maps();
> +
> + return ret;
> }
>
> static int available_user_funcs(const char *target)
> @@ -2364,7 +2371,7 @@ static int available_user_funcs(const char *target)
> struct map *map;
> int ret;
>
> - ret = init_user_exec();
> + ret = init_symbol_maps(true);
> if (ret < 0)
> return ret;
>
> @@ -2372,6 +2379,7 @@ static int available_user_funcs(const char *target)
> ret = __show_available_funcs(map);
> dso__delete(map->dso);
> map__delete(map);
> + exit_symbol_maps();
> return ret;
> }
>
--
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 1/1] ARM: OMAP: Kill warning in CPUIDLE code with !CONFIG_SMP
From: Santosh Shilimkar
for non SMP build, NR_CPUS is 1 and hence the code complains with below
warnings.
arch/arm/mach-omap2/cpuidle44xx.c:207:8: warning: array subscript is above
array bounds [-Warray-bounds]
arch/arm/mach-omap2/cpuidle44xx.c:212:11: warning: array subscript is above
array bounds [-Warray-bounds]
Kill it by making array size fixed.
Acked-by: Nishanth Menon
Signed-off-by: Santosh Shilimkar
Signed-off-by: Mugunthan V N
---
This patch is created on top of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git master
---
arch/arm/mach-omap2/cpuidle44xx.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 4c158c8..01fc710 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -23,6 +23,8 @@
#include "prm.h"
#include "clockdomain.h"
+#define MAX_CPUS 2
+
/* Machine specific information */
struct idle_statedata {
u32 cpu_state;
@@ -48,11 +50,11 @@ static struct idle_statedata omap4_idle_data[] = {
},
};
-static struct powerdomain *mpu_pd, *cpu_pd[NR_CPUS];
-static struct clockdomain *cpu_clkdm[NR_CPUS];
+static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
+static struct clockdomain *cpu_clkdm[MAX_CPUS];
static atomic_t abort_barrier;
-static bool cpu_done[NR_CPUS];
+static bool cpu_done[MAX_CPUS];
static struct idle_statedata *state_ptr = &omap4_idle_data[0];
/* Private functions */
--
1.9.0.rc3.21.g475c52b
--
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] spi: core: Validate lenght of the transfers in message
Hi,
On Sun, 2014-02-16 at 15:25 +0100, Gerhard Sittig wrote:
> On Sat, Feb 15, 2014 at 08:09 +0200, Ivan T. Ivanov wrote:
> >
> > From: "Ivan T. Ivanov"
> >
> > SPI transfer lenght should be a power-of-two multiple
> > of eight bits.
>
> Please re-check for "lenght" typos in subjects and commit logs
> (code comments appear to be correct already).
Thanks, will correct them.
>
>
> The commit message still confuses me. You don't check that the
> length of an SPI transfer has a power-of-two length in bytes.
>
> Instead what the check implements is IIUC
> - pad "odd" bits-per-word settings before the check to full 1/2/4
> byte length specs (this is the power-of-two thing)
> - the total length of the SPI transfer cannot be empty (which I'd
> consider an optimization, not a violation, and may need a
> separate discussion)
I am not sure that I understand this one. I will say "the total
length of the SPI transfer _should not_ be empty". There is no
check for this currently.
> - the total length of the SPI transfer must be such that each
> "word" must be provided within a full 1/2/4 byte entity, with
> padding bits if the bits-per-word is "odd"
>
> Is this a misunderstanding on my side? A terminology thing? To
> me, the "SPI transfer" is the total payload and may have any
> arbitrary length. What you check for is a constraint on the
> transfer's length derived from or based on the "word length"
> ('word' in SPI context).
>
> So the code may be appropriate, yet the description may need an
> update, to not have the next person ask the same questions again.
>
I just forgot to update commit message. Will try to be more
careful next time.
Regards,
Ivan
>
> virtually yours
> Gerhard Sittig
--
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: [tip:x86/vdso] x86, vdso: Instead of dummy functions, include < linux/spinlock_up.h>
Hi Peter, Am Sonntag, den 16.02.2014, 20:06 -0800 schrieb H. Peter Anvin: > On 02/16/2014 07:51 PM, tip-bot for H. Peter Anvin wrote: > > Commit-ID: bd9ee7fd99f127ee1306289415141d45792c97f3 > > Gitweb: > > http://git.kernel.org/tip/bd9ee7fd99f127ee1306289415141d45792c97f3 > > Author: H. Peter Anvin > > AuthorDate: Sun, 16 Feb 2014 19:47:01 -0800 > > Committer: H. Peter Anvin > > CommitDate: Sun, 16 Feb 2014 19:47:01 -0800 > > > > x86, vdso: Instead of dummy functions, include > > > > The list of dummy functions is insufficient. However, instead of > > having a full list of dummy functions we can include > > which contains the (trivial) implementations > > that we use on uniprocessor. > > > > There aren't supposed to be any spinlocks at all in the VDSO, of > > course. > > > > That didn't work either. I thought I was clever, but it didn't work at > all. Multiple build failures across numerous configurations. This is > turning into a total headache. > > The "right" way to fix this is presumably to refactor a bunch of header > files so that the vdso code doesn't have to include a bunch of kernel > internal headers, but that is a lot of work. > I think for the first time it will be okay to kick out the _ASM_X86_SPINLOCK_H hack and accept the C=1 warnings. At next step it is necessary to make the whole BUILD_VDSO32 path in vclock_gettime.c independent from the kernel headers, only uapi/ should be included. The use of cycle_t must be replaced with u64. We need a own copy of __native_read_tsc(), __iter_div_u64_rem, smp_rmb() and cpu_relax(). For the non BUILD_VDSO32 path we must only move the #includes inside this #ifndef BUILD_VDSO32 - Stefani -- 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] IA64, sba_iommu: fix section mismatch
Fix the section mismatch warning by remove __init annotate for function
acpi_sba_ioc_add() because it may be called at runtime.
WARNING: vmlinux.o(.data+0x66ee0): Section mismatch in reference from the
variable acpi_sba_ioc_handler to the function .init.text:acpi_sba_ioc_add()
The variable acpi_sba_ioc_handler references
the function __init acpi_sba_ioc_add()
Signed-off-by: Jiang Liu
---
arch/ia64/hp/common/sba_iommu.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 8e858b5..30c43d3 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -1596,7 +1596,7 @@ static void sba_unmap_sg_attrs(struct device *dev, struct
scatterlist *sglist,
*
***/
-static void __init
+static void
ioc_iova_init(struct ioc *ioc)
{
int tcnfg;
@@ -1807,7 +1807,7 @@ static struct ioc_iommu ioc_iommu_info[] __initdata = {
{ SX2000_IOC_ID, "sx2000", NULL },
};
-static struct ioc * __init
+static struct ioc *
ioc_init(unsigned long hpa, void *handle)
{
struct ioc *ioc;
@@ -2041,7 +2041,7 @@ sba_map_ioc_to_node(struct ioc *ioc, acpi_handle handle)
#define sba_map_ioc_to_node(ioc, handle)
#endif
-static int __init
+static int
acpi_sba_ioc_add(struct acpi_device *device,
const struct acpi_device_id *not_used)
{
--
1.7.10.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 10/10] Documentation: Add device tree bindings for TI LMU devices
Hi Mark,
On 02/15/2014 05:50 AM, Mark Brown wrote:
On Fri, Feb 14, 2014 at 03:32:44PM +0900, Milo Kim wrote:
Bindings for TI LMU, backlight, LM3631 regulator and LM3633 LED are added.
Ah, sorry - I didn't notice that there were several different binding
documents in the patch.
@@ -0,0 +1,49 @@
+TI LMU LM3631 regulator device tree bindings
+
+Required properties:
+ - compatible: "ti,lm3631-regulator"
+
+Optional properties:
+ - regulator-name
+ - regulator-min-microvolt
+ - regulator-max-microvolt
+ - regulator-always-on
+ - regulator-boot-on
+
+ For those properties, please refer to:
+ Documentation/devicetree/bindings/regulator/regulator.txt
This doesn't correspond to the example which says that there is an
optional property "regulators" which can contain regualators lcd_boost,
lcd_vpos and lcd_vneg. It's also better to not enumerate all the
standard properties but just refer to the generic document (as you do).
That avoids confusion if new properties are added to the generic
regulator bindings.
The actual binding is fine, it's just the way it's documented.
Thank you. I've fixed things based on your comments.
Could you check the description below?
I'd like to get your feedback before sending patch-set v2.
From f0dcb9d8b21d38a6764c2e43cde4b41da3078c23 Mon Sep 17 00:00:00 2001
From: Milo Kim
Date: Mon, 17 Feb 2014 14:33:15 +0900
Subject: [PATCH 2/2] Documentation: fix LM3631 regulator DT based on
maintainer's feedback
Signed-off-by: Milo Kim
---
.../bindings/regulator/lm3631-regulator.txt| 63
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/lm3631-regulator.txt
diff --git
a/Documentation/devicetree/bindings/regulator/lm3631-regulator.txt
b/Documentation/devicetree/bindings/regulator/lm3631-regulator.txt
new file mode 100644
index 000..272cdc1
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/lm3631-regulator.txt
@@ -0,0 +1,63 @@
+TI LMU LM3631 regulator device tree bindings
+
+Required properties:
+ - compatible: "ti,lm3631-regulator"
+
+Sub-nodes:
+ - vboost
+ - vcont
+ - voref
+ - vpos
+ - vneg
+
+ Optional properties of each node:
+ Please refer to Documentation/devicetree/bindings/regulator/regulator.txt
+
+LM3631 regulator is represented as a sub-node of the "ti,lm3631" device.
+Please refer to "ti,lm3631" in
Documentation/devicetree/bindings/mfd/ti-lmu.txt
+
+Example:
+
+lm3631@29 {
+ compatible = "ti,lm3631";
+ reg = <0x29>;
+
+ ti,enable-gpio = <&gpio5 6 GPIO_ACTIVE_HIGH>;
+
+ regulators {
+ compatible = "ti,lm3631-regulator";
+
+ vboost {
+ regulator-name = "lcd_boost";
+ regulator-min-microvolt = <450>;
+ regulator-max-microvolt = <635>;
+ regulator-always-on;
+ };
+
+ vcont {
+ regulator-name = "lcd_vcont";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+
+ voref {
+ regulator-name = "lcd_voref";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <600>;
+ };
+
+ vpos {
+ regulator-name = "lcd_vpos";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <600>;
+ regulator-boot-on;
+ };
+
+ vneg {
+ regulator-name = "lcd_vneg";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <600>;
+ regulator-boot-on;
+ };
+ };
+};
--
1.7.9.5
Best regards,
Milo
--
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 10/10] Documentation: Add device tree bindings for TI LMU devices
Hello Mark,
Thanks for your detailed comments.
I've fixed the structure and description.
I'd like to have your feedback before submitting new patch-set.
From 33faeeed69fa064cd476b252c5a7326a541e12b3 Mon Sep 17 00:00:00 2001
From: Milo Kim
Date: Mon, 17 Feb 2014 14:32:39 +0900
Subject: [PATCH 1/2] Documentation: TI LMU DT fix based on Maintainer's
feedback
Signed-off-by: Milo Kim
---
.../devicetree/bindings/leds/leds-lm3633.txt | 47 +
Documentation/devicetree/bindings/mfd/ti-lmu.txt | 200
.../bindings/video/backlight/ti-lmu-backlight.txt | 153 +++
3 files changed, 400 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt
create mode 100644 Documentation/devicetree/bindings/mfd/ti-lmu.txt
create mode 100644
Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3633.txt
b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
new file mode 100644
index 000..10546cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
@@ -0,0 +1,47 @@
+TI LMU LM3633 LED device tree bindings
+
+Required properties:
+ - compatible: "ti,lm3633-leds"
+
+Sub-nodes:
+ Maximum 6 LED channels can be configured in each sub-node.
+
+ Required properties of sub-node:
+ - lvled1-used, lvled2-used, lvled3-used, lvled4-used, lvled5-used,
lvled6-used
+: LED string configuration about which LED string is used.
+
+ Optional properties of sub-node:
+ - channel-name: Name string for LED channel identification
+ - max-current-milliamp: Max current setting. Type is . Unit is mA.
+ Range is from 5 to 30 mA.
+
+LM3633 LED is represented as a sub-node of the "ti,lm3633" device.
+Please refer to "ti,lm3633" in
Documentation/devicetree/bindings/mfd/ti-lmu.txt
+
+Example:
+
+lm3633@36 {
+ compatible = "ti,lm3633";
+ reg = <0x36>;
+
+ ti,enable-gpio = <&gpio5 6 GPIO_ACTIVE_HIGH>;
+
+ leds {
+ compatible = "ti,lm3633-leds";
+
+ chan2 {
+ channel-name = "status";
+ lvled2-used;
+ max-current-milliamp = /bits/ 8 <6>;
+ };
+
+ chan456 {
+ channel-name = "rgb";
+ lvled4-used;
+ lvled5-used;
+ lvled6-used;
+
+ max-current-milliamp = /bits/ 8 <5>;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
new file mode 100644
index 000..5e21ce9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
@@ -0,0 +1,200 @@
+TI LMU(Lighting Management Unit) device tree bindings
+
+TI LMU driver supports lighting devices belows.
+
+ NameDevice tree properties
+ --
+ LM3532 Backlight
+ LM3631 Backlight and regulator
+ LM3633 Backlight and LED
+ LM3695 Backlight
+ LM3697 Backlight
+
+Those have shared device tree properties.
+
+Required properties:
+ - compatible: Should be one of lists below.
+"ti,lm3532"
+"ti,lm3631"
+"ti,lm3633"
+"ti,lm3695"
+"ti,lm3697"
+ - reg: I2C slave address.
+ 0x38 is LM3532
+ 0x29 is LM3631
+ 0x36 is LM3633, LM3697
+ 0x63 is LM3695
+ - ti,enable-gpio: GPIOs about hardware enable pin
+
+Sub-nodes:
+ Required sub-node:
+- backlight: Every TI LMU device has backlight sub-nodes. Please
refer to
+
Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
+
+ Optional sub-node:
+- regulators: Only for LM3631. Please refer to
+
Documentation/devicetree/bindings/regulator/lm3631-regulator.txt
+- leds: Only for LM3633. Please refer to
+Documentation/devicetree/bindings/leds/leds-lm3633.txt
+
+Examples:
+
+lm3532@38 {
+ compatible = "ti,lm3532";
+ reg = <0x38>;
+
+ /* GPIO134 for HWEN pin */
+ ti,enable-gpio = <&gpio5 6 GPIO_ACTIVE_HIGH>;
+
+ backlight {
+ compatible = "ti,lm3532-backlight", "ti,lmu-backlight";
+
+ lcd {
+ hvled1-used;
+ hvled2-used;
+ hvled3-used;
+
+ max-current-milliamp = /bits/ 8 <20>;
+ };
+ };
+};
+
+lm3631@29 {
+ compatible = "ti,lm3631";
+ reg = <0x29>;
+
+ ti,enable-gpio = <&gpio5 6 GPIO_ACTIVE_HIGH>;
+
+ regulators {
+ compatible = "ti,lm3631-regulator";
+
+ vboost {
+ regulator-name = "lcd_boost";
+ regulator-min-microvolt = <450>;
+ regulator-max-microvolt = <635>;
+ regulator-alway
Re: [PATCH -tip RESEND 2/2] ftrace: Introduce nr_saved_cmdlines I/F
Hi Yoshihiro,
On Mon, 17 Feb 2014 13:57:13 +0900, Yoshihiro YUNOMAE wrote:
> Hi Namhyung,
>
> (2014/02/14 13:50), Namhyung Kim wrote:
>> Hi Yoshihiro,
>>
>> On Thu, 13 Feb 2014 10:28:58 +0900, Yoshihiro YUNOMAE wrote:
>>> Introduce nr_saved_cmdlines I/F for changing the number of pid-comm list.
>>> saved_cmdlines can store 128 command names using SAVED_CMDLINES now, but
>>> 'no-existing processes' names are often lost in saved_cmdlines when we
>>> read trace data. So, by introducing nr_saved_cmdlines I/F, the rule storing
>>> 128 command names is changed to the command numbers defined users.
>>>
>>> When we write a value to nr_saved_cmdlines, the number of the value will
>>> be stored in pid-comm list:
>>>
>>> # echo 1024 > /sys/kernel/debug/tracing/nr_saved_cmdlines
>>>
>>> Here, 1024 command names are stored. The default number is 128 and the
>>> maximum
>>> number is PID_MAX_DEFAULT (=32768 if CONFIG_BASE_SMALL is not set). So, if
>>> we
>>> want to avoid to lose command names, we need to set 32768 to
>>> nr_saved_cmdlines.
>>>
>>> We can read the maximum number of the list:
>>>
>>> # cat /sys/kernel/debug/tracing/nr_saved_cmdlines
>>> 128
>>
>> [SNIP]
>>> @@ -3685,7 +3760,8 @@ static void *saved_cmdlines_next(struct seq_file *m,
>>> void *v, loff_t *pos)
>>>
>>> (*pos)++;
>>>
>>> - for (; ptr < &map_cmdline_to_pid[SAVED_CMDLINES]; ptr++) {
>>> + for (; ptr < &savedcmd->map_cmdline_to_pid[savedcmd->cmdline_num];
>>> +ptr++) {
>>> if (*ptr == -1 || *ptr == NO_CMDLINE_MAP)
>>> continue;
>>>
>>> @@ -3700,7 +3776,7 @@ static void *saved_cmdlines_start(struct seq_file *m,
>>> loff_t *pos)
>>> void *v;
>>> loff_t l = 0;
>>>
>>> - v = &map_cmdline_to_pid[0];
>>> + v = &savedcmd->map_cmdline_to_pid[0];
>>> while (l <= *pos) {
>>> v = saved_cmdlines_next(m, v, &l);
>>> if (!v)
>>
>> Are you accessing the savecmd without trace_cmdline_lock?
>
> It does not need to get trace_cmdline_lock here.
> The elements of map_pid_to_cmdline[] and saved_cmdlines[] are protected
> by trace_cmdline_lock in trace_find_cmdline(), but on the other hand
> map_cmdline_to_pid[] are not protected. There are no problems in
> particular. This is because map_cmdline_to_pid[] always refers to a
> valid process name or "<...>".
I don't get it. What does protect the savedcmd from being changed
during reading "saved_cmdlines" file with changing "nr_saved_cmdlines"?
Thanks,
Namhyung
--
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 10/11] powerpc/perf: add kconfig option for hypervisor provided counters
On Fri, 2014-02-14 at 16:25 -0800, Cody P Schafer wrote: > On Fri, Feb 14, 2014 at 04:32:13PM -0600, Scott Wood wrote: > > On Fri, 2014-02-14 at 14:02 -0800, Cody P Schafer wrote: > > > diff --git a/arch/powerpc/platforms/Kconfig.cputype > > > b/arch/powerpc/platforms/Kconfig.cputype > > > index 434fda3..dcc67cd 100644 > > > --- a/arch/powerpc/platforms/Kconfig.cputype > > > +++ b/arch/powerpc/platforms/Kconfig.cputype > > > @@ -364,6 +364,12 @@ config PPC_PERF_CTRS > > > help > > > This enables the powerpc-specific perf_event back-end. > > > > > > +config HV_PERF_CTRS > > > + def_bool y > > > + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT > > > + help > > > + Enable access to perf counters provided by the hypervisor > > > > Please don't add default-y stuff that is platform-specific, and > > definitely point out that platform dependency in the config description > > -- I have to look elsewhere in the patchset to determine that this is > > for "Power Hypervisor". PPC_HAVE_PMU_SUPPORT is enabled by all 6xx > > builds, even for hardware like e300 that doesn't have PMU at all (it has > > the FSL embedded perfmon instead), much less this hv interface. > > > > And yes, PPC_PERF_CTRS has the same problem and should be fixed. :-) > > Yep, I just based this one on what PPC_PERF_CTRS was doing. > > How about the following: > > +config HV_PERF_CTRS > + bool "Perf Hypervisor supplied counters" "Support for Hypervisor supplied PMU events (24x7 & GPCI)" ? > + default y > + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT && PPC_PSERIES I think you just want: depends on PERF_EVENTS && PPC_PSERIES Because you're adding two completely new PMUs, they're not a "struct power_pmu" backend for the existing powerpc PMU implementation. cheers -- 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: [linux-sunxi] [PATCH v6 4/8] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
Hi > > + * Driver for sunxi SD/MMC host controllers > > + * (C) Copyright 2014-2015 Reuuimlla Technology Co., Ltd. > > + * (C) Copyright 2014-2015 Aaron Maoye > > + * (C) Copyright 2014-2015 O2S GmbH > > + * (C) Copyright 2014-2015 David Lanzendörfer > > > > + * (C) Copyright 2014-2015 Hans de Goede > ETIMETRAVEL I'm not really into this licensing and copyright stuff. Could you maybe point out what the correct copyright would be? > __SUNXI_MMC_H__ Ok. Will fix that. > Also, you may want to rename SDXC_RESPONSE_* to SDXC_RESP_*, which looks > better next to the SDXC_DATA_* defines... Ok. I will change that :-) -david signature.asc Description: This is a digitally signed message part.
[PATCH v3] NFSv4.1: new layout stateid can not be overwrite by one out of date
If initiate_file_draining returned NFS4ERR_DELAY, all the lsegs of
a file might be released before the retrying cb_layout request arriving
at the client. In this situation,the list lo->plh_segs is empty,
layoutget request of the file will use open stateid to obtain a new
layout stateid. And if the retrying cb_layout request arrived at the
client after the layoutget reply, new layout stateid would be overwrite
by one out of date.
Signed-off-by: shaobingqing
---
fs/nfs/callback_proc.c |9 +++--
fs/nfs/pnfs.c |3 ++-
fs/nfs/pnfs.h |1 +
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c
index ae2e87b..5b20ace 100644
--- a/fs/nfs/callback_proc.c
+++ b/fs/nfs/callback_proc.c
@@ -170,10 +170,15 @@ static u32 initiate_file_draining(struct nfs_client *clp,
spin_lock(&ino->i_lock);
if (test_bit(NFS_LAYOUT_BULK_RECALL, &lo->plh_flags) ||
pnfs_mark_matching_lsegs_invalid(lo, &free_me_list,
- &args->cbl_range))
+ &args->cbl_range)) {
+ if (!test_and_set_bit(NFS_LAYOUT_BC_DELAY, &lo->plh_flags))
+ pnfs_get_layout_hdr(lo);
rv = NFS4ERR_DELAY;
- else
+ } else {
+ if (test_and_clear_bit(NFS_LAYOUT_BC_DELAY, &lo->plh_flags))
+ pnfs_put_layout_hdr(lo);
rv = NFS4ERR_NOMATCHING_LAYOUT;
+ }
pnfs_set_layout_stateid(lo, &args->cbl_stateid, true);
spin_unlock(&ino->i_lock);
pnfs_free_lseg_list(&free_me_list);
diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
index cb34024..998bc82 100644
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -721,7 +721,8 @@ pnfs_choose_layoutget_stateid(nfs4_stateid *dst, struct
pnfs_layout_hdr *lo,
status = -EAGAIN;
} else if (!nfs4_valid_open_stateid(open_state)) {
status = -EBADF;
- } else if (list_empty(&lo->plh_segs)) {
+ } else if (list_empty(&lo->plh_segs) &&
+ !test_bit(NFS_LAYOUT_BC_DELAY, &lo->plh_flags)) {
int seq;
do {
diff --git a/fs/nfs/pnfs.h b/fs/nfs/pnfs.h
index a4f4181..fb9b37e 100644
--- a/fs/nfs/pnfs.h
+++ b/fs/nfs/pnfs.h
@@ -63,6 +63,7 @@ enum {
NFS_LAYOUT_BULK_RECALL, /* bulk recall affecting layout */
NFS_LAYOUT_ROC, /* some lseg had roc bit set */
NFS_LAYOUT_RETURN, /* Return this layout ASAP */
+ NFS_LAYOUT_BC_DELAY,/*cb_layout are delayed*/
};
enum layoutdriver_policy_flags {
--
1.7.4.2
--
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] IA64, sba_iommu: fix section mismatch
Thanks for reminder, will send out v2.
On 2014/2/17 14:57, Yijing Wang wrote:
>> -static int __init
>> +static int
>> acpi_sba_ioc_add(struct acpi_device *device,
>> const struct acpi_device_id *not_used)
>> {
>>
>
> Hi Gerry,
>ioc_init() and sba_map_ioc_to_node() in this function seems also have the
> __init annotate.
>
>
--
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] ARM: mm: support big-endian page tables
When enable LPAE and big-endian in a hisilicon board, while specify
mem=384M mem=512M@7680M, will get bad page state:
Freeing unused kernel memory: 180K (c0466000 - c0493000)
BUG: Bad page state in process init pfn:fa442
page:c7749840 count:0 mapcount:-1 mapping: (null) index:0x0
page flags: 0x4400(reserved)
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 3.10.27+ #66
[] (unwind_backtrace+0x0/0x11c) from []
(show_stack+0x10/0x14)
[] (show_stack+0x10/0x14) from [] (bad_page+0xd4/0x104)
[] (bad_page+0xd4/0x104) from []
(free_pages_prepare+0xa8/0x14c)
[] (free_pages_prepare+0xa8/0x14c) from []
(free_hot_cold_page+0x18/0xf0)
[] (free_hot_cold_page+0x18/0xf0) from []
(handle_pte_fault+0xcf4/0xdc8)
[] (handle_pte_fault+0xcf4/0xdc8) from []
(handle_mm_fault+0xf4/0x120)
[] (handle_mm_fault+0xf4/0x120) from []
(do_page_fault+0xfc/0x354)
[] (do_page_fault+0xfc/0x354) from []
(do_DataAbort+0x2c/0x90)
[] (do_DataAbort+0x2c/0x90) from [] (__dabt_usr+0x34/0x40)
The bad pfn:fa442 is not system memory(mem=384M mem=512M@7680M), after
debugging,
I find in page fault handler, will get wrong pfn from pte just after set pte,
as follow:
do_anonymous_page()
{
...
set_pte_at(mm, address, page_table, entry);
//debug code
pfn = pte_pfn(entry);
pr_info("pfn:0x%lx, pte:0x%llx\n", pfn, pte_val(entry));
//read out the pte just set
new_pte = pte_offset_map(pmd, address);
new_pfn = pte_pfn(*new_pte);
pr_info("new pfn:0x%lx, new pte:0x%llx\n", pfn, pte_val(entry));
...
}
pfn: 0x1fa4f5, pte:0xc1fa4f575f
new_pfn:0xfa4f5, new_pte:0xc0fa4f5f5f //new pfn/pte is wrong.
The bug is happened in cpu_v7_set_pte_ext(ptep, pte):
when pte is 64-bit, for little-endian, will store low 32-bit in r2,
high 32-bit in r3; for big-endian, will store low 32-bit in r3,
high 32-bit in r2, this will cause wrong pfn stored in pte,
so we should exchange r2 and r3 for big-endian.
Signed-off-by: Jianguo Wu
---
arch/arm/mm/proc-v7-3level.S | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
index 01a719e..22e3ad6 100644
--- a/arch/arm/mm/proc-v7-3level.S
+++ b/arch/arm/mm/proc-v7-3level.S
@@ -64,6 +64,14 @@ ENTRY(cpu_v7_switch_mm)
mov pc, lr
ENDPROC(cpu_v7_switch_mm)
+#ifdef __ARMEB__
+#define rl r3
+#define rh r2
+#else
+#define rl r2
+#define rh r3
+#endif
+
/*
* cpu_v7_set_pte_ext(ptep, pte)
*
@@ -73,13 +81,13 @@ ENDPROC(cpu_v7_switch_mm)
*/
ENTRY(cpu_v7_set_pte_ext)
#ifdef CONFIG_MMU
- tst r2, #L_PTE_VALID
+ tst rl, #L_PTE_VALID
beq 1f
- tst r3, #1 << (57 - 32) @ L_PTE_NONE
- bicne r2, #L_PTE_VALID
+ tst rh, #1 << (57 - 32) @ L_PTE_NONE
+ bicne rl, #L_PTE_VALID
bne 1f
- tst r3, #1 << (55 - 32) @ L_PTE_DIRTY
- orreq r2, #L_PTE_RDONLY
+ tst rh, #1 << (55 - 32) @ L_PTE_DIRTY
+ orreq rl, #L_PTE_RDONLY
1: strdr2, r3, [r0]
ALT_SMP(W(nop))
ALT_UP (mcr p15, 0, r0, c7, c10, 1) @ flush_pte
--
1.7.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] IA64, sba_iommu: fix section mismatch
> -static int __init
> +static int
> acpi_sba_ioc_add(struct acpi_device *device,
>const struct acpi_device_id *not_used)
> {
>
Hi Gerry,
ioc_init() and sba_map_ioc_to_node() in this function seems also have the
__init annotate.
--
Thanks!
Yijing
--
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 2/5] PM / sleep: Asynchronous threads for resume_noirq
In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall resume_noirq time
significantly.
One typical case is:
In resume_noirq phase and for the PCI devices, the function
pci_pm_resume_noirq() will be called, and there is one d3_delay
(10ms) at least.
With the way of asynchronous threads, we just need wait d3_delay
time once in parallel for each calling, which saves much time to
resume quickly.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 66 +++
1 file changed, 50 insertions(+), 16 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 00c53eb..89172aa 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -469,7 +469,7 @@ static void dpm_watchdog_clear(struct dpm_watchdog *wd)
* The driver of @dev will not receive interrupts while this function is being
* executed.
*/
-static int device_resume_noirq(struct device *dev, pm_message_t state)
+static int device_resume_noirq(struct device *dev, pm_message_t state, bool
async)
{
pm_callback_t callback = NULL;
char *info = NULL;
@@ -481,6 +481,8 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
if (dev->power.syscore)
goto Out;
+ dpm_wait(dev->parent, async);
+
if (!dev->power.is_noirq_suspended)
goto Out;
@@ -507,10 +509,29 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
dev->power.is_noirq_suspended = false;
Out:
+ complete_all(&dev->power.completion);
TRACE_RESUME(error);
return error;
}
+static bool is_async(struct device *dev)
+{
+ return dev->power.async_suspend && pm_async_enabled
+ && !pm_trace_is_enabled();
+}
+
+static void async_resume_noirq(void *data, async_cookie_t cookie)
+{
+ struct device *dev = (struct device *)data;
+ int error;
+
+ error = device_resume_noirq(dev, pm_transition, true);
+ if (error)
+ pm_dev_err(dev, pm_transition, " async", error);
+
+ put_device(dev);
+}
+
/**
* dpm_resume_noirq - Execute "noirq resume" callbacks for all devices.
* @state: PM transition of the system being carried out.
@@ -520,29 +541,48 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
*/
static void dpm_resume_noirq(pm_message_t state)
{
+ struct device *dev;
ktime_t starttime = ktime_get();
mutex_lock(&dpm_list_mtx);
- while (!list_empty(&dpm_noirq_list)) {
- struct device *dev = to_device(dpm_noirq_list.next);
- int error;
+ pm_transition = state;
+
+ /*
+* Advanced the async threads upfront,
+* in case the starting of async threads is
+* delayed by non-async resuming devices.
+*/
+ list_for_each_entry(dev, &dpm_noirq_list, power.entry) {
+ reinit_completion(&dev->power.completion);
+ if (is_async(dev)) {
+ get_device(dev);
+ async_schedule(async_resume_noirq, dev);
+ }
+ }
+ while (!list_empty(&dpm_noirq_list)) {
+ dev = to_device(dpm_noirq_list.next);
get_device(dev);
list_move_tail(&dev->power.entry, &dpm_late_early_list);
mutex_unlock(&dpm_list_mtx);
- error = device_resume_noirq(dev, state);
- if (error) {
- suspend_stats.failed_resume_noirq++;
- dpm_save_failed_step(SUSPEND_RESUME_NOIRQ);
- dpm_save_failed_dev(dev_name(dev));
- pm_dev_err(dev, state, " noirq", error);
+ if (!is_async(dev)) {
+ int error;
+
+ error = device_resume_noirq(dev, state, false);
+ if (error) {
+ suspend_stats.failed_resume_noirq++;
+ dpm_save_failed_step(SUSPEND_RESUME_NOIRQ);
+ dpm_save_failed_dev(dev_name(dev));
+ pm_dev_err(dev, state, " noirq", error);
+ }
}
mutex_lock(&dpm_list_mtx);
put_device(dev);
}
mutex_unlock(&dpm_list_mtx);
+ async_synchronize_full();
dpm_show_time(starttime, state, "noirq");
resume_device_irqs();
cpuidle_resume();
@@ -742,12 +782,6 @@ static void async_resume(void *data, async_cookie_t cookie)
put_device(dev);
}
-static bool is_async(struct device *dev)
-{
- return dev->power.async_suspend && pm_async_enabled
- && !pm_trace_is_enabled();
-}
-
/**
* dpm_resume - Execute "resume" callbacks for non-sysdev devices.
* @state: PM transition of the system being carried out.
--
1.9.rc0
--
To un
[PATCH v3 5/5] PM / sleep: Asynchronous threads for suspend_late
In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall suspend_late
time significantly.
This patch is for suspend_late phase.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 66 ++-
1 file changed, 54 insertions(+), 12 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 72b4c9c..c031050 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1127,16 +1127,26 @@ static int dpm_suspend_noirq(pm_message_t state)
*
* Runtime PM is disabled for @dev while this function is being executed.
*/
-static int device_suspend_late(struct device *dev, pm_message_t state)
+static int __device_suspend_late(struct device *dev, pm_message_t state, bool
async)
{
pm_callback_t callback = NULL;
char *info = NULL;
- int error;
+ int error = 0;
+
+ dpm_wait_for_children(dev, async);
__pm_runtime_disable(dev, false);
+ if (async_error)
+ goto Complete;
+
+ if (pm_wakeup_pending()) {
+ async_error = -EBUSY;
+ goto Complete;
+ }
+
if (dev->power.syscore)
- return 0;
+ goto Complete;
if (dev->pm_domain) {
info = "late power domain ";
@@ -1160,10 +1170,40 @@ static int device_suspend_late(struct device *dev,
pm_message_t state)
error = dpm_run_callback(callback, dev, state, info);
if (!error)
dev->power.is_late_suspended = true;
+ else
+ async_error = error;
+Complete:
+ complete_all(&dev->power.completion);
return error;
}
+static void async_suspend_late(void *data, async_cookie_t cookie)
+{
+ struct device *dev = (struct device *)data;
+ int error;
+
+ error = __device_suspend_late(dev, pm_transition, true);
+ if (error) {
+ dpm_save_failed_dev(dev_name(dev));
+ pm_dev_err(dev, pm_transition, " async", error);
+ }
+ put_device(dev);
+}
+
+static int device_suspend_late(struct device *dev)
+{
+ reinit_completion(&dev->power.completion);
+
+ if (pm_async_enabled && dev->power.async_suspend) {
+ get_device(dev);
+ async_schedule(async_suspend_late, dev);
+ return 0;
+ }
+
+ return __device_suspend_late(dev, pm_transition, false);
+}
+
/**
* dpm_suspend_late - Execute "late suspend" callbacks for all devices.
* @state: PM transition of the system being carried out.
@@ -1174,19 +1214,20 @@ static int dpm_suspend_late(pm_message_t state)
int error = 0;
mutex_lock(&dpm_list_mtx);
+ pm_transition = state;
+ async_error = 0;
+
while (!list_empty(&dpm_suspended_list)) {
struct device *dev = to_device(dpm_suspended_list.prev);
get_device(dev);
mutex_unlock(&dpm_list_mtx);
- error = device_suspend_late(dev, state);
+ error = device_suspend_late(dev);
mutex_lock(&dpm_list_mtx);
if (error) {
pm_dev_err(dev, state, " late", error);
- suspend_stats.failed_suspend_late++;
- dpm_save_failed_step(SUSPEND_SUSPEND_LATE);
dpm_save_failed_dev(dev_name(dev));
put_device(dev);
break;
@@ -1195,17 +1236,18 @@ static int dpm_suspend_late(pm_message_t state)
list_move(&dev->power.entry, &dpm_late_early_list);
put_device(dev);
- if (pm_wakeup_pending()) {
- error = -EBUSY;
+ if (async_error)
break;
- }
}
mutex_unlock(&dpm_list_mtx);
- if (error)
+ async_synchronize_full();
+ if (error) {
+ suspend_stats.failed_suspend_late++;
+ dpm_save_failed_step(SUSPEND_SUSPEND_LATE);
dpm_resume_early(resume_event(state));
- else
+ } else {
dpm_show_time(starttime, state, "late");
-
+ }
return error;
}
--
1.9.rc0
--
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/5] PM / sleep: Asynchronous threads for resume_early
In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall resume_early
time significantly.
This patch is for resume_early phase.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 55 +--
1 file changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 89172aa..2f2d110 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -595,7 +595,7 @@ static void dpm_resume_noirq(pm_message_t state)
*
* Runtime PM is disabled for @dev while this function is being executed.
*/
-static int device_resume_early(struct device *dev, pm_message_t state)
+static int device_resume_early(struct device *dev, pm_message_t state, bool
async)
{
pm_callback_t callback = NULL;
char *info = NULL;
@@ -607,6 +607,8 @@ static int device_resume_early(struct device *dev,
pm_message_t state)
if (dev->power.syscore)
goto Out;
+ dpm_wait(dev->parent, async);
+
if (!dev->power.is_late_suspended)
goto Out;
@@ -636,38 +638,69 @@ static int device_resume_early(struct device *dev,
pm_message_t state)
TRACE_RESUME(error);
pm_runtime_enable(dev);
+ complete_all(&dev->power.completion);
return error;
}
+static void async_resume_early(void *data, async_cookie_t cookie)
+{
+ struct device *dev = (struct device *)data;
+ int error;
+
+ error = device_resume_early(dev, pm_transition, true);
+ if (error)
+ pm_dev_err(dev, pm_transition, " async", error);
+
+ put_device(dev);
+}
+
/**
* dpm_resume_early - Execute "early resume" callbacks for all devices.
* @state: PM transition of the system being carried out.
*/
static void dpm_resume_early(pm_message_t state)
{
+ struct device *dev;
ktime_t starttime = ktime_get();
mutex_lock(&dpm_list_mtx);
- while (!list_empty(&dpm_late_early_list)) {
- struct device *dev = to_device(dpm_late_early_list.next);
- int error;
+ pm_transition = state;
+
+ /*
+* Advanced the async threads upfront,
+* in case the starting of async threads is
+* delayed by non-async resuming devices.
+*/
+ list_for_each_entry(dev, &dpm_late_early_list, power.entry) {
+ reinit_completion(&dev->power.completion);
+ if (is_async(dev)) {
+ get_device(dev);
+ async_schedule(async_resume_early, dev);
+ }
+ }
+ while (!list_empty(&dpm_late_early_list)) {
+ dev = to_device(dpm_late_early_list.next);
get_device(dev);
list_move_tail(&dev->power.entry, &dpm_suspended_list);
mutex_unlock(&dpm_list_mtx);
- error = device_resume_early(dev, state);
- if (error) {
- suspend_stats.failed_resume_early++;
- dpm_save_failed_step(SUSPEND_RESUME_EARLY);
- dpm_save_failed_dev(dev_name(dev));
- pm_dev_err(dev, state, " early", error);
- }
+ if (!is_async(dev)) {
+ int error;
+ error = device_resume_early(dev, state, false);
+ if (error) {
+ suspend_stats.failed_resume_early++;
+ dpm_save_failed_step(SUSPEND_RESUME_EARLY);
+ dpm_save_failed_dev(dev_name(dev));
+ pm_dev_err(dev, state, " early", error);
+ }
+ }
mutex_lock(&dpm_list_mtx);
put_device(dev);
}
mutex_unlock(&dpm_list_mtx);
+ async_synchronize_full();
dpm_show_time(starttime, state, "early");
}
--
1.9.rc0
--
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 1/5] PM / sleep: Two flags for async suspend_noirq and suspend_late
The patch is a helper adding two new flags for implementing
async threads for suspend_noirq and suspend_late.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 24 ++--
include/linux/pm.h| 2 ++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 1b41fca..00c53eb 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -91,6 +91,8 @@ void device_pm_sleep_init(struct device *dev)
{
dev->power.is_prepared = false;
dev->power.is_suspended = false;
+ dev->power.is_noirq_suspended = false;
+ dev->power.is_late_suspended = false;
init_completion(&dev->power.completion);
complete_all(&dev->power.completion);
dev->power.wakeup = NULL;
@@ -479,6 +481,9 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
if (dev->power.syscore)
goto Out;
+ if (!dev->power.is_noirq_suspended)
+ goto Out;
+
if (dev->pm_domain) {
info = "noirq power domain ";
callback = pm_noirq_op(&dev->pm_domain->ops, state);
@@ -499,6 +504,7 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
}
error = dpm_run_callback(callback, dev, state, info);
+ dev->power.is_noirq_suspended = false;
Out:
TRACE_RESUME(error);
@@ -561,6 +567,9 @@ static int device_resume_early(struct device *dev,
pm_message_t state)
if (dev->power.syscore)
goto Out;
+ if (!dev->power.is_late_suspended)
+ goto Out;
+
if (dev->pm_domain) {
info = "early power domain ";
callback = pm_late_early_op(&dev->pm_domain->ops, state);
@@ -581,6 +590,7 @@ static int device_resume_early(struct device *dev,
pm_message_t state)
}
error = dpm_run_callback(callback, dev, state, info);
+ dev->power.is_late_suspended = false;
Out:
TRACE_RESUME(error);
@@ -917,6 +927,7 @@ static int device_suspend_noirq(struct device *dev,
pm_message_t state)
{
pm_callback_t callback = NULL;
char *info = NULL;
+ int error;
if (dev->power.syscore)
return 0;
@@ -940,7 +951,11 @@ static int device_suspend_noirq(struct device *dev,
pm_message_t state)
callback = pm_noirq_op(dev->driver->pm, state);
}
- return dpm_run_callback(callback, dev, state, info);
+ error = dpm_run_callback(callback, dev, state, info);
+ if (!error)
+ dev->power.is_noirq_suspended = true;
+
+ return error;
}
/**
@@ -1003,6 +1018,7 @@ static int device_suspend_late(struct device *dev,
pm_message_t state)
{
pm_callback_t callback = NULL;
char *info = NULL;
+ int error;
__pm_runtime_disable(dev, false);
@@ -1028,7 +1044,11 @@ static int device_suspend_late(struct device *dev,
pm_message_t state)
callback = pm_late_early_op(dev->driver->pm, state);
}
- return dpm_run_callback(callback, dev, state, info);
+ error = dpm_run_callback(callback, dev, state, info);
+ if (!error)
+ dev->power.is_late_suspended = true;
+
+ return error;
}
/**
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 8c6583a..f23a4f1 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -542,6 +542,8 @@ struct dev_pm_info {
unsigned intasync_suspend:1;
boolis_prepared:1; /* Owned by the PM core */
boolis_suspended:1; /* Ditto */
+ boolis_noirq_suspended:1;
+ boolis_late_suspended:1;
boolignore_children:1;
boolearly_init:1; /* Owned by the PM core */
spinlock_t lock;
--
1.9.rc0
--
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 4/5] PM / sleep: Asynchronous threads for suspend_noirq
In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall suspend_noirq
time significantly.
This patch is for suspend_noirq phase.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 68 +++
1 file changed, 57 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 2f2d110..72b4c9c 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -990,14 +990,24 @@ static pm_message_t resume_event(pm_message_t sleep_state)
* The driver of @dev will not receive interrupts while this function is being
* executed.
*/
-static int device_suspend_noirq(struct device *dev, pm_message_t state)
+static int __device_suspend_noirq(struct device *dev, pm_message_t state, bool
async)
{
pm_callback_t callback = NULL;
char *info = NULL;
- int error;
+ int error = 0;
+
+ dpm_wait_for_children(dev, async);
+
+ if (async_error)
+ goto Complete;
+
+ if (pm_wakeup_pending()) {
+ async_error = -EBUSY;
+ goto Complete;
+ }
if (dev->power.syscore)
- return 0;
+ goto Complete;
if (dev->pm_domain) {
info = "noirq power domain ";
@@ -1021,10 +1031,40 @@ static int device_suspend_noirq(struct device *dev,
pm_message_t state)
error = dpm_run_callback(callback, dev, state, info);
if (!error)
dev->power.is_noirq_suspended = true;
+ else
+ async_error = error;
+Complete:
+ complete_all(&dev->power.completion);
return error;
}
+static void async_suspend_noirq(void *data, async_cookie_t cookie)
+{
+ struct device *dev = (struct device *)data;
+ int error;
+
+ error = __device_suspend_noirq(dev, pm_transition, true);
+ if (error) {
+ dpm_save_failed_dev(dev_name(dev));
+ pm_dev_err(dev, pm_transition, " async", error);
+ }
+
+ put_device(dev);
+}
+
+static int device_suspend_noirq(struct device *dev)
+{
+ reinit_completion(&dev->power.completion);
+
+ if (pm_async_enabled && dev->power.async_suspend) {
+ get_device(dev);
+ async_schedule(async_suspend_noirq, dev);
+ return 0;
+ }
+ return __device_suspend_noirq(dev, pm_transition, false);
+}
+
/**
* dpm_suspend_noirq - Execute "noirq suspend" callbacks for all devices.
* @state: PM transition of the system being carried out.
@@ -1040,19 +1080,20 @@ static int dpm_suspend_noirq(pm_message_t state)
cpuidle_pause();
suspend_device_irqs();
mutex_lock(&dpm_list_mtx);
+ pm_transition = state;
+ async_error = 0;
+
while (!list_empty(&dpm_late_early_list)) {
struct device *dev = to_device(dpm_late_early_list.prev);
get_device(dev);
mutex_unlock(&dpm_list_mtx);
- error = device_suspend_noirq(dev, state);
+ error = device_suspend_noirq(dev);
mutex_lock(&dpm_list_mtx);
if (error) {
pm_dev_err(dev, state, " noirq", error);
- suspend_stats.failed_suspend_noirq++;
- dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
dpm_save_failed_dev(dev_name(dev));
put_device(dev);
break;
@@ -1061,16 +1102,21 @@ static int dpm_suspend_noirq(pm_message_t state)
list_move(&dev->power.entry, &dpm_noirq_list);
put_device(dev);
- if (pm_wakeup_pending()) {
- error = -EBUSY;
+ if (async_error)
break;
- }
}
mutex_unlock(&dpm_list_mtx);
- if (error)
+ async_synchronize_full();
+ if (!error)
+ error = async_error;
+
+ if (error) {
+ suspend_stats.failed_suspend_noirq++;
+ dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
dpm_resume_noirq(resume_event(state));
- else
+ } else {
dpm_show_time(starttime, state, "noirq");
+ }
return error;
}
--
1.9.rc0
--
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 0/5] Enabling the asynchronous threads for other phases
Hello, This patch series are for enabling the asynchronous threads for the phases resume_noirq, resume_early, suspend_noirq and suspend_late. Just like commit 5af84b82701a and 97df8c12995, with async threads it will reduce the system suspending and resuming time significantly. With these patches, in my test platform, it saved 80% time in resume_noirq phase. Best Regards, --- V2: -- Based on Rafael's minor changes related to coding style, white space etc; -- Rafael pointed out the v1 series break the device parent-children suspending/resuming order when enabling asyncing, here using the dev completion to sync parent-children order; V3: -- In patch v2 5/5, there is one missing "dpm_wait_for_children"; --- [PATCH v3 1/5] PM / sleep: Two flags for async suspend_noirq and [PATCH v3 2/5] PM / sleep: Asynchronous threads for resume_noirq [PATCH v3 3/5] PM / sleep: Asynchronous threads for resume_early [PATCH v3 4/5] PM / sleep: Asynchronous threads for suspend_noirq [PATCH v3 5/5] PM / sleep: Asynchronous threads for suspend_late drivers/base/power/main.c | 275 ++ include/linux/pm.h| 2 ++ 2 files changed, 227 insertions(+), 50 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 9/9] slab: remove a useless lockdep annotation
On Fri, Feb 14, 2014 at 12:49:57PM -0600, Christoph Lameter wrote:
> On Fri, 14 Feb 2014, Joonsoo Kim wrote:
>
> > @@ -921,7 +784,7 @@ static int transfer_objects(struct array_cache *to,
> > static inline struct alien_cache **alloc_alien_cache(int node,
> > int limit, gfp_t gfp)
> > {
> > - return (struct alien_cache **)BAD_ALIEN_MAGIC;
> > + return NULL;
> > }
> >
>
> Why change the BAD_ALIEN_MAGIC?
Hello, Christoph.
BAD_ALIEN_MAGIC is only checked by slab_set_lock_classes(). We remove this
function in this patch, so returning BAD_ALIEN_MAGIC is useless.
And, in fact, BAD_ALIEN_MAGIC is already useless, because alloc_alien_cache()
can't be called on !CONFIG_NUMA. This function is called if use_alien_caches
is positive, but on !CONFIG_NUMA, use_alien_caches is always 0. So we don't
have any chance to meet this BAD_ALIEN_MAGIC in runtime.
Thanks.
--
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 Feb 17
Hi all,
If you see failures in building this tree due to missing declarations of
k..alloc/free, then it may be caused by commit 2bd59d48ebfb ("cgroup:
convert to kernfs"). Please send Tejun Heo a patch
adding an inclusion of linux/slab.h to the appropriate file(s).
This tree fails (more than usual) the powerpc allyesconfig build.
Changes since 20140214:
The powerpc tree still had its build failure.
The libata tree gained a conflict aaginst Linus' tree.
The mfd-lj tree still had its build failure so I used the version from
next-20140210.
Non-merge commits (relative to Linus' tree): 2845
3245 files changed, 101137 insertions(+), 51870 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" as mentioned in the FAQ on the wiki
(see below).
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 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
I am currently merging 208 trees (counting Linus' and 28 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.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (6d0abeca3242 Linux 3.14-rc3)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (b027df048500 ARM: 7957/1: add DSB after icache flush
in __flush_icache_all())
Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and
sched_getattr)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (cd15b048445d powerpc/powernv: Add iommu DMA bypass
support for IODA2)
Merging sparc/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of
git://git.monstr.eu/linux-2.6-microblaze)
Merging net/master (eb2d4c64879c net,bonding: fix bond_options.c direct
rwlock.h include)
Merging ipsec/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of
git://git.monstr.eu/linux-2.6-microblaze)
Merging sound-current/for-linus (2078600b1f8f ALSA: Revert "ALSA: hda/realtek -
Avoid invalid COEFs for ALC271X")
Merging pci-current/for-linus (fc40363b2140 ahci: Fix broken fallback to single
MSI mode)
Merging wireless/master (4885c8731a34 hostap: fix "hostap: proc: Use
remove_proc_subtree()")
Merging driver-core.current/driver-core-linus (9e1ccb4a7700 drivers/base: fix
devres handling for master device)
Merging tty.current/tty-linus (0930b0950a89 vt: Fix secure clear screen)
Merging usb.current/usb-linus (3635c7e2d59f usb: option: blacklist ZTE MF667
net interface)
Merging staging.current/staging-linus (ddf5eb564d97 staging/rtl8821ae: fix
build, depends on MAC80211)
Merging char-misc.current/char-misc-linus (bf7471038840 Revert "misc: eeprom:
sunxi: Add new compatibles")
Merging input-current/for-linus (910a9f5636f5 Input: adp5588-keys - get value
from data out when dir is out)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard"
stripe)
Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede
ctr concurrency issue)
Merging ide/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of
git://git.monstr.eu/linux-2.6-microblaze)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (6f041e99fc7b of: Fix NULL
dereference in unflatten_and_copy())
Merging rr-fixes/fixes (
Re: [PATCH 3/9] slab: move up code to get kmem_cache_node in free_block()
On Fri, Feb 14, 2014 at 03:19:02PM -0800, David Rientjes wrote: > On Fri, 14 Feb 2014, Joonsoo Kim wrote: > > > node isn't changed, so we don't need to retreive this structure > > everytime we move the object. Maybe compiler do this optimization, > > but making it explicitly is better. > > > > Would it be possible to make it const struct kmem_cache_node *n then? Hello, David. Yes, it is possible. If I send v2, I will change it. Thanks. -- 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] user_namespace.c: Remove duplicated word in comment
Signed-off-by: Brian Campbell --- kernel/user_namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c index 240fb62..dd06439 100644 --- a/kernel/user_namespace.c +++ b/kernel/user_namespace.c @@ -225,7 +225,7 @@ static u32 map_id_up(struct uid_gid_map *map, u32 id) * * When there is no mapping defined for the user-namespace uid * pair INVALID_UID is returned. Callers are expected to test - * for and handle handle INVALID_UID being returned. INVALID_UID + * for and handle INVALID_UID being returned. INVALID_UID * may be tested for using uid_valid(). */ kuid_t make_kuid(struct user_namespace *ns, uid_t uid) -- 1.8.5.3 -- 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] drm/nouveau: support for platform devices
Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead
of PCI to which Nouveau is tightly dependent. This patch allows Nouveau
to handle platform devices by:
- abstracting PCI-dependent functions that were typically used for
resource querying and page mapping,
- introducing a nv_device_is_pci() function that allows to make
PCI-dependent code conditional,
- providing a nouveau_drm_platform_probe() function that takes a GPU
platform device to be probed.
Core code as well as engine/subdev drivers are updated wherever possible
to make use of these functions. Some older drivers are too dependent on
PCI to be properly updated, but all newer code on which future chips may
depend should at least be runnable with platform devices.
Signed-off-by: Alexandre Courbot
---
Changes since v2:
- Moved MSI code under PCI-conditioned blocks in mc/base.c, as suggested by
Emil Velikov. This makes more sense with respect to how MSI is used and
allows us to get rid of a couple extra conditional statements.
drivers/gpu/drm/nouveau/core/engine/device/base.c | 83 --
drivers/gpu/drm/nouveau/core/engine/falcon.c | 6 +-
drivers/gpu/drm/nouveau/core/engine/fifo/base.c| 2 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv20.c | 2 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv40.c | 2 +-
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 +-
drivers/gpu/drm/nouveau/core/engine/xtensa.c | 2 +-
drivers/gpu/drm/nouveau/core/include/core/device.h | 30
.../gpu/drm/nouveau/core/include/engine/device.h | 17 +++--
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/os.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 4 +-
drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c | 4 +-
drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 15 ++--
.../gpu/drm/nouveau/core/subdev/devinit/fbmem.h| 8 ++-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv04.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv05.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv10.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv20.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c | 9 +--
drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 9 +--
drivers/gpu/drm/nouveau/core/subdev/i2c/base.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c | 7 +-
drivers/gpu/drm/nouveau/core/subdev/mc/base.c | 55 --
drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c| 13 +++-
drivers/gpu/drm/nouveau/nouveau_agp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bios.c | 4 ++
drivers/gpu/drm/nouveau/nouveau_bo.c | 22 +++---
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 3 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 59 ---
drivers/gpu/drm/nouveau/nouveau_sysfs.c| 8 ++-
drivers/gpu/drm/nouveau/nouveau_ttm.c | 31
drivers/gpu/drm/nouveau/nouveau_vga.c | 5 ++
35 files changed, 306 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c
b/drivers/gpu/drm/nouveau/core/engine/device/base.c
index dd01c6c435d6..8a8f5f2d0eb5 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/base.c
@@ -131,8 +131,8 @@ nouveau_devobj_ctor(struct nouveau_object *parent,
if (ret)
return ret;
- mmio_base = pci_resource_start(device->pdev, 0);
- mmio_size = pci_resource_len(device->pdev, 0);
+ mmio_base = nv_device_resource_start(device, 0);
+ mmio_size = nv_device_resource_len(device, 0);
/* translate api disable mask into internal mapping */
disable = args->debug0;
@@ -446,6 +446,72 @@ nouveau_device_dtor(struct nouveau_object *object)
nouveau_engine_destroy(&device->base);
}
+resource_size_t
+nv_device_resource_start(struct nouveau_device *device, unsigned int bar)
+{
+ if (nv_device_is_pci(device)) {
+ return pci_resource_start(device->pdev, bar);
+ } else {
+ struct resource *res;
+ res = platform_get_resource(device->platformdev,
+ IORESOURCE_MEM, bar);
+ if (!res)
+ return 0;
+ return res->start;
+ }
+}
+
+resource_size_t
+nv_device_resource_len(struct nouveau_device *device, unsigned int bar)
+{
+ if (nv_device_is_pci(device)) {
+ return pci_resource_len(device->pdev, bar);
+ } else {
+ struct resource *res;
+ res = platform_get_resource(device->platformdev,
+ IORESOURCE_MEM, bar);
+ if (!res)
+
Re: [PATCH 2/9] slab: makes clear_obj_pfmemalloc() just return store masked value
On Fri, Feb 14, 2014 at 06:26:15PM -0600, Christoph Lameter wrote: > On Fri, 14 Feb 2014, David Rientjes wrote: > > > Yeah, you don't need it, but don't you think it makes the code more > > readable? Otherwise this is going to be just doing > > > > return (unsigned long)objp & ~SLAB_OBJ_PFMEMALLOC; > > > > and you gotta figure out the function type to understand it's returned as > > Isnt there something like PTR_ALIGN() for this case that would make it > more readable? I can't find what you want. I agree with David's opinion and want to keep patch as is. Thanks. -- 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: [PATCHv3] Generic Mailbox API
On Mon, Feb 17, 2014 at 11:33 AM, Craig McGeachie wrote: > On 16/02/14 07:22, Jassi Brar wrote: >> >> Hello, >> >>Here is what the generic mailbox api looks like after modifications >> to make it work with 5 different platforms. >> Major feedback from Suman Anna(TI), LeyFoon Tan(Intel), >> Craig McGeachie(Broadcom) and Loic Pallardy(ST). >> >> Signed-off-by: Jassi Brar >> > > Um, sorry for not having included this in the previous email. I've just > looked over the patch set and I don't believe it contains anything that I > did, so I don't think my name is appropriate here at all. > I did not assign you copyright/ownership of any code. The patches say who did what. I just mentioned on the record that I got very useful feedback from these guys to improve the api. I do not 'accuse' you of writing any code ;) but I am thankful that you in a way tested the api by writing a driver for it. Thanks, Jassi -- 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: [PATCHv3] Generic Mailbox API
On 16/02/14 07:22, Jassi Brar wrote: Hello, Here is what the generic mailbox api looks like after modifications to make it work with 5 different platforms. Major feedback from Suman Anna(TI), LeyFoon Tan(Intel), Craig McGeachie(Broadcom) and Loic Pallardy(ST). Signed-off-by: Jassi Brar Um, sorry for not having included this in the previous email. I've just looked over the patch set and I don't believe it contains anything that I did, so I don't think my name is appropriate here at all. Cheers, Craig. -- 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/3] mfd: Add realtek USB card reader driver
On 02/14/2014 05:44 PM, Lee Jones wrote: On Wed, 12 Feb 2014, rogera...@realtek.com wrote: From: Roger Tseng Realtek USB card reader provides a channel to transfer command or data to flash memory cards. This driver exports host instances for mmc and memstick subsystems and handles basic works. Signed-off-by: Roger Tseng --- drivers/mfd/Kconfig | 10 + drivers/mfd/Makefile | 1 + drivers/mfd/rtsx_usb.c | 760 +++ include/linux/mfd/rtsx_usb.h | 628 +++ 4 files changed, 1399 insertions(+) create mode 100644 drivers/mfd/rtsx_usb.c create mode 100644 include/linux/mfd/rtsx_usb.h Applied again, thanks. Would you also apply patch 2/3 and 3/3 that to make the device fully operational for users? Or should they be applied by maintainers of mmc/memstick subsystems? Chris, would you give some comment? -- 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 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()
On 15 February 2014 01:12, Stephen Warren wrote:
> On 02/12/2014 11:50 PM, Viresh Kumar wrote:
>> This patchset creates/calls cpufreq suspend/resume callbacks from
>> dpm_{suspend|resume}()
>> for handling suspend/resume of cpufreq governors and core.
>
> Are these patches for 3.14 or 3.15?
3.15
> I ask because I just tested Linus's master from a few days back (some
> point after v3.14-rc2; commit 9398a10cd964 Merge tag
> 'regulator-v3.14-rc2'), and I see a lot of the following messages during
> suspend and/or resume (about 2-7 times, perhaps more of them from the
> resume path, but it's hard to tell):
>
> cpufreq: __cpufreq_driver_target: Failed to change cpu frequency: -16
That's because you return -EBUSY from your tegra_cpu_init() once
suspend/resume has started. Probably the print message is new here,
and so you are able to see it failing.. Nothing else should have changed
otherwise.
> This series does appear to solve those, so I think at least part of it
> needs to be applied for 3.14.
Because we disallow calls to __cpufreq_driver_target() after suspend/
resume have started.
> Also, I sometimes see the following during resume. I saw it twice with
> Linus's tree, but then I did 10 more reboot+suspend+resume cycles and
> couldn't repro it, and I saw it once with Linus's tree plus this series
> applied, then couldn't reproduce it in 5 more tries.
> Do you have any idea what the problem might be, and how to solve it?
Not yet, will check..
--
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: [PATCHv3] Generic Mailbox API
On 16/02/14 07:22, Jassi Brar wrote: Hello, Here is what the generic mailbox api looks like after modifications to make it work with 5 different platforms. Major feedback from Suman Anna(TI), LeyFoon Tan(Intel), Craig McGeachie(Broadcom) and Loic Pallardy(ST). Signed-off-by: Jassi Brar Important point of clarification. I don't work for Broadcom. I have no current or past affiliation with Broadcom. I was fairly certain that I'd given no indication that I did. I'm just some guy who purchased a single board computer based on one of their products. I do work for an IT company, but that isn't relevant to what I do after hours on my own time. Cheers, Craig. -- 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 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()
On 15 February 2014 01:52, Stephen Warren wrote:
> BTW, I also happened to test these on a Tegra114 system, on which there
> is no cpufreq driver, and this series (applied on top of commit
> 9398a10cd964 Merge tag 'regulator-v3.14-rc2') causes the following
> during suspend:
Ahh, that's a obvious bug. Following would fix it, thanks:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index c13c100..2dfbb7e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1617,6 +1617,9 @@ void cpufreq_suspend(void)
{
struct cpufreq_policy *policy;
+ if (!cpufreq_driver)
+ return;
+
if (!has_target())
return;
@@ -1645,6 +1648,9 @@ void cpufreq_resume(void)
{
struct cpufreq_policy *policy;
+ if (!cpufreq_driver)
+ return;
+
if (!has_target())
return;
--
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: [PATCHv3] Generic Mailbox API
On 17 February 2014 11:27, Craig McGeachie wrote: > On 16/02/14 07:22, Jassi Brar wrote: >> >> Hello, >> >>Here is what the generic mailbox api looks like after modifications >> to make it work with 5 different platforms. >> Major feedback from Suman Anna(TI), LeyFoon Tan(Intel), >> Craig McGeachie(Broadcom) and Loic Pallardy(ST). >> >> Signed-off-by: Jassi Brar >> > > Important point of clarification. I don't work for Broadcom. I have no > current or past affiliation with Broadcom. I was fairly certain that I'd > given no indication that I did. I'm just some guy who purchased a single > board computer based on one of their products. I do work for an IT company, > but that isn't relevant to what I do after hours on my own time. > I saw the Broadcom driver being worked upon by you and assumed you either work for or on contract with Broadcom. It doesn't matter much anyways by virtue of the beauty of open-source :) So you still have a say on the mailbox code. Thanks Jassi -- 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] IA64: fix warning in make defconfig
Now the ACPI container and ACPI PCI hotplug driver has been converted as built-in modules, so reflect these changes in IA64 defconfig file. Signed-off-by: Jiang Liu --- arch/ia64/configs/generic_defconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/ia64/configs/generic_defconfig b/arch/ia64/configs/generic_defconfig index efbd292..6404acb 100644 --- a/arch/ia64/configs/generic_defconfig +++ b/arch/ia64/configs/generic_defconfig @@ -30,9 +30,9 @@ CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=m CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=m -CONFIG_ACPI_CONTAINER=m +CONFIG_ACPI_CONTAINER=y CONFIG_HOTPLUG_PCI=y -CONFIG_HOTPLUG_PCI_ACPI=m +CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y -- 1.7.10.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/
[PATCH] IA64, sba_iommu: fix section mismatch
Fix the section mismatch warning by remove __init annotate for function
acpi_sba_ioc_add() because it may be called at runtime.
WARNING: vmlinux.o(.data+0x66ee0): Section mismatch in reference from the
variable acpi_sba_ioc_handler to the function .init.text:acpi_sba_ioc_add()
The variable acpi_sba_ioc_handler references
the function __init acpi_sba_ioc_add()
Signed-off-by: Jiang Liu
---
arch/ia64/hp/common/sba_iommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 8e858b5..c9d6f0b 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -2041,7 +2041,7 @@ sba_map_ioc_to_node(struct ioc *ioc, acpi_handle handle)
#define sba_map_ioc_to_node(ioc, handle)
#endif
-static int __init
+static int
acpi_sba_ioc_add(struct acpi_device *device,
const struct acpi_device_id *not_used)
{
--
1.7.10.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/
[PATCH v2 5/5] PM / sleep: Asynchronous threads for suspend_late
In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall suspend_late
time significantly.
This patch is for suspend_late phase.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 64 ++-
1 file changed, 52 insertions(+), 12 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 72b4c9c..0c5fad0 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1127,16 +1127,24 @@ static int dpm_suspend_noirq(pm_message_t state)
*
* Runtime PM is disabled for @dev while this function is being executed.
*/
-static int device_suspend_late(struct device *dev, pm_message_t state)
+static int __device_suspend_late(struct device *dev, pm_message_t state, bool
async)
{
pm_callback_t callback = NULL;
char *info = NULL;
- int error;
+ int error = 0;
__pm_runtime_disable(dev, false);
+ if (async_error)
+ goto Complete;
+
+ if (pm_wakeup_pending()) {
+ async_error = -EBUSY;
+ goto Complete;
+ }
+
if (dev->power.syscore)
- return 0;
+ goto Complete;
if (dev->pm_domain) {
info = "late power domain ";
@@ -1160,10 +1168,40 @@ static int device_suspend_late(struct device *dev,
pm_message_t state)
error = dpm_run_callback(callback, dev, state, info);
if (!error)
dev->power.is_late_suspended = true;
+ else
+ async_error = error;
+Complete:
+ complete_all(&dev->power.completion);
return error;
}
+static void async_suspend_late(void *data, async_cookie_t cookie)
+{
+ struct device *dev = (struct device *)data;
+ int error;
+
+ error = __device_suspend_late(dev, pm_transition, true);
+ if (error) {
+ dpm_save_failed_dev(dev_name(dev));
+ pm_dev_err(dev, pm_transition, " async", error);
+ }
+ put_device(dev);
+}
+
+static int device_suspend_late(struct device *dev)
+{
+ reinit_completion(&dev->power.completion);
+
+ if (pm_async_enabled && dev->power.async_suspend) {
+ get_device(dev);
+ async_schedule(async_suspend_late, dev);
+ return 0;
+ }
+
+ return __device_suspend_late(dev, pm_transition, false);
+}
+
/**
* dpm_suspend_late - Execute "late suspend" callbacks for all devices.
* @state: PM transition of the system being carried out.
@@ -1174,19 +1212,20 @@ static int dpm_suspend_late(pm_message_t state)
int error = 0;
mutex_lock(&dpm_list_mtx);
+ pm_transition = state;
+ async_error = 0;
+
while (!list_empty(&dpm_suspended_list)) {
struct device *dev = to_device(dpm_suspended_list.prev);
get_device(dev);
mutex_unlock(&dpm_list_mtx);
- error = device_suspend_late(dev, state);
+ error = device_suspend_late(dev);
mutex_lock(&dpm_list_mtx);
if (error) {
pm_dev_err(dev, state, " late", error);
- suspend_stats.failed_suspend_late++;
- dpm_save_failed_step(SUSPEND_SUSPEND_LATE);
dpm_save_failed_dev(dev_name(dev));
put_device(dev);
break;
@@ -1195,17 +1234,18 @@ static int dpm_suspend_late(pm_message_t state)
list_move(&dev->power.entry, &dpm_late_early_list);
put_device(dev);
- if (pm_wakeup_pending()) {
- error = -EBUSY;
+ if (async_error)
break;
- }
}
mutex_unlock(&dpm_list_mtx);
- if (error)
+ async_synchronize_full();
+ if (error) {
+ suspend_stats.failed_suspend_late++;
+ dpm_save_failed_step(SUSPEND_SUSPEND_LATE);
dpm_resume_early(resume_event(state));
- else
+ } else {
dpm_show_time(starttime, state, "late");
-
+ }
return error;
}
--
1.9.rc0
--
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 4/5] PM / sleep: Asynchronous threads for suspend_noirq
In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall suspend_noirq
time significantly.
This patch is for suspend_noirq phase.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 68 +++
1 file changed, 57 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 2f2d110..72b4c9c 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -990,14 +990,24 @@ static pm_message_t resume_event(pm_message_t sleep_state)
* The driver of @dev will not receive interrupts while this function is being
* executed.
*/
-static int device_suspend_noirq(struct device *dev, pm_message_t state)
+static int __device_suspend_noirq(struct device *dev, pm_message_t state, bool
async)
{
pm_callback_t callback = NULL;
char *info = NULL;
- int error;
+ int error = 0;
+
+ dpm_wait_for_children(dev, async);
+
+ if (async_error)
+ goto Complete;
+
+ if (pm_wakeup_pending()) {
+ async_error = -EBUSY;
+ goto Complete;
+ }
if (dev->power.syscore)
- return 0;
+ goto Complete;
if (dev->pm_domain) {
info = "noirq power domain ";
@@ -1021,10 +1031,40 @@ static int device_suspend_noirq(struct device *dev,
pm_message_t state)
error = dpm_run_callback(callback, dev, state, info);
if (!error)
dev->power.is_noirq_suspended = true;
+ else
+ async_error = error;
+Complete:
+ complete_all(&dev->power.completion);
return error;
}
+static void async_suspend_noirq(void *data, async_cookie_t cookie)
+{
+ struct device *dev = (struct device *)data;
+ int error;
+
+ error = __device_suspend_noirq(dev, pm_transition, true);
+ if (error) {
+ dpm_save_failed_dev(dev_name(dev));
+ pm_dev_err(dev, pm_transition, " async", error);
+ }
+
+ put_device(dev);
+}
+
+static int device_suspend_noirq(struct device *dev)
+{
+ reinit_completion(&dev->power.completion);
+
+ if (pm_async_enabled && dev->power.async_suspend) {
+ get_device(dev);
+ async_schedule(async_suspend_noirq, dev);
+ return 0;
+ }
+ return __device_suspend_noirq(dev, pm_transition, false);
+}
+
/**
* dpm_suspend_noirq - Execute "noirq suspend" callbacks for all devices.
* @state: PM transition of the system being carried out.
@@ -1040,19 +1080,20 @@ static int dpm_suspend_noirq(pm_message_t state)
cpuidle_pause();
suspend_device_irqs();
mutex_lock(&dpm_list_mtx);
+ pm_transition = state;
+ async_error = 0;
+
while (!list_empty(&dpm_late_early_list)) {
struct device *dev = to_device(dpm_late_early_list.prev);
get_device(dev);
mutex_unlock(&dpm_list_mtx);
- error = device_suspend_noirq(dev, state);
+ error = device_suspend_noirq(dev);
mutex_lock(&dpm_list_mtx);
if (error) {
pm_dev_err(dev, state, " noirq", error);
- suspend_stats.failed_suspend_noirq++;
- dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
dpm_save_failed_dev(dev_name(dev));
put_device(dev);
break;
@@ -1061,16 +1102,21 @@ static int dpm_suspend_noirq(pm_message_t state)
list_move(&dev->power.entry, &dpm_noirq_list);
put_device(dev);
- if (pm_wakeup_pending()) {
- error = -EBUSY;
+ if (async_error)
break;
- }
}
mutex_unlock(&dpm_list_mtx);
- if (error)
+ async_synchronize_full();
+ if (!error)
+ error = async_error;
+
+ if (error) {
+ suspend_stats.failed_suspend_noirq++;
+ dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
dpm_resume_noirq(resume_event(state));
- else
+ } else {
dpm_show_time(starttime, state, "noirq");
+ }
return error;
}
--
1.9.rc0
--
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 3/5] PM / sleep: Asynchronous threads for resume_early
In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall resume_early
time significantly.
This patch is for resume_early phase.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 55 +--
1 file changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 89172aa..2f2d110 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -595,7 +595,7 @@ static void dpm_resume_noirq(pm_message_t state)
*
* Runtime PM is disabled for @dev while this function is being executed.
*/
-static int device_resume_early(struct device *dev, pm_message_t state)
+static int device_resume_early(struct device *dev, pm_message_t state, bool
async)
{
pm_callback_t callback = NULL;
char *info = NULL;
@@ -607,6 +607,8 @@ static int device_resume_early(struct device *dev,
pm_message_t state)
if (dev->power.syscore)
goto Out;
+ dpm_wait(dev->parent, async);
+
if (!dev->power.is_late_suspended)
goto Out;
@@ -636,38 +638,69 @@ static int device_resume_early(struct device *dev,
pm_message_t state)
TRACE_RESUME(error);
pm_runtime_enable(dev);
+ complete_all(&dev->power.completion);
return error;
}
+static void async_resume_early(void *data, async_cookie_t cookie)
+{
+ struct device *dev = (struct device *)data;
+ int error;
+
+ error = device_resume_early(dev, pm_transition, true);
+ if (error)
+ pm_dev_err(dev, pm_transition, " async", error);
+
+ put_device(dev);
+}
+
/**
* dpm_resume_early - Execute "early resume" callbacks for all devices.
* @state: PM transition of the system being carried out.
*/
static void dpm_resume_early(pm_message_t state)
{
+ struct device *dev;
ktime_t starttime = ktime_get();
mutex_lock(&dpm_list_mtx);
- while (!list_empty(&dpm_late_early_list)) {
- struct device *dev = to_device(dpm_late_early_list.next);
- int error;
+ pm_transition = state;
+
+ /*
+* Advanced the async threads upfront,
+* in case the starting of async threads is
+* delayed by non-async resuming devices.
+*/
+ list_for_each_entry(dev, &dpm_late_early_list, power.entry) {
+ reinit_completion(&dev->power.completion);
+ if (is_async(dev)) {
+ get_device(dev);
+ async_schedule(async_resume_early, dev);
+ }
+ }
+ while (!list_empty(&dpm_late_early_list)) {
+ dev = to_device(dpm_late_early_list.next);
get_device(dev);
list_move_tail(&dev->power.entry, &dpm_suspended_list);
mutex_unlock(&dpm_list_mtx);
- error = device_resume_early(dev, state);
- if (error) {
- suspend_stats.failed_resume_early++;
- dpm_save_failed_step(SUSPEND_RESUME_EARLY);
- dpm_save_failed_dev(dev_name(dev));
- pm_dev_err(dev, state, " early", error);
- }
+ if (!is_async(dev)) {
+ int error;
+ error = device_resume_early(dev, state, false);
+ if (error) {
+ suspend_stats.failed_resume_early++;
+ dpm_save_failed_step(SUSPEND_RESUME_EARLY);
+ dpm_save_failed_dev(dev_name(dev));
+ pm_dev_err(dev, state, " early", error);
+ }
+ }
mutex_lock(&dpm_list_mtx);
put_device(dev);
}
mutex_unlock(&dpm_list_mtx);
+ async_synchronize_full();
dpm_show_time(starttime, state, "early");
}
--
1.9.rc0
--
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 2/5] PM / sleep: Asynchronous threads for resume_noirq
In analogy with commits 5af84b82701a and 97df8c12995, using
asynchronous threads can improve the overall resume_noirq time
significantly.
One typical case is:
In resume_noirq phase and for the PCI devices, the function
pci_pm_resume_noirq() will be called, and there is one d3_delay
(10ms) at least.
With the way of asynchronous threads, we just need wait d3_delay
time once in parallel for each calling, which saves much time to
resume quickly.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 66 +++
1 file changed, 50 insertions(+), 16 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 00c53eb..89172aa 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -469,7 +469,7 @@ static void dpm_watchdog_clear(struct dpm_watchdog *wd)
* The driver of @dev will not receive interrupts while this function is being
* executed.
*/
-static int device_resume_noirq(struct device *dev, pm_message_t state)
+static int device_resume_noirq(struct device *dev, pm_message_t state, bool
async)
{
pm_callback_t callback = NULL;
char *info = NULL;
@@ -481,6 +481,8 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
if (dev->power.syscore)
goto Out;
+ dpm_wait(dev->parent, async);
+
if (!dev->power.is_noirq_suspended)
goto Out;
@@ -507,10 +509,29 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
dev->power.is_noirq_suspended = false;
Out:
+ complete_all(&dev->power.completion);
TRACE_RESUME(error);
return error;
}
+static bool is_async(struct device *dev)
+{
+ return dev->power.async_suspend && pm_async_enabled
+ && !pm_trace_is_enabled();
+}
+
+static void async_resume_noirq(void *data, async_cookie_t cookie)
+{
+ struct device *dev = (struct device *)data;
+ int error;
+
+ error = device_resume_noirq(dev, pm_transition, true);
+ if (error)
+ pm_dev_err(dev, pm_transition, " async", error);
+
+ put_device(dev);
+}
+
/**
* dpm_resume_noirq - Execute "noirq resume" callbacks for all devices.
* @state: PM transition of the system being carried out.
@@ -520,29 +541,48 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
*/
static void dpm_resume_noirq(pm_message_t state)
{
+ struct device *dev;
ktime_t starttime = ktime_get();
mutex_lock(&dpm_list_mtx);
- while (!list_empty(&dpm_noirq_list)) {
- struct device *dev = to_device(dpm_noirq_list.next);
- int error;
+ pm_transition = state;
+
+ /*
+* Advanced the async threads upfront,
+* in case the starting of async threads is
+* delayed by non-async resuming devices.
+*/
+ list_for_each_entry(dev, &dpm_noirq_list, power.entry) {
+ reinit_completion(&dev->power.completion);
+ if (is_async(dev)) {
+ get_device(dev);
+ async_schedule(async_resume_noirq, dev);
+ }
+ }
+ while (!list_empty(&dpm_noirq_list)) {
+ dev = to_device(dpm_noirq_list.next);
get_device(dev);
list_move_tail(&dev->power.entry, &dpm_late_early_list);
mutex_unlock(&dpm_list_mtx);
- error = device_resume_noirq(dev, state);
- if (error) {
- suspend_stats.failed_resume_noirq++;
- dpm_save_failed_step(SUSPEND_RESUME_NOIRQ);
- dpm_save_failed_dev(dev_name(dev));
- pm_dev_err(dev, state, " noirq", error);
+ if (!is_async(dev)) {
+ int error;
+
+ error = device_resume_noirq(dev, state, false);
+ if (error) {
+ suspend_stats.failed_resume_noirq++;
+ dpm_save_failed_step(SUSPEND_RESUME_NOIRQ);
+ dpm_save_failed_dev(dev_name(dev));
+ pm_dev_err(dev, state, " noirq", error);
+ }
}
mutex_lock(&dpm_list_mtx);
put_device(dev);
}
mutex_unlock(&dpm_list_mtx);
+ async_synchronize_full();
dpm_show_time(starttime, state, "noirq");
resume_device_irqs();
cpuidle_resume();
@@ -742,12 +782,6 @@ static void async_resume(void *data, async_cookie_t cookie)
put_device(dev);
}
-static bool is_async(struct device *dev)
-{
- return dev->power.async_suspend && pm_async_enabled
- && !pm_trace_is_enabled();
-}
-
/**
* dpm_resume - Execute "resume" callbacks for non-sysdev devices.
* @state: PM transition of the system being carried out.
--
1.9.rc0
--
To un
[PATCH v2 1/5] PM / sleep: Two flags for async suspend_noirq and suspend_late
The patch is a helper adding two new flags for implementing
async threads for suspend_noirq and suspend_late.
Signed-off-by: Chuansheng Liu
---
drivers/base/power/main.c | 24 ++--
include/linux/pm.h| 2 ++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 1b41fca..00c53eb 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -91,6 +91,8 @@ void device_pm_sleep_init(struct device *dev)
{
dev->power.is_prepared = false;
dev->power.is_suspended = false;
+ dev->power.is_noirq_suspended = false;
+ dev->power.is_late_suspended = false;
init_completion(&dev->power.completion);
complete_all(&dev->power.completion);
dev->power.wakeup = NULL;
@@ -479,6 +481,9 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
if (dev->power.syscore)
goto Out;
+ if (!dev->power.is_noirq_suspended)
+ goto Out;
+
if (dev->pm_domain) {
info = "noirq power domain ";
callback = pm_noirq_op(&dev->pm_domain->ops, state);
@@ -499,6 +504,7 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state)
}
error = dpm_run_callback(callback, dev, state, info);
+ dev->power.is_noirq_suspended = false;
Out:
TRACE_RESUME(error);
@@ -561,6 +567,9 @@ static int device_resume_early(struct device *dev,
pm_message_t state)
if (dev->power.syscore)
goto Out;
+ if (!dev->power.is_late_suspended)
+ goto Out;
+
if (dev->pm_domain) {
info = "early power domain ";
callback = pm_late_early_op(&dev->pm_domain->ops, state);
@@ -581,6 +590,7 @@ static int device_resume_early(struct device *dev,
pm_message_t state)
}
error = dpm_run_callback(callback, dev, state, info);
+ dev->power.is_late_suspended = false;
Out:
TRACE_RESUME(error);
@@ -917,6 +927,7 @@ static int device_suspend_noirq(struct device *dev,
pm_message_t state)
{
pm_callback_t callback = NULL;
char *info = NULL;
+ int error;
if (dev->power.syscore)
return 0;
@@ -940,7 +951,11 @@ static int device_suspend_noirq(struct device *dev,
pm_message_t state)
callback = pm_noirq_op(dev->driver->pm, state);
}
- return dpm_run_callback(callback, dev, state, info);
+ error = dpm_run_callback(callback, dev, state, info);
+ if (!error)
+ dev->power.is_noirq_suspended = true;
+
+ return error;
}
/**
@@ -1003,6 +1018,7 @@ static int device_suspend_late(struct device *dev,
pm_message_t state)
{
pm_callback_t callback = NULL;
char *info = NULL;
+ int error;
__pm_runtime_disable(dev, false);
@@ -1028,7 +1044,11 @@ static int device_suspend_late(struct device *dev,
pm_message_t state)
callback = pm_late_early_op(dev->driver->pm, state);
}
- return dpm_run_callback(callback, dev, state, info);
+ error = dpm_run_callback(callback, dev, state, info);
+ if (!error)
+ dev->power.is_late_suspended = true;
+
+ return error;
}
/**
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 8c6583a..f23a4f1 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -542,6 +542,8 @@ struct dev_pm_info {
unsigned intasync_suspend:1;
boolis_prepared:1; /* Owned by the PM core */
boolis_suspended:1; /* Ditto */
+ boolis_noirq_suspended:1;
+ boolis_late_suspended:1;
boolignore_children:1;
boolearly_init:1; /* Owned by the PM core */
spinlock_t lock;
--
1.9.rc0
--
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] Revert "ACPI / video: Add HP EliteBook Revolve 810 to the blacklist"
On 02/15/2014 06:21 AM, Rafael J. Wysocki wrote: > On Friday, February 14, 2014 05:26:01 PM Mika Westerberg wrote: >> On Fri, Feb 14, 2014 at 03:46:20PM +0100, Takashi Iwai wrote: >>> The acpi_osi blacklist is just a workaround, and if we have better >>> solutions, it should be removed. That's why I'm asking it. >>> >>> So, after removing acpi_osi blacklist, and keeping your video >>> blacklist patch, the backlight works? >> >> Yes, the backlight works (there is only intel_backlight listed under >> /sys/class/backlight). >> >>> If yes, as mentioned, we should think of rather extending this video >>> blacklist to more EliteBook G1 and ProBook G1 machines, and remove >>> acpi_osi blacklist instead. >> >> Makes sense to me. (Well, I'm fine as long as backlight on my machine works >> ;-)) >> >> Aaron, Rafael, any comments on this? > > I generally agree with Takashi, but I'm not sure what to do for 3.14. I can re-base the previously sent patch titled: [PATCH] ACPI / video: Add systems that should favor native backlight interface And put Mika's system into the DMI table that will use native backlight interface in video module and remove it from video_detect's DMI table at the same time. Does this sound OK? -- 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 0/5] Enabling the asynchronous threads for other phases
Hello, This patch series are for enabling the asynchronous threads for the phases resume_noirq, resume_early, suspend_noirq and suspend_late. Just like commit 5af84b82701a and 97df8c12995, with async threads it will reduce the system suspending and resuming time significantly. With these patches, in my test platform, it saved 80% time in resume_noirq phase. Best Regards, --- V2: -- Based on Rafael's minor changes related to coding style, white space etc; -- Rafael pointed out the v1 series break the device parent-children suspending/resuming order when enabling asyncing, here using the dev completion to sync parent-children order; --- [PATCH 1/5] PM / sleep: Two flags for async suspend_noirq and [PATCH 2/5] PM / sleep: Asynchronous threads for resume_noirq [PATCH 3/5] PM / sleep: Asynchronous threads for resume_early [PATCH 4/5] PM / sleep: Asynchronous threads for suspend_noirq [PATCH 5/5] PM / sleep: Asynchronous threads for suspend_late drivers/base/power/main.c | 273 ++ include/linux/pm.h| 2 ++ 2 files changed, 225 insertions(+), 50 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/
[PATCH] smack lsm bug fixes
From 8fa425d071b7d4cfdf6bcb89d789138a13529d06 Mon Sep 17 00:00:00 2001
From: Pankaj Kumar
Date: Mon, 17 Feb 2014 10:36:26 +0530
Subject: [PATCH] smack lsm bug fixes
1. In order to remove any SMACK extended attribute from a file, a user
should have CAP_MAC_ADMIN capability. But any user without this
capability is able to remove SMACK64MMAP security attribute. This error
has been corrected by a modification in smack_inode_removexattr hook.
2. While setting extended attribute in smack_inode_setsecurity hook,
'-EACCES' error is returned if extended attribute size or value is not
correct. This is wrong error rather this is invalid extended attribute
case. Corrected error '-EINVAL' shall be returned.
---
security/smack/smack_lsm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 14f52be..e1b1650 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -938,7 +938,7 @@ static int smack_inode_removexattr(struct dentry *dentry,
const char *name)
strcmp(name, XATTR_NAME_SMACKIPOUT) == 0 ||
strcmp(name, XATTR_NAME_SMACKEXEC) == 0 ||
strcmp(name, XATTR_NAME_SMACKTRANSMUTE) == 0 ||
- strcmp(name, XATTR_NAME_SMACKMMAP)) {
+ strcmp(name, XATTR_NAME_SMACKMMAP) == 0) {
if (!smack_privileged(CAP_MAC_ADMIN))
rc = -EPERM;
} else
@@ -2076,7 +2076,7 @@ static int smack_inode_setsecurity(struct inode *inode,
const char *name,
int rc = 0;
if (value == NULL || size > SMK_LONGLABEL || size == 0)
- return -EACCES;
+ return -EINVAL;
skp = smk_import_entry(value, size);
if (skp == NULL)
--
1.8.1.2
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH net-next 0/4] bonding cleaning
From: Joe Perches Date: Sat, 15 Feb 2014 15:57:03 -0800 > Miscellaneous cleanups > > Joe Perches (4): > bonding: Convert pr_warning to pr_warn, neatening > bonding: Neaten pr_ > bonding: Convert c99 comments > bonding: Convert memcpy(foo, bar, ETH_ALEN) to ether_addr_copy(foo, bar) Series applied, thanks. -- 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/3] caif: delete unnecessary field initialization
From: Julia Lawall Date: Sat, 15 Feb 2014 08:36:13 +0100 > From: Julia Lawall > > On success, the function netdev_alloc_skb initializes the dev field of its > result to its first argument, so this doesn't have to be done in the > calling context. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ > expression skb,privn,e; > @@ > > skb = netdev_alloc_skb(privn,...); > ... when strict > ( > -skb->dev = privn; > | > ?skb = e > ) > // > > Signed-off-by: Julia Lawall Applied to net-next, thanks. -- 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] rcu: move SRCU grace period work to power efficient workqueue
On Wed, 2014-02-12 at 19:23 +0100, Frederic Weisbecker wrote: > On Mon, Feb 10, 2014 at 10:47:29AM -0800, Paul E. McKenney wrote: > > On Mon, Feb 10, 2014 at 06:08:31PM +0800, Lai Jiangshan wrote: > > > Acked-by: Lai Jiangshan > > > > Thank you all, queued for 3.15. > > > > We should also have some facility for moving the SRCU workqueues to > > housekeeping/timekeeping kthreads in the NO_HZ_FULL case. Or does > > this patch already have that effect? > > Kevin Hilman and me plan to try to bring a new Kconfig option that could let > us control the unbound workqueues affinity through sysfs. Handing control to the user seemed like a fine thing, so I started making a boot option to enable it. Forcing WQ_SYSFS on at sysfs decision spot doesn't go well, init order matters :) Post init frobbing required if you want to see/frob all unbound. -Mike -- 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] cpufreq: Refactor cpufreq_set_policy()
On 17 February 2014 06:36, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Reduce the rampant usage of goto and the indentation level in
> cpufreq_set_policy() to improve the readability of that code.
>
> No functional changes should result from that.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/cpufreq.c | 102
> --
> 1 file changed, 45 insertions(+), 57 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -2018,22 +2018,21 @@ EXPORT_SYMBOL(cpufreq_get_policy);
> static int cpufreq_set_policy(struct cpufreq_policy *policy,
> struct cpufreq_policy *new_policy)
> {
> - int ret = 0, failed = 1;
> + struct cpufreq_governor *old_gov;
> + int ret;
>
> pr_debug("setting new policy for CPU %u: %u - %u kHz\n",
> new_policy->cpu,
> new_policy->min, new_policy->max);
>
> memcpy(&new_policy->cpuinfo, &policy->cpuinfo,
> sizeof(policy->cpuinfo));
>
> - if (new_policy->min > policy->max || new_policy->max < policy->min) {
> - ret = -EINVAL;
> - goto error_out;
> - }
> + if (new_policy->min > policy->max || new_policy->max < policy->min)
> + return -EINVAL;
>
> /* verify the cpu speed can be set within this limit */
> ret = cpufreq_driver->verify(new_policy);
> if (ret)
> - goto error_out;
> + return ret;
>
> /* adjust if necessary - all reasons */
> blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> @@ -2049,7 +2048,7 @@ static int cpufreq_set_policy(struct cpu
> */
> ret = cpufreq_driver->verify(new_policy);
> if (ret)
> - goto error_out;
> + return ret;
>
> /* notification of the new policy */
> blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> @@ -2064,58 +2063,47 @@ static int cpufreq_set_policy(struct cpu
> if (cpufreq_driver->setpolicy) {
> policy->policy = new_policy->policy;
> pr_debug("setting range\n");
> - ret = cpufreq_driver->setpolicy(new_policy);
> - } else {
> - if (new_policy->governor != policy->governor) {
> - /* save old, working values */
> - struct cpufreq_governor *old_gov = policy->governor;
> -
> - pr_debug("governor switch\n");
> -
> - /* end old governor */
> - if (policy->governor) {
> - __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> - up_write(&policy->rwsem);
> - __cpufreq_governor(policy,
> - CPUFREQ_GOV_POLICY_EXIT);
> - down_write(&policy->rwsem);
> - }
> -
> - /* start new governor */
> - policy->governor = new_policy->governor;
> - if (!__cpufreq_governor(policy,
> CPUFREQ_GOV_POLICY_INIT)) {
> - if (!__cpufreq_governor(policy,
> CPUFREQ_GOV_START)) {
> - failed = 0;
> - } else {
> - up_write(&policy->rwsem);
> - __cpufreq_governor(policy,
> -
> CPUFREQ_GOV_POLICY_EXIT);
> - down_write(&policy->rwsem);
> - }
> - }
> -
> - if (failed) {
> - /* new governor failed, so re-start old one */
> - pr_debug("starting governor %s failed\n",
> -
> policy->governor->name);
> - if (old_gov) {
> - policy->governor = old_gov;
> - __cpufreq_governor(policy,
> -
> CPUFREQ_GOV_POLICY_INIT);
> - __cpufreq_governor(policy,
> - CPUFREQ_GOV_START);
> - }
> - ret = -EINVAL;
> - goto error_out;
> - }
> - /* might be a policy change, too, so fall through */
> - }
> - pr_debug("governor: change or update limits\n");
> - ret = __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS
Re: [PATCH 2/2] cpufreq: don't call cpufreq_update_policy() on CPU addition
On 17 February 2014 05:51, Rafael J. Wysocki wrote: > On Friday, February 14, 2014 04:30:41 PM Viresh Kumar wrote: >> cpufreq_update_policy() is called from two places currently. From a workqueue >> handled queued from cpufreq_bp_resume() for boot CPU and from >> cpufreq_cpu_callback() whenever a CPU is added. >> >> The first one makes sure that boot CPU is running on the frequency present in >> policy->cpu. But we don't really need a call from cpufreq_cpu_callback(), >> because we always call cpufreq_driver->init() (which will set policy->cur >> correctly) whenever first CPU of any policy is added back. And so every >> policy >> structure is guaranteed to have the right frequency in policy->cur. > > That sounds good, but doing the extra cpufreq_update_policy() shouldn't > actually > hurt, should it? Yeah, it shouldn't hurt badly.. > So, that would be a cleanup rather than a fix, right? Hmm, yeah.. -- 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/2] cpufreq: Return error if ->get() failed in cpufreq_update_policy()
On 17 February 2014 05:58, Rafael J. Wysocki wrote:
> On Friday, February 14, 2014 04:30:40 PM Viresh Kumar wrote:
> Good to know that you chat with each other, but it really is not a useful
> piece
> of information until you say what *exactly* you were talking about.
All that is mentioned in commit logs of both the patches :) .. That's all we
discussed.
>> drivers/cpufreq/cpufreq.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 08ca8c9..383362b 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -2151,6 +2151,13 @@ int cpufreq_update_policy(unsigned int cpu)
>>*/
>> if (cpufreq_driver->get) {
>> new_policy.cur = cpufreq_driver->get(cpu);
>> +
>> + if (!new_policy.cur) {
>> + pr_err("%s: ->get() returned 0 KHz\n", __func__);
>> + ret = -EINVAL;
>
> That isn't -EINVAL. It may be -EIO or -ENODEV, but not -EINVAL. Please.
Hmm.. Correct. I will use EIO then..
>> + goto no_policy;
>
> And is it unsafe to continue here? Or can we continue regardless of getting
> 0?
We were supposed to set this frequency as the current frequency in policy->cur,
what else can we do now in this function when we aren't able to read current
freq? And so I thought that's all we can do here.
>> + }
>> +
>> if (!policy->cur) {
>> pr_debug("Driver did not initialize current freq");
>> policy->cur = new_policy.cur;
>>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] sb_edac: degrade log level for "EDAC sbridge: Seeking for: dev 1d.3 PCI ID xxxx"
On a system with four Intel processor, it generates too many messages "EDAC sbridge: Seeking for: dev 1d.3 PCI ID ". And it doesn't give many useful information for normal users, so change log level from INFO to DEBUG. Signed-off-by: Jiang Liu --- drivers/edac/sb_edac.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c index 54e2abe..347c7a1 100644 --- a/drivers/edac/sb_edac.c +++ b/drivers/edac/sb_edac.c @@ -1263,7 +1263,7 @@ static int sbridge_get_onedevice(struct pci_dev **prev, struct pci_dev *pdev = NULL; u8 bus = 0; - sbridge_printk(KERN_INFO, + sbridge_printk(KERN_DEBUG, "Seeking for: dev %02x.%d PCI ID %04x:%04x\n", dev_descr->dev, dev_descr->func, PCI_VENDOR_ID_INTEL, dev_descr->dev_id); -- 1.7.10.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/
[RFC Patch v1 4/6] xen, acpi_pad: use acpi_evaluate_pad() to replace open-coded version
Use public function acpi_evaluate_pad() to replace open-coded
version of evaluating ACPI _OST method.
Signed-off-by: Jiang Liu
---
drivers/xen/xen-acpi-pad.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/xen/xen-acpi-pad.c b/drivers/xen/xen-acpi-pad.c
index 40c4bc0..f83b754 100644
--- a/drivers/xen/xen-acpi-pad.c
+++ b/drivers/xen/xen-acpi-pad.c
@@ -77,27 +77,14 @@ static int acpi_pad_pur(acpi_handle handle)
return num;
}
-/* Notify firmware how many CPUs are idle */
-static void acpi_pad_ost(acpi_handle handle, int stat,
- uint32_t idle_nums)
-{
- union acpi_object params[3] = {
- {.type = ACPI_TYPE_INTEGER,},
- {.type = ACPI_TYPE_INTEGER,},
- {.type = ACPI_TYPE_BUFFER,},
- };
- struct acpi_object_list arg_list = {3, params};
-
- params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
- params[1].integer.value = stat;
- params[2].buffer.length = 4;
- params[2].buffer.pointer = (void *)&idle_nums;
- acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
-}
-
static void acpi_pad_handle_notify(acpi_handle handle)
{
int idle_nums;
+ struct acpi_buffer param = {
+ .length = 4,
+ .pointer = (void *)&idle_nums,
+ };
+
mutex_lock(&xen_cpu_lock);
idle_nums = acpi_pad_pur(handle);
@@ -109,7 +96,8 @@ static void acpi_pad_handle_notify(acpi_handle handle)
idle_nums = xen_acpi_pad_idle_cpus(idle_nums)
?: xen_acpi_pad_idle_cpus_num();
if (idle_nums >= 0)
- acpi_pad_ost(handle, 0, idle_nums);
+ acpi_evaluate_ost(handle, ACPI_PROCESSOR_AGGREGATOR_NOTIFY,
+ 0, ¶m);
mutex_unlock(&xen_cpu_lock);
}
--
1.7.10.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/
[RFC Patch v1 1/6] acpi_pad: simplify notify handler by using acpi_drv_ops->notify
Use callback acpi_drv_ops->notify to simplify acpi_pad driver's
notification handling code.
Signed-off-by: Jiang Liu
---
drivers/acpi/acpi_pad.c | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index df96a0f..1e3ce76 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -443,14 +443,11 @@ static void acpi_pad_handle_notify(acpi_handle handle)
mutex_unlock(&isolated_cpus_lock);
}
-static void acpi_pad_notify(acpi_handle handle, u32 event,
- void *data)
+static void acpi_pad_notify(struct acpi_device *device, u32 event)
{
- struct acpi_device *device = data;
-
switch (event) {
case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
- acpi_pad_handle_notify(handle);
+ acpi_pad_handle_notify(device->handle);
acpi_bus_generate_netlink_event(device->pnp.device_class,
dev_name(&device->dev), event, 0);
break;
@@ -462,22 +459,10 @@ static void acpi_pad_notify(acpi_handle handle, u32 event,
static int acpi_pad_add(struct acpi_device *device)
{
- acpi_status status;
-
strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
- if (acpi_pad_add_sysfs(device))
- return -ENODEV;
-
- status = acpi_install_notify_handler(device->handle,
- ACPI_DEVICE_NOTIFY, acpi_pad_notify, device);
- if (ACPI_FAILURE(status)) {
- acpi_pad_remove_sysfs(device);
- return -ENODEV;
- }
-
- return 0;
+ return acpi_pad_add_sysfs(device);
}
static int acpi_pad_remove(struct acpi_device *device)
@@ -486,9 +471,8 @@ static int acpi_pad_remove(struct acpi_device *device)
acpi_pad_idle_cpus(0);
mutex_unlock(&isolated_cpus_lock);
- acpi_remove_notify_handler(device->handle,
- ACPI_DEVICE_NOTIFY, acpi_pad_notify);
acpi_pad_remove_sysfs(device);
+
return 0;
}
@@ -505,6 +489,7 @@ static struct acpi_driver acpi_pad_driver = {
.ops = {
.add = acpi_pad_add,
.remove = acpi_pad_remove,
+ .notify = acpi_pad_notify,
},
};
--
1.7.10.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/
[RFC Patch v1 3/6] acpi_pad: use acpi_evaluate_pad() to replace open-coded version
Use public function acpi_evaluate_pad() to replace open-coded
version of evaluating ACPI _OST method.
Signed-off-by: Jiang Liu
---
drivers/acpi/acpi_pad.c | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index 1e3ce76..86b4e11 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -408,28 +408,14 @@ static int acpi_pad_pur(acpi_handle handle)
return num;
}
-/* Notify firmware how many CPUs are idle */
-static void acpi_pad_ost(acpi_handle handle, int stat,
- uint32_t idle_cpus)
-{
- union acpi_object params[3] = {
- {.type = ACPI_TYPE_INTEGER,},
- {.type = ACPI_TYPE_INTEGER,},
- {.type = ACPI_TYPE_BUFFER,},
- };
- struct acpi_object_list arg_list = {3, params};
-
- params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
- params[1].integer.value = stat;
- params[2].buffer.length = 4;
- params[2].buffer.pointer = (void *)&idle_cpus;
- acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
-}
-
static void acpi_pad_handle_notify(acpi_handle handle)
{
int num_cpus;
uint32_t idle_cpus;
+ struct acpi_buffer param = {
+ .length = 4,
+ .pointer = (void *)&idle_cpus,
+ };
mutex_lock(&isolated_cpus_lock);
num_cpus = acpi_pad_pur(handle);
@@ -439,7 +425,7 @@ static void acpi_pad_handle_notify(acpi_handle handle)
}
acpi_pad_idle_cpus(num_cpus);
idle_cpus = acpi_pad_idle_cpus_num();
- acpi_pad_ost(handle, 0, idle_cpus);
+ acpi_evaluate_ost(handle, ACPI_PROCESSOR_AGGREGATOR_NOTIFY, 0, ¶m);
mutex_unlock(&isolated_cpus_lock);
}
--
1.7.10.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/
[RFC Patch v1 6/6] ACPI: use device name LNXSYBUS.xx for ACPI \_SB and \_TZ objects
Use device name "LNXSYBUS:xx" instead of "device.xx" for ACPI objects
\_SB and \_TZ.
BTW, the original check of "handle == ACPI_ROOT_OBJECT" in statment
"else if (list_empty(&pnp->ids) && handle == ACPI_ROOT_OBJECT)"
is always false because of the code at the begin of that block.
if (handle == ACPI_ROOT_OBJECT) {
acpi_add_id(pnp, ACPI_SYSTEM_HID);
break;
}
Signed-off-by: Jiang Liu
---
drivers/acpi/scan.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 57b053f..62ec4ba 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1706,6 +1706,20 @@ static bool acpi_ibm_smbus_match(acpi_handle handle)
return false;
}
+static bool acpi_object_is_system_bus(acpi_handle handle)
+{
+ acpi_handle tmp;
+
+ if (ACPI_SUCCESS(acpi_get_handle(NULL, "\\_SB", &tmp)) &&
+ tmp == handle)
+ return true;
+ if (ACPI_SUCCESS(acpi_get_handle(NULL, "\\_TZ", &tmp)) &&
+ tmp == handle)
+ return true;
+
+ return false;
+}
+
static void acpi_set_pnp_ids(acpi_handle handle, struct acpi_device_pnp *pnp,
int device_type)
{
@@ -1757,8 +1771,10 @@ static void acpi_set_pnp_ids(acpi_handle handle, struct
acpi_device_pnp *pnp,
acpi_add_id(pnp, ACPI_DOCK_HID);
else if (acpi_ibm_smbus_match(handle))
acpi_add_id(pnp, ACPI_SMBUS_IBM_HID);
- else if (list_empty(&pnp->ids) && handle == ACPI_ROOT_OBJECT) {
- acpi_add_id(pnp, ACPI_BUS_HID); /* \_SB, LNXSYBUS */
+ else if (list_empty(&pnp->ids) &&
+acpi_object_is_system_bus(handle)) {
+ /* \_SB, \_TZ, LNXSYBUS */
+ acpi_add_id(pnp, ACPI_BUS_HID);
strcpy(pnp->device_name, ACPI_BUS_DEVICE_NAME);
strcpy(pnp->device_class, ACPI_BUS_CLASS);
}
--
1.7.10.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/
[RFC Patch v1 2/6] ACPI: rename acpi_evaluate_hotplug_ost to acpi_evaluate_ost for reuse
Rename acpi_evaluate_hotplug_ost() to acpi_evaluate_ost() for later resue.
Signed-off-by: Jiang Liu
---
drivers/acpi/utils.c| 14 --
include/acpi/acpi_bus.h | 10 +-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 85e3b61..19d0169 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -433,17 +433,15 @@ EXPORT_SYMBOL(acpi_get_physical_device_location);
* When the platform does not support _OST, this function has no effect.
*/
acpi_status
-acpi_evaluate_hotplug_ost(acpi_handle handle, u32 source_event,
- u32 status_code, struct acpi_buffer *status_buf)
+acpi_evaluate_ost(acpi_handle handle, u32 source_event, u32 status_code,
+ struct acpi_buffer *status_buf)
{
-#ifdef ACPI_HOTPLUG_OST
union acpi_object params[3] = {
{.type = ACPI_TYPE_INTEGER,},
{.type = ACPI_TYPE_INTEGER,},
{.type = ACPI_TYPE_BUFFER,}
};
struct acpi_object_list arg_list = {3, params};
- acpi_status status;
params[0].integer.value = source_event;
params[1].integer.value = status_code;
@@ -455,13 +453,9 @@ acpi_evaluate_hotplug_ost(acpi_handle handle, u32
source_event,
params[2].buffer.length = 0;
}
- status = acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
- return status;
-#else
- return AE_OK;
-#endif
+ return acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
}
-EXPORT_SYMBOL(acpi_evaluate_hotplug_ost);
+EXPORT_SYMBOL(acpi_evaluate_ost);
/**
* acpi_handle_printk: Print message with ACPI prefix and object path
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 8256eb4..adef502 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -49,8 +49,16 @@ acpi_evaluate_reference(acpi_handle handle,
struct acpi_object_list *arguments,
struct acpi_handle_list *list);
acpi_status
+acpi_evaluate_ost(acpi_handle handle, u32 source_event, u32 status_code,
+ struct acpi_buffer *status_buf);
+#ifdef ACPI_HOTPLUG_OST
+#defineacpi_evaluate_hotplug_ost acpi_evaluate_ost
+#else
+static inline acpi_status
acpi_evaluate_hotplug_ost(acpi_handle handle, u32 source_event,
- u32 status_code, struct acpi_buffer *status_buf);
+ u32 status_code, struct acpi_buffer *status_buf)
+{ return AE_OK; }
+#endif
acpi_status
acpi_get_physical_device_location(acpi_handle handle, struct acpi_pld_info
**pld);
--
1.7.10.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/
[RFC Patch v1 5/6] acpi_processor: use acpi_evaluate_pad() to replace open-coded version
Use public function acpi_evaluate_pad() to replace open-coded
version of evaluating ACPI _OST method.
Signed-off-by: Jiang Liu
---
drivers/acpi/processor_perflib.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index ff90054..cfc8aba 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -156,17 +156,9 @@ static int acpi_processor_get_platform_limit(struct
acpi_processor *pr)
*/
static void acpi_processor_ppc_ost(acpi_handle handle, int status)
{
- union acpi_object params[2] = {
- {.type = ACPI_TYPE_INTEGER,},
- {.type = ACPI_TYPE_INTEGER,},
- };
- struct acpi_object_list arg_list = {2, params};
-
- if (acpi_has_method(handle, "_OST")) {
- params[0].integer.value = ACPI_PROCESSOR_NOTIFY_PERFORMANCE;
- params[1].integer.value = status;
- acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
- }
+ if (acpi_has_method(handle, "_OST"))
+ acpi_evaluate_ost(handle, ACPI_PROCESSOR_NOTIFY_PERFORMANCE,
+ status, NULL);
}
int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int event_flag)
--
1.7.10.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/
[RFC Patch v1 0/6] Miscellaneous improvements for ACPI
Hi, This is a miscellaneous patch set to improve ACPI code. due to resource limitation, I can't find hardware to test all patches. So appreciate any help to these patches. Thanks! Gerry Jiang Liu (6): acpi_pad: simplify notify handler by using acpi_drv_ops->notify ACPI: rename acpi_evaluate_hotplug_ost to acpi_evaluate_ost for reuse acpi_pad: use acpi_evaluate_pad() to replace open-coded version xen, acpi_pad: use acpi_evaluate_pad() to replace open-coded version acpi_processor: use acpi_evaluate_pad() to replace open-coded version ACPI: use device name LNXSYBUS.xx for ACPI \_SB and \_TZ objects drivers/acpi/acpi_pad.c | 49 -- drivers/acpi/processor_perflib.c | 14 +++ drivers/acpi/scan.c | 20 ++-- drivers/acpi/utils.c | 14 --- drivers/xen/xen-acpi-pad.c | 26 ++-- include/acpi/acpi_bus.h | 10 +++- 6 files changed, 51 insertions(+), 82 deletions(-) -- 1.7.10.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: Re: [PATCH -tip RESEND 2/2] ftrace: Introduce nr_saved_cmdlines I/F
Hi Namhyung,
(2014/02/14 13:50), Namhyung Kim wrote:
> Hi Yoshihiro,
>
> On Thu, 13 Feb 2014 10:28:58 +0900, Yoshihiro YUNOMAE wrote:
>> Introduce nr_saved_cmdlines I/F for changing the number of pid-comm list.
>> saved_cmdlines can store 128 command names using SAVED_CMDLINES now, but
>> 'no-existing processes' names are often lost in saved_cmdlines when we
>> read trace data. So, by introducing nr_saved_cmdlines I/F, the rule storing
>> 128 command names is changed to the command numbers defined users.
>>
>> When we write a value to nr_saved_cmdlines, the number of the value will
>> be stored in pid-comm list:
>>
>> # echo 1024 > /sys/kernel/debug/tracing/nr_saved_cmdlines
>>
>> Here, 1024 command names are stored. The default number is 128 and the
>> maximum
>> number is PID_MAX_DEFAULT (=32768 if CONFIG_BASE_SMALL is not set). So, if we
>> want to avoid to lose command names, we need to set 32768 to
>> nr_saved_cmdlines.
>>
>> We can read the maximum number of the list:
>>
>> # cat /sys/kernel/debug/tracing/nr_saved_cmdlines
>> 128
>
> [SNIP]
>> @@ -3685,7 +3760,8 @@ static void *saved_cmdlines_next(struct seq_file *m,
>> void *v, loff_t *pos)
>>
>> (*pos)++;
>>
>> -for (; ptr < &map_cmdline_to_pid[SAVED_CMDLINES]; ptr++) {
>> +for (; ptr < &savedcmd->map_cmdline_to_pid[savedcmd->cmdline_num];
>> + ptr++) {
>> if (*ptr == -1 || *ptr == NO_CMDLINE_MAP)
>> continue;
>>
>> @@ -3700,7 +3776,7 @@ static void *saved_cmdlines_start(struct seq_file *m,
>> loff_t *pos)
>> void *v;
>> loff_t l = 0;
>>
>> -v = &map_cmdline_to_pid[0];
>> +v = &savedcmd->map_cmdline_to_pid[0];
>> while (l <= *pos) {
>> v = saved_cmdlines_next(m, v, &l);
>> if (!v)
>
> Are you accessing the savecmd without trace_cmdline_lock?
It does not need to get trace_cmdline_lock here.
The elements of map_pid_to_cmdline[] and saved_cmdlines[] are protected
by trace_cmdline_lock in trace_find_cmdline(), but on the other hand
map_cmdline_to_pid[] are not protected. There are no problems in
particular. This is because map_cmdline_to_pid[] always refers to a
valid process name or "<...>".
Note that we can always get process names by setting nr_saved_cmdlines
to maximum number if we want to avoid to get "<...>".
Thank you,
Yoshihiro YUNOMAE
--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com
--
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: [PATCHv4 0/4] add compressing abstraction and multi stream support
Hello Sergey, I don't have a time to look at it now Sorry for that. I will hold the time soonish. Thanks. On Wed, Feb 12, 2014 at 10:39:31PM +0300, Sergey Senozhatsky wrote: > This patchset introduces zcomp compression backend abstraction > adding ability to support compression algorithms other than LZO; > support for multi compression streams, making parallel compressions > possible. > > Diff from v3: > -- renamed compression backend and working memory structs as requested >by Minchan Kim; fixed several issues noted by Minchan Kim. > > Sergey Senozhatsky (4): > zram: introduce compressing backend abstraction > zram: use zcomp compressing backends > zram: support multi compressing buffers > zram: document max_comp_streams > > Documentation/ABI/testing/sysfs-block-zram | 9 +- > Documentation/blockdev/zram.txt| 21 +++- > drivers/block/zram/Makefile| 2 +- > drivers/block/zram/zcomp.c | 156 > + > drivers/block/zram/zcomp.h | 58 +++ > drivers/block/zram/zcomp_lzo.c | 33 ++ > drivers/block/zram/zram_drv.c | 102 --- > drivers/block/zram/zram_drv.h | 10 +- > 8 files changed, 345 insertions(+), 46 deletions(-) > create mode 100644 drivers/block/zram/zcomp.c > create mode 100644 drivers/block/zram/zcomp.h > create mode 100644 drivers/block/zram/zcomp_lzo.c > > -- > 1.9.0.rc3.256.g4af3ebd > > -- > 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/ -- Kind regards, Minchan Kim -- 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] rcu: move SRCU grace period work to power efficient workqueue
On Sun, 2014-02-16 at 08:41 -0800, Paul E. McKenney wrote: > So if there is NO_HZ_FULL, you have no objection to binding workqueues to > the timekeeping CPUs, but that you would also like some form of automatic > binding in the !NO_HZ_FULL case. Of course, if a common mechanism could > serve both cases, that would be good. And yes, cpusets are frowned upon > for some workloads. I'm not _objecting_, I'm not driving, Frederic's doing that ;-) That said, isolation seems to be turning into a property of nohz mode, but as I see it, nohz_full is an extension to generic isolation. > So maybe start with Kevin's patch, but augment with something else for > the !NO_HZ_FULL case? Sure (hm, does it work without workqueue.disable_numa ?). It just seems to me that tying it to sched domain construction would be a better fit. That way, it doesn't matter what your isolation requiring load is, whether you run a gaggle of realtime tasks or one HPC task your business, the generic requirement is isolation, not tick mode. For one HPC task per core, you want no tick, if you're running all SCHED_FIFO, maybe you want that too, depends on the impact of nohz_full mode. All sensitive loads want the isolation, but they may not like the price. I personally like the cpuset way. Being able to partition boxen on the fly makes them very flexible. In a perfect world, you'd be able to quiesce and configure offloading and nohz_full on the fly too, and not end up with some hodgepodge like this needs boot option foo, that happens invisibly because of config option bar, the other thing you have to do manually.. and you get to eat 937 kthreads and tons of overhead on all CPUs if you want the ability to _maybe_ run a critical task or two. -Mike -- 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] serial/uart: Add tunable RX interrupt trigger I/F of FIFO buffers
Add tunable RX interrupt trigger I/F of FIFO buffers.
Serial devices are used as not only message communication devices but control
or sending communication devices. For the latter uses, normally small data
will be exchanged, so user applications want to receive data unit as soon as
possible for real-time tendency. If we have a sensor which sends a 1 byte data
each time and must control a device based on the sensor feedback, the RX
interrupt should be triggered for each data.
According to HW specification of serial UART devices, RX interrupt trigger
can be changed, but the trigger is hard-coded. For example, RX interrupt trigger
in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets
the trigger to only 8bytes.
This patch makes a 16550A device change RX interrupt trigger from userland.
unsigned char rx_trig_byte = 1;
fd = open(TTY_PASS, O_RDWR | O_NONBLOCK);
ioctl(fd, TIOCSFIFOTRIG, rx_trig_byte);
read(fd, buf, size);
- 16550A (1, 4, 8, or 14 bytes)
Changed in V2:
- Use _IOW for TIOCSFIFORTRIG definition
- Pass the interrupt trigger value itself
Signed-off-by: Yoshihiro YUNOMAE
Cc: Greg Kroah-Hartman
---
drivers/tty/serial/8250/8250_core.c | 58 +++
include/uapi/asm-generic/ioctls.h |1 +
2 files changed, 59 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 61ecd70..429f3a6 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2699,6 +2699,63 @@ serial8250_verify_port(struct uart_port *port, struct
serial_struct *ser)
return 0;
}
+static int convert_val2rxtrig(struct uart_8250_port *up, unsigned char val)
+{
+ switch (up->port.type) {
+ case PORT_16550A:
+ if (val == 1)
+ return UART_FCR_R_TRIG_00;
+ else if (val == 4)
+ return UART_FCR_R_TRIG_01;
+ else if (val == 8)
+ return UART_FCR_R_TRIG_10;
+ else if (val == 14)
+ return UART_FCR_R_TRIG_11;
+ break;
+ default:
+ pr_info("Not support RX-trigger setting for this serial %u\n",
+ up->port.type);
+ }
+ return -EINVAL;
+}
+
+static int set_fifo_rx_trigger(struct uart_8250_port *up, unsigned char val)
+{
+ unsigned char fcr;
+ int rx_trig;
+
+ rx_trig = convert_val2rxtrig(up, val);
+ if (rx_trig < 0)
+ return rx_trig;
+
+ fcr = uart_config[up->port.type].fcr;
+ serial8250_clear_fifos(up);
+ fcr &= ~UART_FCR_TRIGGER_MASK;
+ fcr |= (unsigned char)rx_trig;
+ serial_out(up, UART_FCR, fcr);
+ return 0;
+}
+
+static int
+serial8250_ioctl(struct uart_port *port, unsigned int cmd, unsigned long arg)
+{
+ struct uart_8250_port *up =
+ container_of(port, struct uart_8250_port, port);
+ int ret;
+
+ if (!(up->capabilities & UART_CAP_FIFO) || port->fifosize <= 1)
+ return -EINVAL;
+
+ switch (cmd) {
+ case TIOCSFIFORTRIG:
+ ret = set_fifo_rx_trigger(up, (unsigned char)arg);
+ break;
+ default:
+ ret = -ENOIOCTLCMD;
+ }
+ return ret;
+}
+
static const char *
serial8250_type(struct uart_port *port)
{
@@ -2728,6 +2785,7 @@ static struct uart_ops serial8250_pops = {
.request_port = serial8250_request_port,
.config_port= serial8250_config_port,
.verify_port= serial8250_verify_port,
+ .ioctl = serial8250_ioctl,
#ifdef CONFIG_CONSOLE_POLL
.poll_get_char = serial8250_get_poll_char,
.poll_put_char = serial8250_put_poll_char,
diff --git a/include/uapi/asm-generic/ioctls.h
b/include/uapi/asm-generic/ioctls.h
index 143dacb..9504dca 100644
--- a/include/uapi/asm-generic/ioctls.h
+++ b/include/uapi/asm-generic/ioctls.h
@@ -77,6 +77,7 @@
#define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */
#define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
#define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */
+#define TIOCSFIFORTRIG _IOW('T', 0x41, unsigned char) /* Set RX int. trigger */
#define FIONCLEX 0x5450
#define FIOCLEX0x5451
--
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: imx: remove MACH_MXLADS
Воскресенье, 16 февраля 2014, 21:35 +01:00 от Paul Bolle :
> On Sun, 2014-02-16 at 23:21 +0400, Alexander Shiyan wrote:
> > Воскресенье, 16 февраля 2014, 20:12 +01:00 от Paul Bolle
> :
> > > On Sun, 2014-02-16 at 23:06 +0400, Alexander Shiyan wrote:
> > > > Kconfig selects MACH_MXLADS, this enables machine_arch_type
> > > > from include/generated/mach-types.h which used for machine_is_xx()
> macro,
> > > > so if multiple boards is defined in the kernel, this cause to incorrect
> > > matching.
> > >
> > > But, as I stated in the commit explanation, there are no users of
> > > machine_is_mxlads().
> >
> > If you have MXLADS and FOO boards support in the kernel (for example)
> > and you want to start MXLADS version, your machine_is_FOO() will be
> positive,
> > since machine_arch_type will be constant value FOO in this case.
>
> I think it might be helpful - for people trying to understand this
> thread - to add a quote from https://lkml.org/lkml/2013/3/8/473 :
> So, the result is that:
> - de-selected platforms have their if (machine_is_xxx()) { } optimised
> out of the kernel.
> - for a kernel built targetting one platform, all the
> if (machine_is_xxx()) tests are optimised away, leaving only the
> relevant code behind.
> - otherwise, we get the _appropriate_ conditional code for the
> configuration generated.
>
> Back to the issue at hand: without my patch ARCH_MX1ADS selects
> MACH_MXLADS. So it seems in this case people will have to select
> ARCH_MX1ADS besides selecting FOO. Wouldn't that solve this problem?
> Note that the MACH_MXLADS is now basically meant to be selected by
> ARCH_MX1ADS and not set directly anyway.
It seems that even in the current state, Kconfig for i.MX contains an error.
As a start, we should rename ARCH_MX1ADS to MACH_MX1ADS first.
---
[PATCH] arm: removed compiler warning
Removed this compiler warning for arch/arm/boot/compressed/atags_to_fdt.c. The warning was: 'memsize' may be used uninitialized in this function. Signed-off-by: John de la Garza --- arch/arm/boot/compressed/atags_to_fdt.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c index d1153c8..75b64da 100644 --- a/arch/arm/boot/compressed/atags_to_fdt.c +++ b/arch/arm/boot/compressed/atags_to_fdt.c @@ -110,7 +110,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) * address and size for each bank */ uint32_t mem_reg_property[2 * 2 * NR_BANKS]; int memcount = 0; - int ret, memsize; + int memsize = 0; + int ret; /* make sure we've got an aligned pointer */ if ((u32)atag_list & 0x3) -- 1.7.10.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: [tip:x86/vdso] x86, vdso: Instead of dummy functions, include < linux/spinlock_up.h>
On 02/16/2014 07:51 PM, tip-bot for H. Peter Anvin wrote: > Commit-ID: bd9ee7fd99f127ee1306289415141d45792c97f3 > Gitweb: http://git.kernel.org/tip/bd9ee7fd99f127ee1306289415141d45792c97f3 > Author: H. Peter Anvin > AuthorDate: Sun, 16 Feb 2014 19:47:01 -0800 > Committer: H. Peter Anvin > CommitDate: Sun, 16 Feb 2014 19:47:01 -0800 > > x86, vdso: Instead of dummy functions, include > > The list of dummy functions is insufficient. However, instead of > having a full list of dummy functions we can include > which contains the (trivial) implementations > that we use on uniprocessor. > > There aren't supposed to be any spinlocks at all in the VDSO, of > course. > That didn't work either. I thought I was clever, but it didn't work at all. Multiple build failures across numerous configurations. This is turning into a total headache. The "right" way to fix this is presumably to refactor a bunch of header files so that the vdso code doesn't have to include a bunch of kernel internal headers, but that is a lot of work. -hpa -- 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] sysfs: fix namespace refcnt leak
Hi Tejun,
I think we have to fix kernfs in order to fix refcnt leak in sysfs
and cgroupfs. This fix is for 3.14, but it creates conflicts for
cgroup-next.
As mount() and kill_sb() is not a one-to-one match, we shoudn't get
ns refcnt unconditionally in sysfs_mount(), and instead we should
get the refcnt only when kernfs_mount() allocated a new superblock.
Signed-off-by: Li Zefan
---
fs/kernfs/mount.c | 7 ++-
fs/sysfs/mount.c | 5 +++--
include/linux/kernfs.h | 9 +
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c
index 405279b..53ce420 100644
--- a/fs/kernfs/mount.c
+++ b/fs/kernfs/mount.c
@@ -132,6 +132,7 @@ const void *kernfs_super_ns(struct super_block *sb)
* @flags: mount flags specified for the mount
* @root: kernfs_root of the hierarchy being mounted
* @ns: optional namespace tag of the mount
+ * @new: tell the caller if we allocated a new superblock
*
* This is to be called from each kernfs user's file_system_type->mount()
* implementation, which should pass through the specified @fs_type and
@@ -141,12 +142,15 @@ const void *kernfs_super_ns(struct super_block *sb)
* The return value can be passed to the vfs layer verbatim.
*/
struct dentry *kernfs_mount_ns(struct file_system_type *fs_type, int flags,
- struct kernfs_root *root, const void *ns)
+ struct kernfs_root *root, const void *ns,
+ bool *new_sb)
{
struct super_block *sb;
struct kernfs_super_info *info;
int error;
+ *new_sb = false;
+
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return ERR_PTR(-ENOMEM);
@@ -166,6 +170,7 @@ struct dentry *kernfs_mount_ns(struct file_system_type
*fs_type, int flags,
return ERR_PTR(error);
}
sb->s_flags |= MS_ACTIVE;
+ *new_sb = true;
}
return dget(sb->s_root);
diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index 5c7fdd9..f5bea79 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -27,6 +27,7 @@ static struct dentry *sysfs_mount(struct file_system_type
*fs_type,
{
struct dentry *root;
void *ns;
+ bool new_sb;
if (!(flags & MS_KERNMOUNT)) {
if (!capable(CAP_SYS_ADMIN) && !fs_fully_visible(fs_type))
@@ -37,8 +38,8 @@ static struct dentry *sysfs_mount(struct file_system_type
*fs_type,
}
ns = kobj_ns_grab_current(KOBJ_NS_TYPE_NET);
- root = kernfs_mount_ns(fs_type, flags, sysfs_root, ns);
- if (IS_ERR(root))
+ root = kernfs_mount_ns(fs_type, flags, sysfs_root, ns, &new_sb);
+ if (IS_ERR(root) || !new_sb)
kobj_ns_drop(KOBJ_NS_TYPE_NET, ns);
return root;
}
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 649497a..1b1849f 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -279,7 +279,8 @@ void kernfs_notify(struct kernfs_node *kn);
const void *kernfs_super_ns(struct super_block *sb);
struct dentry *kernfs_mount_ns(struct file_system_type *fs_type, int flags,
- struct kernfs_root *root, const void *ns);
+ struct kernfs_root *root, const void *ns,
+ bool *new_sb);
void kernfs_kill_sb(struct super_block *sb);
void kernfs_init(void);
@@ -372,7 +373,7 @@ static inline const void *kernfs_super_ns(struct
super_block *sb)
static inline struct dentry *
kernfs_mount_ns(struct file_system_type *fs_type, int flags,
- struct kernfs_root *root, const void *ns)
+ struct kernfs_root *root, const void *ns, bool *new_sb)
{ return ERR_PTR(-ENOSYS); }
static inline void kernfs_kill_sb(struct super_block *sb) { }
@@ -430,9 +431,9 @@ static inline int kernfs_rename(struct kernfs_node *kn,
static inline struct dentry *
kernfs_mount(struct file_system_type *fs_type, int flags,
-struct kernfs_root *root)
+struct kernfs_root *root, bool *new_sb)
{
- return kernfs_mount_ns(fs_type, flags, root, NULL);
+ return kernfs_mount_ns(fs_type, flags, root, NULL, new_sb);
}
#endif /* __LINUX_KERNFS_H */
--
1.8.0.2
--
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/
[tip:x86/vdso] x86, vdso: Do conditional fixmap of VVAR and HPET page
Commit-ID: eccca441fe1f6b416a3592d764686edb9fbd2ac6
Gitweb: http://git.kernel.org/tip/eccca441fe1f6b416a3592d764686edb9fbd2ac6
Author: stef...@seibold.net
AuthorDate: Sun, 16 Feb 2014 22:52:48 +0100
Committer: H. Peter Anvin
CommitDate: Sun, 16 Feb 2014 19:48:52 -0800
x86, vdso: Do conditional fixmap of VVAR and HPET page
This patch adds conditional fixmap of the VVAR and HPET pages for the
32 bit kernel.
Signed-off-by: Stefani Seibold
Link:
http://lkml.kernel.org/r/1392587568-7325-11-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/vdso.h | 6 ++
arch/x86/kernel/hpet.c| 5 +
arch/x86/kernel/vsyscall_32.c | 4
arch/x86/vdso/vdso32-setup.c | 6 --
4 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index fe3cef9..6db8b23 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -1,6 +1,12 @@
#ifndef _ASM_X86_VDSO_H
#define _ASM_X86_VDSO_H
+enum {
+ VDSO_DISABLED = 0,
+ VDSO_ENABLED = 1,
+ VDSO_COMPAT = 2,
+};
+
#if defined CONFIG_X86_32 || defined CONFIG_COMPAT
#include
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 54263f0..b99544b 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#define HPET_MASK CLOCKSOURCE_MASK(32)
@@ -74,6 +75,10 @@ static inline void hpet_writel(unsigned int d, unsigned int
a)
static inline void hpet_set_mapping(void)
{
hpet_virt_address = ioremap_nocache(hpet_address, HPET_MMAP_SIZE);
+#ifdef CONFIG_X86_32
+ if (vdso_enabled != VDSO_COMPAT)
+ return;
+#endif
__set_fixmap(VSYSCALL_HPET, hpet_address, PAGE_KERNEL_VVAR_NOCACHE);
}
diff --git a/arch/x86/kernel/vsyscall_32.c b/arch/x86/kernel/vsyscall_32.c
index 4b94c47..0cbf94b 100644
--- a/arch/x86/kernel/vsyscall_32.c
+++ b/arch/x86/kernel/vsyscall_32.c
@@ -13,8 +13,12 @@
#include
#include
#include
+#include
void __init map_vsyscall(void)
{
+ if (vdso_enabled != VDSO_COMPAT)
+ return;
+
__set_fixmap(VVAR_PAGE, __pa_symbol(&__vvar_page), PAGE_KERNEL_VVAR);
}
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 9b57770..6b74a46 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -29,12 +29,6 @@
#include
#include
-enum {
- VDSO_DISABLED = 0,
- VDSO_ENABLED = 1,
- VDSO_COMPAT = 2,
-};
-
#ifdef CONFIG_COMPAT_VDSO
#define VDSO_DEFAULT VDSO_COMPAT
#else
--
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/
[tip:x86/vdso] x86, vdso: Instead of dummy functions, include < linux/spinlock_up.h>
Commit-ID: bd9ee7fd99f127ee1306289415141d45792c97f3
Gitweb: http://git.kernel.org/tip/bd9ee7fd99f127ee1306289415141d45792c97f3
Author: H. Peter Anvin
AuthorDate: Sun, 16 Feb 2014 19:47:01 -0800
Committer: H. Peter Anvin
CommitDate: Sun, 16 Feb 2014 19:47:01 -0800
x86, vdso: Instead of dummy functions, include
The list of dummy functions is insufficient. However, instead of
having a full list of dummy functions we can include
which contains the (trivial) implementations
that we use on uniprocessor.
There aren't supposed to be any spinlocks at all in the VDSO, of
course.
Cc: Stefani Seibold
Link:
http://lkml.kernel.org/r/1392587568-7325-10-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin
---
arch/x86/vdso/vdso32/vclock_gettime.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/x86/vdso/vdso32/vclock_gettime.c
b/arch/x86/vdso/vdso32/vclock_gettime.c
index 5de5057..2335f26 100644
--- a/arch/x86/vdso/vdso32/vclock_gettime.c
+++ b/arch/x86/vdso/vdso32/vclock_gettime.c
@@ -36,20 +36,12 @@
* a lot of warnings with make C=1.
* It is imposible not to include spinlock.h since most kernel headers does
* include it.
+ *
+ * includes the minimal functions which are used
+ * on UP; include it instead.
*/
#define _ASM_X86_SPINLOCK_H
-
-/*
- * dummys for unneeded arck_spin functions
- */
-static inline void arch_spin_unlock_wait(void *p)
-{
-}
-
-static inline int arch_spin_is_locked(void *p)
-{
- return 0;
-}
+#include
/*
* The define of CONFIG_ILLEGAL_POINTER_VALUE is also to prevent the
--
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: Get an online loan
Get an online loan at Skye Loan Finance Limited is favorably disposed to broker and facilitate the transfer of a Loan(s) to vise nominated account(s) of fund destination upon authentication and compliance of all procedural guidelines. Our loans are available from GBP 50,000.00, GBP 750,000.00 to GBP 950 Millions over 3-20 years at rates ranging from 3.5% to 6.5% APR E-mail: loanapplication_department2...@slf-online.com -- 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] sched: make sure sched-priority after invoke idle_balance()
On 02/14/2014 08:38 PM, Peter Zijlstra wrote:
[snip]
>>
>> This patch will prevent this happen by some rechecking after idle_balance(),
>> it
>> utilize the resched-flag for the case when RT/DL task was enqueued but don't
>> ask
>> for resched (will that ever happened?).
>
> I'm not sure this is actually working right; the problem is that while
> we do retry on need_resched() in the main schedule() loop, that last
> need_resched() is on @next (then current). So clearing/resetting @prev's
> need_resched() is not going to trigger that loop.
>
> Not to mention we explicitly clear @prev's need_resched right after
> pick_next_task().
Actually it's not aim at that timing, but consider about the RT case, it
won't work as expected anyway...
>
> So how about something like this?
>
> I don't particularly like adding that condition to pick_next_task(); but
> the alternative is recursively calling pick_next_task() and while
> recursion is strictly limited to the number of sched_classes, it does
> feel kinda icky.
Yeah...but it works, the RT stuff is inside the loop and really hard to
be handled...
>
> Anybody got any preferences?
>
> ---
> Subject: sched: Guarantee task priority in pick_next_task()
[snip]
> pick_next_task(struct rq *rq, struct task_struct *prev)
> {
> - const struct sched_class *class;
> + const struct sched_class *class = &fair_sched_class;
> struct task_struct *p;
>
> /*
>* Optimization: we know that if all tasks are in
>* the fair class we can call that function directly:
>*/
> - if (likely(prev->sched_class == &fair_sched_class &&
> + if (likely(prev->sched_class == class &&
> rq->nr_running == rq->cfs.h_nr_running)) {
> p = fair_sched_class.pick_next_task(rq, prev);
> if (likely(p))
> - return p;
> + goto got_task;
Since idle_balance() won't happen in the loop, may be we could use:
if p && p->sched_class == class
return p
in here, let it fall down into the loop if p is idle, since that means
we got RT/DL and will do this anyway, could save two jump work may be?
(and may could combine some code below if so?)
Regards,
Michael Wang
> }
>
> +again:
> for_each_class(class) {
> p = class->pick_next_task(rq, prev);
> if (p)
> - return p;
> + goto got_task;
> }
>
> BUG(); /* the idle class will always have a runnable task */
> +
> +got_task:
> + /*
> + * See pick_next_task_{fair,rt}(); they return rq->idle in case
> + * they want to re-start the task selection.
> + */
> + if (unlikely(p->sched_class != class))
> + goto again;
> +
> + return p;
> }
>
> /*
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4684,6 +4684,7 @@ pick_next_task_fair(struct rq *rq, struc
> struct cfs_rq *cfs_rq = &rq->cfs;
> struct sched_entity *se;
> struct task_struct *p;
> + int new_tasks;
>
> again:
> #ifdef CONFIG_FAIR_GROUP_SCHED
> @@ -4782,7 +4783,20 @@ pick_next_task_fair(struct rq *rq, struc
> return p;
>
> idle:
> - if (idle_balance(rq)) /* drops rq->lock */
> + /*
> + * Because idle_balance() releases (and re-acquires) rq->lock, it is
> + * possible for any higher priority task to appear. In that case we
> + * must re-start the pick_next_entity() loop.
> + */
> + new_tasks = idle_balance(rq);
> +
> + /*
> + * See pick_next_task(); we return rq->idle to restart task selection.
> + */
> + if (rq->nr_running != rq->cfs.h_nr_running)
> + return rq->idle;
> +
> + if (new_tasks)
> goto again;
>
> return NULL;
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -1360,8 +1360,16 @@ pick_next_task_rt(struct rq *rq, struct
> struct task_struct *p;
> struct rt_rq *rt_rq = &rq->rt;
>
> - if (need_pull_rt_task(rq, prev))
> + if (need_pull_rt_task(rq, prev)) {
> pull_rt_task(rq);
> + /*
> + * pull_rt_task() can drop (and re-acquire) rq->lock; this
> + * means a dl task can slip in, in which case we need to
> + * re-start task selection.
> + */
> + if (unlikely(rq->dl.dl_nr_running))
> + return rq->idle;
> + }
>
> if (!rt_rq->rt_nr_running)
> return NULL;
> --
> 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/
>
--
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.
Re: linux-next: build failure after merge of the mfd-lj tree
Hi Lee,
On Fri, 14 Feb 2014 13:42:17 +1100 Stephen Rothwell
wrote:
>
> After merging the mfd-lj tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/mfd/max665x.c:19:0:
> include/linux/mfd/max665x-private.h:31:1: error: expected ';', identifier or
> '(' before 'struct'
> struct max665x_dev {
> ^
>
> Caused by commit e77bb5297293 ("mfd: max665x: Differentiate between
> MAX665X devices"). Clearly never built by anyone :-(
>
> I have used the mfd-lj tree from next-20140210 again for today (since the
> other version had other problems).
Still seeing this error.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpRH8LWOl85z.pgp
Description: PGP signature
Re: Get an online loan
Get an online loan at Skye Loan Finance Limited is favorably disposed to broker and facilitate the transfer of a Loan(s) to vise nominated account(s) of fund destination upon authentication and compliance of all procedural guidelines. Our loans are available from GBP 50,000.00, GBP 750,000.00 to GBP 950 Millions over 3-20 years at rates ranging from 3.5% to 6.5% APR E-mail: loanapplication_department2...@slf-online.com -- 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] cgroup: add a validation check to cgroup_add_cftyps()
Fengguang reported this bug:
BUG: unable to handle kernel NULL pointer dereference at 003c
IP: [] cgroup_cfts_commit+0x27/0x1c1
...
Call Trace:
[] ? kmem_cache_alloc_trace+0x33f/0x3b7
[] cgroup_add_cftypes+0x8f/0xca
[] cgroup_init+0x6a/0x26a
[] start_kernel+0x4d7/0x57a
[] i386_start_kernel+0x92/0x96
This happens in a corner case. If CGROUP_SCHED=y but CFS_BANDWIDTH=n &&
FAIR_GROUP_SCHED=n && RT_GROUP_SCHED=n, we have:
cpu_files[] = {
{ } /* terminate */
}
When we pass cpu_files to cgroup_apply_cftypes(), as cpu_files[0].ss
is NULL, we'll access NULL pointer.
The bug was introduced by commit de00ffa56ea3132c6013fc8f07133b8a1014cf53
("cgroup: make cgroup_subsys->base_cftypes use cgroup_add_cftypes()").
Reported-by: Fengguang Wu
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index eaffc08..465c1d8 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2356,6 +2356,9 @@ int cgroup_add_cftypes(struct cgroup_subsys *ss, struct
cftype *cfts)
{
int ret;
+ if (!cfts || cfts[0].name[0] == '\0')
+ return 0;
+
ret = cgroup_init_cftypes(ss, cfts);
if (ret)
return ret;
--
1.8.0.2
--
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] printk: Fix discarding of records
On 2/16/14, 7:41 PM, "Linus Torvalds" wrote: >On Sun, Feb 16, 2014 at 4:19 PM, Banerjee, Debabrata > wrote: >> >> No that can't be right, the prev value after every loop is the >>msg->flags >> from the *last* line in the list, which has no relation to the *first*, >>so >> reusing it for the top of the next loop is nonsense. > >Please, Debabrata, humor me, and just try the patch. > >And try reading the source code. Because your statement is BS. ... >No, I haven't tested my patch, and maybe it's broken for some subtle >reason I'm missing too. Yes my explanation was wrong, your patch works for me. I assumed printing the prefix was desired, but if not, great. -Debabrata -- 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] mm: add a new command-line kmemcheck value
If we want to debug the kernel memory, we should turn on CONFIG_KMEMCHECK
and rebuild the kernel. This always takes a long time and sometimes
impossible, e.g. users don't have the kernel source code or the code
is different from "www.kernel.org" (private features may be added to the
kernel, and usually users can not get the whole code).
This patch adds a new command-line "kmemcheck=3", then the kernel will run
as the same as CONFIG_KMEMCHECK=off even CONFIG_KMEMCHECK is turn on.
"kmemcheck=0/1/2" is the same as originally. This means we can always turn
on CONFIG_KMEMCHECK, and use "kmemcheck=3" to control it on/off with out
rebuild the kernel.
In another word, "kmemcheck=3" is equivalent:
1) turn off CONFIG_KMEMCHECK
2) rebuild the kernel
3) reboot
The different between kmemcheck=0 and 3 is the used memory and nr_cpus.
Also kmemcheck=0 can used in runtime, and kmemcheck=3 is only used in boot.
boottime: kmemcheck=0/1/2/3 (command-line)
runtime: kmemcheck=0/1/2 (/proc/sys/kernel/kmemcheck)
Signed-off-by: Xishi Qiu
---
arch/x86/mm/init.c| 11 ++
arch/x86/mm/kmemcheck/kmemcheck.c | 62 ++---
arch/x86/mm/kmemcheck/shadow.c| 13 +---
include/linux/kmemcheck.h |2 +
mm/kmemcheck.c| 12 +--
mm/page_alloc.c |2 +
6 files changed, 76 insertions(+), 26 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index f971306..cd7d75f 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -135,6 +135,15 @@ static void __init probe_page_size_mask(void)
page_size_mask |= 1 << PG_LEVEL_2M;
#endif
+#if defined(CONFIG_KMEMCHECK)
+ if (!kmemcheck_on) {
+ if (direct_gbpages)
+ page_size_mask |= 1 << PG_LEVEL_1G;
+ if (cpu_has_pse)
+ page_size_mask |= 1 << PG_LEVEL_2M;
+ }
+#endif
+
/* Enable PSE if available */
if (cpu_has_pse)
set_in_cr4(X86_CR4_PSE);
@@ -331,6 +340,8 @@ bool pfn_range_is_mapped(unsigned long start_pfn, unsigned
long end_pfn)
return false;
}
+extern int kmemcheck_on;
+
/*
* Setup the direct mapping of the physical memory at PAGE_OFFSET.
* This runs before bootmem is initialized and gets pages directly from
diff --git a/arch/x86/mm/kmemcheck/kmemcheck.c
b/arch/x86/mm/kmemcheck/kmemcheck.c
index d87dd6d..d686ee0 100644
--- a/arch/x86/mm/kmemcheck/kmemcheck.c
+++ b/arch/x86/mm/kmemcheck/kmemcheck.c
@@ -44,30 +44,35 @@
#ifdef CONFIG_KMEMCHECK_ONESHOT_BY_DEFAULT
# define KMEMCHECK_ENABLED 2
#endif
+#define KMEMCHECK_CLOSED 3
-int kmemcheck_enabled = KMEMCHECK_ENABLED;
+int kmemcheck_enabled = KMEMCHECK_CLOSED;
+int kmemcheck_on = 0;
int __init kmemcheck_init(void)
{
+ if (kmemcheck_on) {
#ifdef CONFIG_SMP
- /*
-* Limit SMP to use a single CPU. We rely on the fact that this code
-* runs before SMP is set up.
-*/
- if (setup_max_cpus > 1) {
- printk(KERN_INFO
- "kmemcheck: Limiting number of CPUs to 1.\n");
- setup_max_cpus = 1;
- }
+ /*
+* Limit SMP to use a single CPU. We rely on the fact that this
code
+* runs before SMP is set up.
+*/
+ if (setup_max_cpus > 1) {
+ printk(KERN_INFO
+ "kmemcheck: Limiting number of CPUs to 1.\n");
+ setup_max_cpus = 1;
+ }
#endif
- if (!kmemcheck_selftest()) {
- printk(KERN_INFO "kmemcheck: self-tests failed; disabling\n");
- kmemcheck_enabled = 0;
- return -EINVAL;
+ if (!kmemcheck_selftest()) {
+ printk(KERN_INFO "kmemcheck: self-tests failed;
disabling\n");
+ kmemcheck_enabled = 0;
+ return -EINVAL;
+ }
+
+ printk(KERN_INFO "kmemcheck: Initialized\n");
}
- printk(KERN_INFO "kmemcheck: Initialized\n");
return 0;
}
@@ -82,6 +87,12 @@ static int __init param_kmemcheck(char *str)
return -EINVAL;
sscanf(str, "%d", &kmemcheck_enabled);
+
+ if ((kmemcheck_enabled >= KMEMCHECK_CLOSED) || (kmemcheck_enabled < 0))
+ kmemcheck_on = 0;
+ else
+ kmemcheck_on = 1;
+
return 0;
}
@@ -134,9 +145,12 @@ static DEFINE_PER_CPU(struct kmemcheck_context,
kmemcheck_context);
bool kmemcheck_active(struct pt_regs *regs)
{
- struct kmemcheck_context *data = &__get_cpu_var(kmemcheck_context);
+ if (kmemcheck_on) {
+ struct kmemcheck_context *data =
&__get_cpu_var(kmemcheck_context);
+ return data->balance > 0;
+ }
- return data->balance > 0;
+ return false;
}
/* Save an address that needs to be shown/hidden
Re: [PATCH 0/6] Marvell Armada 375 and 38x clocks drivers
On Mon, Feb 10, 2014 at 06:32:43PM +0100, Gregory CLEMENT wrote: > Hi Mike, > > Here are patches that add the clocks drivers for two new Marvell ARM > SOCs that belong to the mach-mvebu family: the Armada 375 and the > Armada 380/385. They are based on Cortex-A9 CPU cores, and share a > number of peripherals with their predecessors in the mach-mvebu > family. > > The drivers added are similar to the one already used for the other > SoCs of this family, as usual only the data are different the logic > remains the same ans allow us to use the common part. > > The core support (arch/arm/mach-mvebu) for these SOCs have just been > posted, and we're aiming at having this merged for 3.15 if possible. > > Thanks, > > Gregory > > Gregory CLEMENT (4): > clk: mvebu: add clock support for Armada 375 > dt: Update binding information for mvebu core clocks with Armada 375 > dt: Update binding information for mvebu gating clocks with Armada 375 > clk: mvebu: add clock support for Armada 380/385 > > Thomas Petazzoni (2): > dt: Update binding information for mvebu core clocks with Armada > 380/385 > dt: Update binding information for mvebu gating clocks with Armada > 380/385 > > .../devicetree/bindings/clock/mvebu-core-clock.txt | 14 ++ > .../bindings/clock/mvebu-gated-clock.txt | 65 +++- > drivers/clk/mvebu/Kconfig | 8 + > drivers/clk/mvebu/Makefile | 2 + > drivers/clk/mvebu/armada-375.c | 184 > + > drivers/clk/mvebu/armada-38x.c | 167 +++ > 6 files changed, 436 insertions(+), 4 deletions(-) > create mode 100644 drivers/clk/mvebu/armada-375.c > create mode 100644 drivers/clk/mvebu/armada-38x.c Hey guys, I've tentatively applied this series to mvebu/clk-3xx. I can't build test it until I pull in the core support. So I'll keep it separate from the regular clock driver changes just in case. thx, Jason. -- 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: manual merge of the libata tree with Linus' tree
Hi Tejun,
Today's linux-next merge of the libata tree got a conflict in
drivers/ata/sata_mv.c between commit 90aa2997029f ("ata: sata_mv: Fix
probe failures with optional phys") from Linus' tree and commit
8ad116e649b2 ("ata: sata_mv: Cleanup only the initialized ports") from
the libata tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/ata/sata_mv.c
index 52b8181ddafd,9c1a11de3044..
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@@ -4131,9 -4129,11 +4130,12 @@@ static int mv_platform_probe(struct pla
if (IS_ERR(hpriv->port_phys[port])) {
rc = PTR_ERR(hpriv->port_phys[port]);
hpriv->port_phys[port] = NULL;
- if ((rc != -EPROBE_DEFER) && (rc != -ENODEV))
- dev_warn(&pdev->dev, "error getting phy");
+ if (rc != -EPROBE_DEFER)
+ dev_warn(&pdev->dev, "error getting phy %d",
+ rc);
+
+ /* Cleanup only the initialized ports */
+ hpriv->n_ports = port;
goto err;
} else
phy_power_on(hpriv->port_phys[port]);
pgpQxE8YscR1K.pgp
Description: PGP signature
Re: [PATCH RESEND 0/3] mmc: rtsx: fix bug and support nonblocking request
Hi Micky, On Mon, Feb 17, 2014 at 10:00:54AM +0800, micky_ch...@realsil.com.cn wrote: > From: Micky Ching > > First we fix the card poweroff bug: the card power is not shutdown when sd/mmc > card removed, this will make UHS-card failed to running in high speed mode if > we > insert the card again. > > We offer a concise tuning searching method, it is much easier to read. > > At last we add support for nonblocking request, which will improve card read > speed at about 10% write speed about 5% normally. > > Micky Ching (3): > mmc: rtsx: fix card poweroff bug > mmc: rtsx: modify phase searching method for tuning > mmc: rtsx: add support for pre_req and post_req > > drivers/mfd/rtsx_pcr.c| 132 ++--- Please add Lee Jones (cc'ed) for MFD. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 0/5] Enabling the asynchronous threads for other phases
Hello Rafael, > -Original Message- > From: Liu, Chuansheng > Sent: Monday, February 17, 2014 9:44 AM > To: 'Rafael J. Wysocki' > Cc: gre...@linuxfoundation.org; pa...@ucw.cz; Brown, Len; > linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Li, Zhuangzhi > Subject: RE: [PATCH 0/5] Enabling the asynchronous threads for other phases > > Hello Rafael, > > > -Original Message- > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > > Sent: Monday, February 17, 2014 7:41 AM > > To: Liu, Chuansheng > > Cc: gre...@linuxfoundation.org; pa...@ucw.cz; Brown, Len; > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Li, Zhuangzhi > > Subject: Re: [PATCH 0/5] Enabling the asynchronous threads for other phases > > > > On Monday, February 10, 2014 08:36:57 AM Liu, Chuansheng wrote: > > > Hello Rafael, > > > > > > > -Original Message- > > > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > > > > Sent: Thursday, February 06, 2014 5:53 AM > > > > To: Liu, Chuansheng > > > > Cc: gre...@linuxfoundation.org; pa...@ucw.cz; Brown, Len; > > > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Li, Zhuangzhi > > > > Subject: Re: [PATCH 0/5] Enabling the asynchronous threads for other > > phases > > > > > > > > On Monday, January 20, 2014 04:44:34 PM Liu, Chuansheng wrote: > > > > > Hello, > > > > > > > > > > This patch series are for enabling the asynchronous threads for the > > phases > > > > > resume_noirq, resume_early, suspend_noirq and suspend_late. > > > > > > > > > > Just like commit 5af84b82701a and 97df8c12995, with async threads it > > will > > > > > reduce the system suspending and resuming time significantly. > > > > > > > > > > With these patches, in my test platform, it saved 80% time in > > resume_noirq > > > > > phase. > > > > > > > > > > Has done the suspend-resume stress test for a long time, please help > > > > > to > > > > > review. > > > > > > > > > > Best Regards, > > > > > > > > > > [PATCH 1/5] PM: Adding two flags for async suspend_noirq and > > > > > [PATCH 2/5] PM: Enabling the asynchronous threads for resume_noirq > > > > > [PATCH 3/5] PM: Enabling the asyncronous threads for resume_early > > > > > [PATCH 4/5] PM: Enabling the asyncronous threads for suspend_noirq > > > > > [PATCH 5/5] PM: Enabling the asyncronous threads for suspend_late > > > > > > > > I've applied this to the bleeding-edge branch of the linux-pm.git tree, > > > > with > > > > minor changes related to coding style, white space etc. > > > Thanks your help. > > > > Unfortunately, I've just realized that your patches don't add any mechanism > > ensuring that parent devices' .suspend_noirq() will be called *after* the > > .suspend_noirq() of all their children. Of course, analogously for > > .suspend_late() and for the resume part (where children have to wait for > > their parents). > > > > In the original async suspend/resume code that is implemented using > > power.completion and I suppose you can do the same thing here. > > I think "parent devices suspend after their children" is not related directly > with using async or not; > In the original code, even without asyncing, the suspend/resume has the > waiting > action, but there no waiting action for suspend_noirq and other phases. > Sorry, re-checked the code, the order in the list has made sure the sequence of parent-then-children when without asyncing. Thanks your pointing out, will re-cook this series patch.
Re: [PATCH 11/27] clocksource: sh_cmt: Add support for multiple channels per device
Hi Laurent,
On Mon, Feb 17, 2014 at 10:48 AM, Laurent Pinchart
wrote:
> Hi Magnus,
>
> On Monday 17 February 2014 10:41:31 Magnus Damm wrote:
>> On Mon, Feb 17, 2014 at 3:18 AM, Laurent Pinchart wrote:
>> > On Saturday 15 February 2014 13:46:54 Thomas Gleixner wrote:
>> >> On Fri, 14 Feb 2014, Laurent Pinchart wrote:
>> >> > CMT hardware devices can support multiple channels, with global
>> >> > registers and per-channel registers. The sh_cmt driver currently models
>> >> > the hardware with one Linux device per channel. This model makes it
>> >> > difficult to handle global registers in a clean way.
>> >> >
>> >> > Add support for a new model that uses one Linux device per timer with
>> >> > multiple channels per device. This requires changes to platform data,
>> >> > add new channel configuration fields.
>> >> >
>> >> > Support for the legacy model is kept and will be removed after all
>> >> > platforms switch to the new model.
>> >> >
>> >> > Signed-off-by: Laurent Pinchart
>> >> >
>> >> > ---
>> >> >
>> >> > drivers/clocksource/sh_cmt.c | 299 ++-
>> >> > include/linux/sh_timer.h | 9 ++
>> >> > 2 files changed, 239 insertions(+), 69 deletions(-)
>> >> >
>> >> > diff --git a/drivers/clocksource/sh_cmt.c
>> >> > b/drivers/clocksource/sh_cmt.c
>> >> > index 5280231..8390f0f 100644
>> >> > --- a/drivers/clocksource/sh_cmt.c
>> >> > +++ b/drivers/clocksource/sh_cmt.c
>
> [snip]
>
>> >> > @@ -85,11 +94,15 @@ struct sh_cmt_info {
>> >> >
>> >> > struct sh_cmt_channel {
>> >> > struct sh_cmt_device *cmt;
>> >> > - unsigned int index;
>> >> > - void __iomem *base;
>> >> > + unsigned int index; /* Index in the documentation */
>> >> > + unsigned int hwidx; /* Real hardware index */
>> >> > +
>> >> > + void __iomem *iostart;
>> >> > + void __iomem *ioctrl;
>> >> >
>> >> > struct irqaction irqaction;
>> >>
>> >> While you are at it, can you please get rid of that irqaction and use
>> >> request_irq() ?
>> >
>> > The driver claims it can't use request_irq() because the function is not
>> > available for early platform devices. If the situation has changed I'd
>> > gladly get rid of irqaction.
>>
>> With the risk of stating the obvious, this depends on how early the
>> early platform device stuff is being run. The actual location may not
>> be the same on SH and ARM for instance.
>>
>> On ARM we are doing all we can to initialize these devices as late as
>> ever possible in the MULTIPLAFORM (DT reference) case. Once we manage
>> to remove the legacy ARM case then there is one less user of early
>> platform timers.
>>
>> One perhaps reasonable way forward could be to use request_irq() in
>> case of DT and leave the legacy platform data case to rely on
>> irqaction.
>
> The whole point of switching from setup_irq() to request_irq() is to simplify
> the code. Adding request_irq() as an option would go in the opposite
> direction.
The point of switching to setup_irq() was not very clear to me. I
think it is fine to switch to using it over time, and I'm open to any
alternative ways forward. Usually moving in incremental steps means
more crap in the short term, but if someone could come up with a way
that involves little crap then I'm all for that! =)
Thanks,
/ magnus
--
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 RESEND 0/3] mmc: rtsx: fix bug and support nonblocking request
From: Micky Ching First we fix the card poweroff bug: the card power is not shutdown when sd/mmc card removed, this will make UHS-card failed to running in high speed mode if we insert the card again. We offer a concise tuning searching method, it is much easier to read. At last we add support for nonblocking request, which will improve card read speed at about 10% write speed about 5% normally. Micky Ching (3): mmc: rtsx: fix card poweroff bug mmc: rtsx: modify phase searching method for tuning mmc: rtsx: add support for pre_req and post_req drivers/mfd/rtsx_pcr.c| 132 ++--- drivers/mmc/host/rtsx_pci_sdmmc.c | 537 ++--- include/linux/mfd/rtsx_common.h |1 + include/linux/mfd/rtsx_pci.h |8 +- 4 files changed, 481 insertions(+), 197 deletions(-) -- 1.7.9.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 RESEND 2/3] mmc: rtsx: modify phase searching method for tuning
From: Micky Ching
The new phase searching method is more concise and easier to
understand.
Signed-off-by: Micky Ching
---
drivers/mmc/host/rtsx_pci_sdmmc.c | 112 +++--
include/linux/mfd/rtsx_pci.h |2 +-
2 files changed, 33 insertions(+), 81 deletions(-)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index c9a7328..7da270b 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -31,16 +31,6 @@
#include
#include
-/* SD Tuning Data Structure
- * Record continuous timing phase path
- */
-struct timing_phase_path {
- int start;
- int end;
- int mid;
- int len;
-};
-
struct realtek_pci_sdmmc {
struct platform_device *pdev;
struct rtsx_pcr *pcr;
@@ -511,85 +501,47 @@ static int sd_change_phase(struct realtek_pci_sdmmc *host,
return 0;
}
-static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32 phase_map)
+static inline u32 test_phase_bit(u32 phase_map, unsigned int bit)
{
- struct timing_phase_path path[MAX_PHASE + 1];
- int i, j, cont_path_cnt;
- int new_block, max_len, final_path_idx;
- u8 final_phase = 0xFF;
+ bit %= RTSX_PHASE_MAX;
+ return phase_map & (1 << bit);
+}
- /* Parse phase_map, take it as a bit-ring */
- cont_path_cnt = 0;
- new_block = 1;
- j = 0;
- for (i = 0; i < MAX_PHASE + 1; i++) {
- if (phase_map & (1 << i)) {
- if (new_block) {
- new_block = 0;
- j = cont_path_cnt++;
- path[j].start = i;
- path[j].end = i;
- } else {
- path[j].end = i;
- }
- } else {
- new_block = 1;
- if (cont_path_cnt) {
- /* Calculate path length and middle point */
- int idx = cont_path_cnt - 1;
- path[idx].len =
- path[idx].end - path[idx].start + 1;
- path[idx].mid =
- path[idx].start + path[idx].len / 2;
- }
- }
- }
+static int sd_get_phase_len(u32 phase_map, unsigned int start_bit)
+{
+ int i;
- if (cont_path_cnt == 0) {
- dev_dbg(sdmmc_dev(host), "No continuous phase path\n");
- goto finish;
- } else {
- /* Calculate last continuous path length and middle point */
- int idx = cont_path_cnt - 1;
- path[idx].len = path[idx].end - path[idx].start + 1;
- path[idx].mid = path[idx].start + path[idx].len / 2;
+ for (i = 0; i < RTSX_PHASE_MAX; i++) {
+ if (test_phase_bit(phase_map, start_bit + i) == 0)
+ return i;
}
+ return RTSX_PHASE_MAX;
+}
+
+static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32 phase_map)
+{
+ int start = 0, len = 0;
+ int start_final = 0, len_final = 0;
+ u8 final_phase = 0xFF;
- /* Connect the first and last continuous paths if they are adjacent */
- if (!path[0].start && (path[cont_path_cnt - 1].end == MAX_PHASE)) {
- /* Using negative index */
- path[0].start = path[cont_path_cnt - 1].start - MAX_PHASE - 1;
- path[0].len += path[cont_path_cnt - 1].len;
- path[0].mid = path[0].start + path[0].len / 2;
- /* Convert negative middle point index to positive one */
- if (path[0].mid < 0)
- path[0].mid += MAX_PHASE + 1;
- cont_path_cnt--;
+ if (phase_map == 0) {
+ dev_err(sdmmc_dev(host), "phase error: [map:%x]\n", phase_map);
+ return final_phase;
}
- /* Choose the longest continuous phase path */
- max_len = 0;
- final_phase = 0;
- final_path_idx = 0;
- for (i = 0; i < cont_path_cnt; i++) {
- if (path[i].len > max_len) {
- max_len = path[i].len;
- final_phase = (u8)path[i].mid;
- final_path_idx = i;
+ while (start < RTSX_PHASE_MAX) {
+ len = sd_get_phase_len(phase_map, start);
+ if (len_final < len) {
+ start_final = start;
+ len_final = len;
}
-
- dev_dbg(sdmmc_dev(host), "path[%d].start = %d\n",
- i, path[i].start);
- dev_dbg(sdmmc_dev(host), "path[%d].end = %d\n",
- i, path[i].end);
- dev_dbg(sdmmc_dev(host), "path[%d].len = %d\n",
-
[PATCH RESEND 1/3] mmc: rtsx: fix card poweroff bug
From: Micky Ching
If the host driver removed while card in the slot, the host will not
power off card power correctly. This bug is produced because host
eject flag set before the last mmc_set_ios callback, we should set the
eject flag after power off.
Signed-off-by: Micky Ching
---
drivers/mmc/host/rtsx_pci_sdmmc.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 375a880e..c9a7328 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -1328,7 +1328,6 @@ static int rtsx_pci_sdmmc_drv_remove(struct
platform_device *pdev)
pcr->slots[RTSX_SD_CARD].p_dev = NULL;
pcr->slots[RTSX_SD_CARD].card_event = NULL;
mmc = host->mmc;
- host->eject = true;
mutex_lock(&host->host_mutex);
if (host->mrq) {
@@ -1346,6 +1345,8 @@ static int rtsx_pci_sdmmc_drv_remove(struct
platform_device *pdev)
mutex_unlock(&host->host_mutex);
mmc_remove_host(mmc);
+ host->eject = true;
+
mmc_free_host(mmc);
dev_dbg(&(pdev->dev),
--
1.7.9.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 RESEND 3/3] mmc: rtsx: add support for pre_req and post_req
From: Micky Ching
Add support for non-blocking request, pre_req() runs dma_map_sg() and
post_req() runs dma_unmap_sg(). This patch can increase card read/write
speed, especially for high speed card and slow CPU(for some embedded
platform).
Users can get a great benefit from this patch. if CPU frequency is 800MHz,
SDR104 or DDR50 card read/write speed may increase more than 15%.
test results:
intel i3(800MHz - 2.3GHz), SD card clock 208MHz
performance mode(2.3GHz):
Before:
dd if=/dev/mmcblk0p1 of=/dev/null bs=64k count=1024
67108864 bytes (67 MB) copied, 1.18191 s, 56.8 MB/s
After:
dd if=/dev/mmcblk0p1 of=/dev/null bs=64k count=1024
67108864 bytes (67 MB) copied, 1.09276 s, 61.4 MB/s
powersave mode(800MHz):
Before:
dd if=/dev/mmcblk0p1 of=/dev/null bs=64k count=1024
67108864 bytes (67 MB) copied, 1.29569 s, 51.8 MB/s
After:
dd if=/dev/mmcblk0p1 of=/dev/null bs=64k count=1024
67108864 bytes (67 MB) copied, 1.11218 s, 60.3 MB/s
Signed-off-by: Micky Ching
---
drivers/mfd/rtsx_pcr.c| 132
drivers/mmc/host/rtsx_pci_sdmmc.c | 426 ++---
include/linux/mfd/rtsx_common.h |1 +
include/linux/mfd/rtsx_pci.h |6 +
4 files changed, 448 insertions(+), 117 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 2af55bb..d21c894 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -338,58 +338,28 @@ int rtsx_pci_transfer_data(struct rtsx_pcr *pcr, struct
scatterlist *sglist,
int num_sg, bool read, int timeout)
{
struct completion trans_done;
- u8 dir;
- int err = 0, i, count;
+ int err = 0, count;
long timeleft;
unsigned long flags;
- struct scatterlist *sg;
- enum dma_data_direction dma_dir;
- u32 val;
- dma_addr_t addr;
- unsigned int len;
-
- dev_dbg(&(pcr->pci->dev), "--> %s: num_sg = %d\n", __func__, num_sg);
-
- /* don't transfer data during abort processing */
- if (pcr->remove_pci)
- return -EINVAL;
-
- if ((sglist == NULL) || (num_sg <= 0))
- return -EINVAL;
- if (read) {
- dir = DEVICE_TO_HOST;
- dma_dir = DMA_FROM_DEVICE;
- } else {
- dir = HOST_TO_DEVICE;
- dma_dir = DMA_TO_DEVICE;
- }
-
- count = dma_map_sg(&(pcr->pci->dev), sglist, num_sg, dma_dir);
+ count = rtsx_pci_dma_map_sg(pcr, sglist, num_sg, read);
if (count < 1) {
dev_err(&(pcr->pci->dev), "scatterlist map failed\n");
return -EINVAL;
}
dev_dbg(&(pcr->pci->dev), "DMA mapping count: %d\n", count);
- val = ((u32)(dir & 0x01) << 29) | TRIG_DMA | ADMA_MODE;
- pcr->sgi = 0;
- for_each_sg(sglist, sg, count, i) {
- addr = sg_dma_address(sg);
- len = sg_dma_len(sg);
- rtsx_pci_add_sg_tbl(pcr, addr, len, i == count - 1);
- }
spin_lock_irqsave(&pcr->lock, flags);
pcr->done = &trans_done;
pcr->trans_result = TRANS_NOT_READY;
init_completion(&trans_done);
- rtsx_pci_writel(pcr, RTSX_HDBAR, pcr->host_sg_tbl_addr);
- rtsx_pci_writel(pcr, RTSX_HDBCTLR, val);
spin_unlock_irqrestore(&pcr->lock, flags);
+ rtsx_pci_dma_transfer(pcr, sglist, count, read);
+
timeleft = wait_for_completion_interruptible_timeout(
&trans_done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
@@ -413,7 +383,7 @@ out:
pcr->done = NULL;
spin_unlock_irqrestore(&pcr->lock, flags);
- dma_unmap_sg(&(pcr->pci->dev), sglist, num_sg, dma_dir);
+ rtsx_pci_dma_unmap_sg(pcr, sglist, num_sg, read);
if ((err < 0) && (err != -ENODEV))
rtsx_pci_stop_cmd(pcr);
@@ -425,6 +395,73 @@ out:
}
EXPORT_SYMBOL_GPL(rtsx_pci_transfer_data);
+int rtsx_pci_dma_map_sg(struct rtsx_pcr *pcr, struct scatterlist *sglist,
+ int num_sg, bool read)
+{
+ enum dma_data_direction dir = read ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ if (pcr->remove_pci)
+ return -EINVAL;
+
+ if ((sglist == NULL) || num_sg < 1)
+ return -EINVAL;
+
+ return dma_map_sg(&(pcr->pci->dev), sglist, num_sg, dir);
+}
+EXPORT_SYMBOL_GPL(rtsx_pci_dma_map_sg);
+
+int rtsx_pci_dma_unmap_sg(struct rtsx_pcr *pcr, struct scatterlist *sglist,
+ int num_sg, bool read)
+{
+ enum dma_data_direction dir = read ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ if (pcr->remove_pci)
+ return -EINVAL;
+
+ if (sglist == NULL || num_sg < 1)
+ return -EINVAL;
+
+ dma_unmap_sg(&(pcr->pci->dev), sglist, num_sg, dir);
+ return num_sg;
+}
+EXPORT_SYMBOL_GPL(rtsx_pci_dma_unmap_sg);
+
+int rtsx_pci_dma_transfer(struct rtsx_pcr *pcr, struct scatterlist *sglist,
+ int sg_count, bool read)
+{
+ struct scatterlist
[PATCH v2 10/11] sched: rename update_*_cpu_load
Since we have no cpu_load update, rename the related functions:
s/update_idle_cpu_load/update_idle_rt_avg/
s/update_cpu_load_nohz/update_rt_avg_nohz/
s/update_cpu_load_active/update_avg_load_active/
No functional change.
Signed-off-by: Alex Shi
---
Documentation/trace/ftrace.txt | 8
include/linux/sched.h | 2 +-
kernel/sched/core.c| 2 +-
kernel/sched/fair.c| 2 +-
kernel/sched/proc.c| 8
kernel/sched/sched.h | 4 ++--
kernel/time/tick-sched.c | 2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index bd36598..2fe46b5 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -1542,12 +1542,12 @@ Doing the same with chrt -r 5 and function-trace set.
-0 3dN.1 12us : menu_hrtimer_cancel <-tick_nohz_idle_exit
-0 3dN.1 12us : ktime_get <-tick_nohz_idle_exit
-0 3dN.1 12us : tick_do_update_jiffies64 <-tick_nohz_idle_exit
- -0 3dN.1 13us : update_cpu_load_nohz <-tick_nohz_idle_exit
- -0 3dN.1 13us : _raw_spin_lock <-update_cpu_load_nohz
+ -0 3dN.1 13us : update_rt_avg_nohz <-tick_nohz_idle_exit
+ -0 3dN.1 13us : _raw_spin_lock <-update_rt_avg_nohz
-0 3dN.1 13us : add_preempt_count <-_raw_spin_lock
- -0 3dN.2 13us : __update_cpu_load <-update_cpu_load_nohz
+ -0 3dN.2 13us : __update_cpu_load <-update_rt_avg_nohz
-0 3dN.2 14us : sched_avg_update <-__update_cpu_load
- -0 3dN.2 14us : _raw_spin_unlock <-update_cpu_load_nohz
+ -0 3dN.2 14us : _raw_spin_unlock <-update_rt_avg_nohz
-0 3dN.2 14us : sub_preempt_count <-_raw_spin_unlock
-0 3dN.1 15us : calc_load_exit_idle <-tick_nohz_idle_exit
-0 3dN.1 15us : touch_softlockup_watchdog <-tick_nohz_idle_exit
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6c416c8..f6afcb3 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -174,7 +174,7 @@ extern unsigned long this_cpu_load(void);
extern void calc_global_load(unsigned long ticks);
-extern void update_cpu_load_nohz(void);
+extern void update_rt_avg_nohz(void);
extern unsigned long get_parent_ip(unsigned long addr);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 32602595..74dae0e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2431,7 +2431,7 @@ void scheduler_tick(void)
raw_spin_lock(&rq->lock);
update_rq_clock(rq);
curr->sched_class->task_tick(rq, curr, 0);
- update_cpu_load_active(rq);
+ update_avg_load_active(rq);
raw_spin_unlock(&rq->lock);
perf_event_task_tick();
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6c37ee1..1b008ac 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6986,7 +6986,7 @@ static void nohz_idle_balance(struct rq *this_rq, enum
cpu_idle_type idle)
raw_spin_lock_irq(&rq->lock);
update_rq_clock(rq);
- update_idle_cpu_load(rq);
+ update_idle_rt_avg(rq);
raw_spin_unlock_irq(&rq->lock);
rebalance_domains(rq, CPU_IDLE);
diff --git a/kernel/sched/proc.c b/kernel/sched/proc.c
index dd3c2d9..42b7706 100644
--- a/kernel/sched/proc.c
+++ b/kernel/sched/proc.c
@@ -423,7 +423,7 @@ static void calc_load_account_active(struct rq *this_rq)
* Called from nohz_idle_balance() to update the load ratings before doing the
* idle balance.
*/
-void update_idle_cpu_load(struct rq *this_rq)
+void update_idle_rt_avg(struct rq *this_rq)
{
unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
@@ -440,17 +440,17 @@ void update_idle_cpu_load(struct rq *this_rq)
/*
* Called from tick_nohz_idle_exit()
*/
-void update_cpu_load_nohz(void)
+void update_rt_avg_nohz(void)
{
struct rq *this_rq = this_rq();
- update_idle_cpu_load(this_rq);
+ update_idle_rt_avg(this_rq);
}
#endif /* CONFIG_NO_HZ */
/*
* Called from scheduler_tick()
*/
-void update_cpu_load_active(struct rq *this_rq)
+void update_avg_load_active(struct rq *this_rq)
{
this_rq->last_load_update_tick = jiffies;
sched_avg_update(this_rq);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index c623131..ab310c2 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -21,7 +21,7 @@ extern unsigned long calc_load_update;
extern atomic_long_t calc_load_tasks;
extern long calc_load_fold_active(struct rq *this_rq);
-extern void update_cpu_load_active(struct rq *this_rq);
+extern void update_avg_load_active(struct rq *this_rq);
/*
* Helpers for converting nanosecond timing to jiffy resolution
@@ -1194,7 +1194,7 @@ extern void init_dl_task_timer(struct sched_dl_entity
*dl_se);
unsigned long to_ratio(u64 period, u64 runtime);
-extern void update_idle_cpu_load(struct rq *this_rq);
+extern void update_idle_rt
[PATCH v2 11/11] sched: clean up task_hot function
task_hot doesn't need the 'sched_domain' parameter, so remove it.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1b008ac..e81a790 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5003,7 +5003,7 @@ static void move_task(struct task_struct *p, struct
lb_env *env)
* Is this task likely cache-hot:
*/
static int
-task_hot(struct task_struct *p, u64 now, struct sched_domain *sd)
+task_hot(struct task_struct *p, u64 now)
{
s64 delta;
@@ -5164,7 +5164,7 @@ int can_migrate_task(struct task_struct *p, struct lb_env
*env)
* 2) task is cache cold, or
* 3) too many balance attempts have failed.
*/
- tsk_cache_hot = task_hot(p, rq_clock_task(env->src_rq), env->sd);
+ tsk_cache_hot = task_hot(p, rq_clock_task(env->src_rq));
if (!tsk_cache_hot)
tsk_cache_hot = migrate_degrades_locality(p, env);
--
1.8.1.2
--
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 09/11] sched: remove rq->cpu_load and rq->nr_load_updates
The cpu_load is the copy of rq->cfs.runnable_load_avg. And it updated
on time. So we can use the latter directly. Thus saved 2 rq variables:
cpu_load and nr_load_updates.
Then don't need __update_cpu_load(), just keep sched_avg_update().
Thus removed get_rq_runnable_load() which used for update_cpu_load only.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 2 --
kernel/sched/debug.c | 2 --
kernel/sched/proc.c | 55 +---
kernel/sched/sched.h | 2 --
4 files changed, 13 insertions(+), 48 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ac2f10c..32602595 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6800,8 +6800,6 @@ void __init sched_init(void)
INIT_LIST_HEAD(&rq->leaf_rt_rq_list);
init_tg_rt_entry(&root_task_group, &rq->rt, NULL, i, NULL);
#endif
-
- rq->cpu_load = 0;
rq->last_load_update_tick = jiffies;
#ifdef CONFIG_SMP
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index a24d549..83737ce 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -298,12 +298,10 @@ do {
\
SEQ_printf(m, " .%-30s: %lu\n", "load",
rq->load.weight);
P(nr_switches);
- P(nr_load_updates);
P(nr_uninterruptible);
PN(next_balance);
SEQ_printf(m, " .%-30s: %ld\n", "curr->pid",
(long)(task_pid_nr(rq->curr)));
PN(clock);
- P(cpu_load);
#undef P
#undef PN
diff --git a/kernel/sched/proc.c b/kernel/sched/proc.c
index 383c4ba..dd3c2d9 100644
--- a/kernel/sched/proc.c
+++ b/kernel/sched/proc.c
@@ -8,12 +8,19 @@
#include "sched.h"
+#ifdef CONFIG_SMP
unsigned long this_cpu_load(void)
{
- struct rq *this = this_rq();
- return this->cpu_load;
+ struct rq *rq = this_rq();
+ return rq->cfs.runnable_load_avg;
}
-
+#else
+unsigned long this_cpu_load(void)
+{
+ struct rq *rq = this_rq();
+ return rq->load.weight;
+}
+#endif
/*
* Global load-average calculations
@@ -398,34 +405,6 @@ static void calc_load_account_active(struct rq *this_rq)
* End of global load-average stuff
*/
-
-/*
- * Update rq->cpu_load statistics. This function is usually called every
- * scheduler tick (TICK_NSEC). With tickless idle this will not be called
- * every tick. We fix it up based on jiffies.
- */
-static void __update_cpu_load(struct rq *this_rq, unsigned long this_load)
-{
- this_rq->nr_load_updates++;
-
- /* Update our load: */
- this_rq->cpu_load = this_load; /* Fasttrack for idx 0 */
-
- sched_avg_update(this_rq);
-}
-
-#ifdef CONFIG_SMP
-static inline unsigned long get_rq_runnable_load(struct rq *rq)
-{
- return rq->cfs.runnable_load_avg;
-}
-#else
-static inline unsigned long get_rq_runnable_load(struct rq *rq)
-{
- return rq->load.weight;
-}
-#endif
-
#ifdef CONFIG_NO_HZ_COMMON
/*
* There is no sane way to deal with nohz on smp when using jiffies because the
@@ -447,17 +426,15 @@ static inline unsigned long get_rq_runnable_load(struct
rq *rq)
void update_idle_cpu_load(struct rq *this_rq)
{
unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
- unsigned long load = get_rq_runnable_load(this_rq);
/*
* bail if there's load or we're actually up-to-date.
*/
- if (load || curr_jiffies == this_rq->last_load_update_tick)
+ if (curr_jiffies == this_rq->last_load_update_tick)
return;
this_rq->last_load_update_tick = curr_jiffies;
-
- __update_cpu_load(this_rq, load);
+ sched_avg_update(this_rq);
}
/*
@@ -466,7 +443,6 @@ void update_idle_cpu_load(struct rq *this_rq)
void update_cpu_load_nohz(void)
{
struct rq *this_rq = this_rq();
-
update_idle_cpu_load(this_rq);
}
#endif /* CONFIG_NO_HZ */
@@ -476,12 +452,7 @@ void update_cpu_load_nohz(void)
*/
void update_cpu_load_active(struct rq *this_rq)
{
- unsigned long load = get_rq_runnable_load(this_rq);
- /*
-* See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
-*/
this_rq->last_load_update_tick = jiffies;
- __update_cpu_load(this_rq, load);
-
+ sched_avg_update(this_rq);
calc_load_account_active(this_rq);
}
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 5b2d4a1..c623131 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -517,7 +517,6 @@ struct rq {
unsigned int nr_numa_running;
unsigned int nr_preferred_running;
#endif
- unsigned long cpu_load;
unsigned long last_load_update_tick;
#ifdef CONFIG_NO_HZ_COMMON
u64 nohz_stamp;
@@ -530,7 +529,6 @@ struct rq {
/* capture load from *all* tasks on this cpu: */
struct load_weight load;
- unsigned long nr_load_updates;
u64 nr_switches;
struct cfs_rq cfs;
--
[PATCH v2 07/11] sched: clean up weighted_cpuload
weighted_cpuload is used instead of source_load() when !idx.
Now idx is always 0. so unify the usage to soruce_load. That make
code more readable.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2da0e3b..5cdc838 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1045,7 +1045,7 @@ static void update_numa_stats(struct numa_stats *ns, int
nid)
struct rq *rq = cpu_rq(cpu);
ns->nr_running += rq->nr_running;
- ns->load += weighted_cpuload(cpu);
+ ns->load += source_load(cpu);
ns->power += power_of(cpu);
cpus++;
@@ -3940,7 +3940,7 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
#ifdef CONFIG_SMP
/* Used instead of source_load when we know the type == 0 */
-static unsigned long weighted_cpuload(const int cpu)
+static inline unsigned long weighted_cpuload(const int cpu)
{
return cpu_rq(cpu)->cfs.runnable_load_avg;
}
@@ -4324,7 +4324,7 @@ find_idlest_cpu(struct sched_group *group, struct
task_struct *p, int this_cpu)
/* Traverse only the allowed CPUs */
for_each_cpu_and(i, sched_group_cpus(group), tsk_cpus_allowed(p)) {
- load = weighted_cpuload(i);
+ load = source_load(i);
if (load < min_load || (load == min_load && i == this_cpu)) {
min_load = load;
@@ -5762,7 +5762,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
sgs->nr_numa_running += rq->nr_numa_running;
sgs->nr_preferred_running += rq->nr_preferred_running;
#endif
- sgs->sum_weighted_load += weighted_cpuload(i);
+ sgs->sum_weighted_load += source_load(i);
if (idle_cpu(i))
sgs->idle_cpus++;
}
@@ -6248,10 +6248,10 @@ static struct rq *find_busiest_queue(struct lb_env *env,
if (!capacity)
capacity = fix_small_capacity(env->sd, group);
- wl = weighted_cpuload(i);
+ wl = source_load(i);
/*
-* When comparing with imbalance, use weighted_cpuload()
+* When comparing with imbalance, use source_load()
* which is not scaled with the cpu power.
*/
if (capacity && rq->nr_running == 1 && wl > env->imbalance)
@@ -6259,7 +6259,7 @@ static struct rq *find_busiest_queue(struct lb_env *env,
/*
* For the load comparisons with the other cpu's, consider
-* the weighted_cpuload() scaled with the cpu power, so that
+* the source_load() scaled with the cpu power, so that
* the load can be moved away from the cpu that is potentially
* running at a lower capacity.
*
--
1.8.1.2
--
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 08/11] sched: remove weighted_load()
Although weighted_load is a inline founction, it's not needed in fact.
so remove it.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5cdc838..6c37ee1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3939,31 +3939,16 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
}
#ifdef CONFIG_SMP
-/* Used instead of source_load when we know the type == 0 */
-static inline unsigned long weighted_cpuload(const int cpu)
-{
- return cpu_rq(cpu)->cfs.runnable_load_avg;
-}
-
-/*
- * Return a low guess at the load of a migration-source cpu weighted
- * according to the scheduling class and "nice" value.
- *
- * We want to under-estimate the load of migration sources, to
- * balance conservatively.
- */
+/* Return the real load of 'cpu' */
static unsigned long source_load(int cpu)
{
- return weighted_cpuload(cpu);
+ return cpu_rq(cpu)->cfs.runnable_load_avg;
}
-/*
- * Return a high guess at the load of a migration-target cpu weighted
- * according to the scheduling class and "nice" value.
- */
+/* Return a high bias at the load of a migration-target cpu weighted */
static unsigned long target_load(int cpu, int imbalance_pct)
{
- unsigned long total = weighted_cpuload(cpu);
+ unsigned long total = cpu_rq(cpu)->cfs.runnable_load_avg;
if (!sched_feat(LB_BIAS))
return total;
--
1.8.1.2
--
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 04/11] sched: unify imbalance bias for target group
Old code considers the bias in source/target_load already. but still
use imbalance_pct as last check in idlest/busiest group finding. It is
also a kind of redundant job. If we bias imbalance in source/target_load,
we'd better not use imbalance_pct again.
After cpu_load array removed, it is nice time to unify the target bias
consideration. So I remove the imbalance_pct from last check and add the
live bias using.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index eeffe75..a85a10b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1016,7 +1016,7 @@ bool should_numa_migrate_memory(struct task_struct *p,
struct page * page,
static unsigned long weighted_cpuload(const int cpu);
static unsigned long source_load(int cpu);
-static unsigned long target_load(int cpu);
+static unsigned long target_load(int cpu, int imbalance_pct);
static unsigned long power_of(int cpu);
static long effective_load(struct task_group *tg, int cpu, long wl, long wg);
@@ -3967,7 +3967,7 @@ static unsigned long source_load(int cpu)
* Return a high guess at the load of a migration-target cpu weighted
* according to the scheduling class and "nice" value.
*/
-static unsigned long target_load(int cpu)
+static unsigned long target_load(int cpu, int imbalance_pct)
{
struct rq *rq = cpu_rq(cpu);
unsigned long total = weighted_cpuload(cpu);
@@ -3975,6 +3975,11 @@ static unsigned long target_load(int cpu)
if (!sched_feat(LB_BIAS))
return total;
+ /*
+* Bias target load with imbalance_pct.
+*/
+ total = total * imbalance_pct / 100;
+
return max(rq->cpu_load, total);
}
@@ -4180,6 +4185,7 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
struct task_group *tg;
unsigned long weight;
int balanced;
+ int bias = 100 + (sd->imbalance_pct - 100) / 2;
/*
* If we wake multiple tasks be careful to not bounce
@@ -4191,7 +4197,7 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
this_cpu = smp_processor_id();
prev_cpu = task_cpu(p);
load = source_load(prev_cpu);
- this_load = target_load(this_cpu);
+ this_load = target_load(this_cpu, bias);
/*
* If sync wakeup then subtract the (maximum possible)
@@ -4226,7 +4232,7 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
this_eff_load *= this_load +
effective_load(tg, this_cpu, weight, weight);
- prev_eff_load = 100 + (sd->imbalance_pct - 100) / 2;
+ prev_eff_load = bias;
prev_eff_load *= power_of(this_cpu);
prev_eff_load *= load + effective_load(tg, prev_cpu, 0, weight);
@@ -4247,7 +4253,8 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
if (balanced ||
(this_load <= load &&
-this_load + target_load(prev_cpu) <= tl_per_task)) {
+this_load + target_load(prev_cpu, sd->imbalance_pct)
+ <= tl_per_task)) {
/*
* This domain has SD_WAKE_AFFINE and
* p is cache cold in this domain, and
@@ -4293,7 +4300,7 @@ find_idlest_group(struct sched_domain *sd, struct
task_struct *p, int this_cpu)
if (local_group)
load = source_load(i);
else
- load = target_load(i);
+ load = target_load(i, imbalance);
avg_load += load;
}
@@ -4309,7 +4316,7 @@ find_idlest_group(struct sched_domain *sd, struct
task_struct *p, int this_cpu)
}
} while (group = group->next, group != sd->groups);
- if (!idlest || 100*this_load < imbalance*min_load)
+ if (!idlest || this_load < min_load)
return NULL;
return idlest;
}
@@ -5745,6 +5752,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
{
unsigned long load;
int i;
+ int bias = 100 + (env->sd->imbalance_pct - 100) / 2;
memset(sgs, 0, sizeof(*sgs));
@@ -5752,8 +5760,8 @@ static inline void update_sg_lb_stats(struct lb_env *env,
struct rq *rq = cpu_rq(i);
/* Bias balancing toward cpus of our domain */
- if (local_group)
- load = target_load(i);
+ if (local_group && env->idle != CPU_IDLE)
+ load = target_load(i, bias);
else
load = source_load(i);
@@ -6193,14 +6201,6 @@ static struct sched_group *find_busiest_group(struct
lb_env *env)
if
[PATCH v2 05/11] sched: rewrite update_cpu_load_nohz
After change to sched_avg, the cpu load in idle exit was decayed.
So, it maybe near zero if waking a long time sleep task, or, a full
non-decay load if waking a new forked task. Then, we can use it to
reflect the cpu load, don't need to pretend 0.
Signed-off-by: Alex Shi
---
kernel/sched/proc.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/kernel/sched/proc.c b/kernel/sched/proc.c
index 057bb9b..383c4ba 100644
--- a/kernel/sched/proc.c
+++ b/kernel/sched/proc.c
@@ -461,28 +461,13 @@ void update_idle_cpu_load(struct rq *this_rq)
}
/*
- * Called from tick_nohz_idle_exit() -- try and fix up the ticks we missed.
+ * Called from tick_nohz_idle_exit()
*/
void update_cpu_load_nohz(void)
{
struct rq *this_rq = this_rq();
- unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
- unsigned long pending_updates;
-
- if (curr_jiffies == this_rq->last_load_update_tick)
- return;
- raw_spin_lock(&this_rq->lock);
- pending_updates = curr_jiffies - this_rq->last_load_update_tick;
- if (pending_updates) {
- this_rq->last_load_update_tick = curr_jiffies;
- /*
-* We were idle, this means load 0, the current load might be
-* !0 due to remote wakeups and the sort.
-*/
- __update_cpu_load(this_rq, 0);
- }
- raw_spin_unlock(&this_rq->lock);
+ update_idle_cpu_load(this_rq);
}
#endif /* CONFIG_NO_HZ */
--
1.8.1.2
--
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 06/11] sched: clean up source_load/target_load
Don't need 'rq' variable now.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a85a10b..2da0e3b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3954,13 +3954,7 @@ static unsigned long weighted_cpuload(const int cpu)
*/
static unsigned long source_load(int cpu)
{
- struct rq *rq = cpu_rq(cpu);
- unsigned long total = weighted_cpuload(cpu);
-
- if (!sched_feat(LB_BIAS))
- return total;
-
- return min(rq->cpu_load, total);
+ return weighted_cpuload(cpu);
}
/*
@@ -3969,7 +3963,6 @@ static unsigned long source_load(int cpu)
*/
static unsigned long target_load(int cpu, int imbalance_pct)
{
- struct rq *rq = cpu_rq(cpu);
unsigned long total = weighted_cpuload(cpu);
if (!sched_feat(LB_BIAS))
@@ -3978,9 +3971,7 @@ static unsigned long target_load(int cpu, int
imbalance_pct)
/*
* Bias target load with imbalance_pct.
*/
- total = total * imbalance_pct / 100;
-
- return max(rq->cpu_load, total);
+ return total * imbalance_pct / 100;
}
static unsigned long power_of(int cpu)
--
1.8.1.2
--
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 01/11] sched: shortcut to remove load_idx
Shortcut to remove rq->cpu_load[load_idx] effect in scheduler.
In five load idx, only busy_idx, idle_idx are not zero.
Newidle_idx, wake_idx and fork_idx are all zero in all archs.
So, change the idx to zero here can fully remove load_idx effect.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 235cfa7..4fcc3a3 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5908,7 +5908,7 @@ static inline void update_sd_lb_stats(struct lb_env *env,
struct sd_lb_stats *sd
if (child && child->flags & SD_PREFER_SIBLING)
prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle);
+ load_idx = 0;
do {
struct sg_lb_stats *sgs = &tmp_sgs;
--
1.8.1.2
--
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 03/11] sched: clean up cpu_load update
Since we don't decay the rq->cpu_load, so we don't need the
pending_updates. But we still want update rq->rt_avg, so
still keep rq->last_load_update_tick and func __update_cpu_load.
Signed-off-by: Alex Shi
---
kernel/sched/proc.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/proc.c b/kernel/sched/proc.c
index a2435c5..057bb9b 100644
--- a/kernel/sched/proc.c
+++ b/kernel/sched/proc.c
@@ -404,8 +404,7 @@ static void calc_load_account_active(struct rq *this_rq)
* scheduler tick (TICK_NSEC). With tickless idle this will not be called
* every tick. We fix it up based on jiffies.
*/
-static void __update_cpu_load(struct rq *this_rq, unsigned long this_load,
- unsigned long pending_updates)
+static void __update_cpu_load(struct rq *this_rq, unsigned long this_load)
{
this_rq->nr_load_updates++;
@@ -449,7 +448,6 @@ void update_idle_cpu_load(struct rq *this_rq)
{
unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
unsigned long load = get_rq_runnable_load(this_rq);
- unsigned long pending_updates;
/*
* bail if there's load or we're actually up-to-date.
@@ -457,10 +455,9 @@ void update_idle_cpu_load(struct rq *this_rq)
if (load || curr_jiffies == this_rq->last_load_update_tick)
return;
- pending_updates = curr_jiffies - this_rq->last_load_update_tick;
this_rq->last_load_update_tick = curr_jiffies;
- __update_cpu_load(this_rq, load, pending_updates);
+ __update_cpu_load(this_rq, load);
}
/*
@@ -483,7 +480,7 @@ void update_cpu_load_nohz(void)
* We were idle, this means load 0, the current load might be
* !0 due to remote wakeups and the sort.
*/
- __update_cpu_load(this_rq, 0, pending_updates);
+ __update_cpu_load(this_rq, 0);
}
raw_spin_unlock(&this_rq->lock);
}
@@ -499,7 +496,7 @@ void update_cpu_load_active(struct rq *this_rq)
* See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
*/
this_rq->last_load_update_tick = jiffies;
- __update_cpu_load(this_rq, load, 1);
+ __update_cpu_load(this_rq, load);
calc_load_account_active(this_rq);
}
--
1.8.1.2
--
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 02/11] sched: remove rq->cpu_load[load_idx] array
Since load_idx effect removed in load balance, we don't need the
load_idx decays in scheduler. that will save some process in sched_tick
and others places.
Signed-off-by: Alex Shi
---
arch/ia64/include/asm/topology.h | 5 ---
arch/metag/include/asm/topology.h | 5 ---
arch/tile/include/asm/topology.h | 6 ---
include/linux/sched.h | 5 ---
include/linux/topology.h | 8
kernel/sched/core.c | 58 +++-
kernel/sched/debug.c | 6 +--
kernel/sched/fair.c | 79 +
kernel/sched/proc.c | 92 ++-
kernel/sched/sched.h | 3 +-
10 files changed, 42 insertions(+), 225 deletions(-)
diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
index a2496e4..54e5b17 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -55,11 +55,6 @@ void build_cpu_to_node_map(void);
.busy_factor= 64, \
.imbalance_pct = 125, \
.cache_nice_tries = 2,\
- .busy_idx = 2,\
- .idle_idx = 1,\
- .newidle_idx= 0,\
- .wake_idx = 0,\
- .forkexec_idx = 0,\
.flags = SD_LOAD_BALANCE \
| SD_BALANCE_NEWIDLE\
| SD_BALANCE_EXEC \
diff --git a/arch/metag/include/asm/topology.h
b/arch/metag/include/asm/topology.h
index 8e9c0b3..d1d15cd 100644
--- a/arch/metag/include/asm/topology.h
+++ b/arch/metag/include/asm/topology.h
@@ -13,11 +13,6 @@
.busy_factor= 32, \
.imbalance_pct = 125, \
.cache_nice_tries = 2,\
- .busy_idx = 3,\
- .idle_idx = 2,\
- .newidle_idx= 0,\
- .wake_idx = 0,\
- .forkexec_idx = 0,\
.flags = SD_LOAD_BALANCE \
| SD_BALANCE_FORK \
| SD_BALANCE_EXEC \
diff --git a/arch/tile/include/asm/topology.h b/arch/tile/include/asm/topology.h
index d15c0d8..05f6ffe 100644
--- a/arch/tile/include/asm/topology.h
+++ b/arch/tile/include/asm/topology.h
@@ -57,12 +57,6 @@ static inline const struct cpumask *cpumask_of_node(int node)
.busy_factor= 64, \
.imbalance_pct = 125, \
.cache_nice_tries = 1,\
- .busy_idx = 2,\
- .idle_idx = 1,\
- .newidle_idx= 0,\
- .wake_idx = 0,\
- .forkexec_idx = 0,\
- \
.flags = 1*SD_LOAD_BALANCE \
| 1*SD_BALANCE_NEWIDLE \
| 1*SD_BALANCE_EXEC \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index c49a258..6c416c8 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -892,11 +892,6 @@ struct sched_domain {
unsigned int busy_factor; /* less balancing by factor if busy */
unsigned int imbalance_pct; /* No balance until over watermark */
unsigned int cache_nice_tries; /* Leave cache hot tasks for # tries */
- unsigned int busy_idx;
- unsigned int idle_idx;
- unsigned int newidle_idx;
- unsigned int wake_idx;
- unsigned int forkexec_idx;
unsigned int smt_gain;
int nohz_idle; /* NOHZ IDLE status */
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 12ae6ce..863fad3 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -121,9 +121,6 @@ int arch_update_cpu_topology(void);
.busy_factor= 64, \
.imbalance_pct = 125, \
.cache_nice_tries = 1,\
- .busy_idx = 2,\
- .wake_idx = 0,\
- .forkexec_idx = 0,\
Re: [PATCH RFC 3/3] video: Kconfig: move drm and fb into separate menus
On Friday, February 14, 2014 8:19 PM, Tomi Valkeinen wrote: > > At the moment the "Device Drivers / Graphics support" kernel config page > looks rather messy, with DRM and fbdev driver selections on the same > page, some on the top level Graphics support page, some under their > respective subsystems. > > If I'm not mistaken, this is caused by the drivers depending on other > things than DRM or FB, which causes Kconfig to arrange the options in > not-so-neat manner. > > Both DRM and FB have a main menuconfig option for the whole DRM or FB > subsystem. Optimally, this would be enough to arrange all DRM and FB > options under the respective subsystem, but for whatever reason this > doesn't work reliably. > > This patch adds an explicit submenu for DRM and FB, making it much > clearer which options are related to FB, and which to DRM. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Jingoo Han I tested this patch. Menu becomes clearer! Thanks. Best regards, Jingoo Han > --- > drivers/video/Kconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > index f0f26a0b746e..70d174090a54 100644 > --- a/drivers/video/Kconfig > +++ b/drivers/video/Kconfig > @@ -21,9 +21,13 @@ source "drivers/gpu/vga/Kconfig" > > source "drivers/gpu/host1x/Kconfig" > > +menu "Direct Rendering Manager" > source "drivers/gpu/drm/Kconfig" > +endmenu > > +menu "Framebuffer Devices" > source "drivers/video/fbdev/Kconfig" > +endmenu > > source "drivers/video/backlight/Kconfig" > > -- > 1.8.3.2 -- 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 0/11] remove cpu_load in rq
The cpu_load decays on time according past cpu load of rq. The sched_avg also decays tasks' load on time. Now we has 2 kind decay for cpu_load. That is a kind of redundancy. And increase the system load by decay calculation. This patch try to remove the cpu_load decay. There are 5 load_idx used for cpu_load in sched_domain. busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx and forkexec_idx are all zero on every arch. A shortcut to remove cpu_Load decay in the first patch. just one line patch for this change. V2, 1, This version do some tuning on load bias of target load, to maximum match current code logical. 2, Got further to remove the cpu_load in rq. 3, Revert the patch 'Limit sd->*_idx range on sysctl' since no needs Any testing/comments are appreciated. This patch rebase on latest tip/master. The git tree for this patchset at: g...@github.com:alexshi/power-scheduling.git noload 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 RFC 2/3] fbdev: move fbdev core files to separate directory
On Friday, February 14, 2014 8:19 PM, Tomi Valkeinen wrote:
>
> Instead of having fbdev framework core files at the root fbdev
> directory, mixed with random fbdev device drivers, move the fbdev core
> files to a separate core directory. This makes it much clearer which of
> the files are actually part of the fbdev framework, and which are part
> of device drivers.
>
> Signed-off-by: Tomi Valkeinen
Hi Tomi,
This is what I wanted for a long time!
Thank you for your effort!
Last year, I noticed that the current FB directory and files
are not clear. It looks good!
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/video/fbdev/Makefile | 16 +---
> drivers/video/fbdev/core/Makefile| 16
> drivers/video/fbdev/{ => core}/cfbcopyarea.c | 0
> drivers/video/fbdev/{ => core}/cfbfillrect.c | 0
> drivers/video/fbdev/{ => core}/cfbimgblt.c | 0
> drivers/video/fbdev/{ => core}/fb_ddc.c | 2 +-
> drivers/video/fbdev/{ => core}/fb_defio.c| 0
> drivers/video/fbdev/{ => core}/fb_draw.h | 0
> drivers/video/fbdev/{ => core}/fb_notify.c | 0
> drivers/video/fbdev/{ => core}/fb_sys_fops.c | 0
> drivers/video/fbdev/{ => core}/fbcmap.c | 0
> drivers/video/fbdev/{ => core}/fbcvt.c | 0
> drivers/video/fbdev/{ => core}/fbmem.c | 0
> drivers/video/fbdev/{ => core}/fbmon.c | 2 +-
> drivers/video/fbdev/{ => core}/fbsysfs.c | 0
> drivers/video/fbdev/{ => core}/modedb.c | 0
> drivers/video/fbdev/{ => core}/svgalib.c | 0
> drivers/video/fbdev/{ => core}/syscopyarea.c | 0
> drivers/video/fbdev/{ => core}/sysfillrect.c | 0
> drivers/video/fbdev/{ => core}/sysimgblt.c | 0
> drivers/video/fbdev/wmt_ge_rops.c| 2 +-
> 21 files changed, 20 insertions(+), 18 deletions(-)
> create mode 100644 drivers/video/fbdev/core/Makefile
> rename drivers/video/fbdev/{ => core}/cfbcopyarea.c (100%)
> rename drivers/video/fbdev/{ => core}/cfbfillrect.c (100%)
> rename drivers/video/fbdev/{ => core}/cfbimgblt.c (100%)
> rename drivers/video/fbdev/{ => core}/fb_ddc.c (99%)
> rename drivers/video/fbdev/{ => core}/fb_defio.c (100%)
> rename drivers/video/fbdev/{ => core}/fb_draw.h (100%)
> rename drivers/video/fbdev/{ => core}/fb_notify.c (100%)
> rename drivers/video/fbdev/{ => core}/fb_sys_fops.c (100%)
> rename drivers/video/fbdev/{ => core}/fbcmap.c (100%)
> rename drivers/video/fbdev/{ => core}/fbcvt.c (100%)
> rename drivers/video/fbdev/{ => core}/fbmem.c (100%)
> rename drivers/video/fbdev/{ => core}/fbmon.c (99%)
> rename drivers/video/fbdev/{ => core}/fbsysfs.c (100%)
> rename drivers/video/fbdev/{ => core}/modedb.c (100%)
> rename drivers/video/fbdev/{ => core}/svgalib.c (100%)
> rename drivers/video/fbdev/{ => core}/syscopyarea.c (100%)
> rename drivers/video/fbdev/{ => core}/sysfillrect.c (100%)
> rename drivers/video/fbdev/{ => core}/sysimgblt.c (100%)
--
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 23/27] clocksource: sh_cmt: Add DT support
Hi Laurent, On Mon, Feb 17, 2014 at 10:45 AM, Laurent Pinchart wrote: > Hi Magnus, > > On Saturday 15 February 2014 02:22:00 Magnus Damm wrote: >> On Sat, Feb 15, 2014 at 1:12 AM, Laurent Pinchart wrote: >> > On Saturday 15 February 2014 01:01:30 Magnus Damm wrote: >> >> On Sat, Feb 15, 2014 at 12:53 AM, Laurent Pinchart wrote: >> >> > On Friday 14 February 2014 10:58:22 Mark Rutland wrote: >> >> >> On Fri, Feb 14, 2014 at 01:00:01AM +, Laurent Pinchart wrote: >> >> >> > +Channels Optional Properties: >> >> >> > + >> >> >> > + - clock-source-rating: rating of the timer as a clock source >> >> >> > device. >> >> >> > + - clock-event-rating: rating of the timer as a clock event >> >> >> > device. >> >> >> >> >> >> This feels like a leak of Linux internals. Why do you need this? >> >> > >> >> > You're right, it is. The clock source and clock event ratings are >> >> > currently configured through platform data, I'll need to find a way to >> >> > compute them in the driver instead. >> >> >> >> That would be very good! >> > >> > Any pointer would be appreciated :-) How did you compute the various >> > ratings used in platform data all over the place ? >> >> Historically we used the rating to select between CMT and TMU. For >> clock sources I suppose you also have the jiffy rating to consider. >> And for the SMP parts we have ARM IP for TWD and arch timers that have >> their ratings too. So you need to check all the timers on a particular >> system and consider what you want to have operating by default. The >> ARM IP timers should be preferred if available. For clock sources the >> rule is probably the higher resolution the better. >> >> >> > There's still one piece of Linux-specific data I need though, as I need >> >> > to specify for each channel whether to use it as a clock source device, >> >> > a clock event device, both of them or none. That's configuration >> >> > information that needs to be provided somehow. >> >> >> >> I think you can decide clock source or clock event assignment based on >> >> number of channels available. If you have only a single channel then both >> >> clock event and clock source need to be supported. Otherwise use one >> >> channel for clock source and the rest for clock events. >> > >> > That won't match the current situation. Look at CMT0 in r8a7790 for >> > instance. There's two hardware channels available, and we only use the >> > first one, for clock events only. >> >> You are correct. The reason for that is that the CMT driver today is >> optimized for combined clock event and clock source operation. >> >> Historically the hardware it initially was written for (sh-mobile on >> the SH arch) only had a single timer channel so combined operation was >> required for tickless to work. But since you're asking how to allocate >> channels then I propose checking numbers of channels available and go >> from there. With that the r8a7790 support can only get better. =) >> >> >> This is probably out of scope for this DT conversion, but it would be >> >> neat if you somehow could specify the CPU affinity for a channel to tie a >> >> clock event to an individual CPU core. This would make a a per-cpu timer >> >> unless I'm mistaken. But that's more of a software policy than anything >> >> else. >> > >> > Yes, that's a configuration that needs to be specified somewhere. I don't >> > know where though. >> >> As long as you have per-channel interrupts described in DT you can >> probably handle this in a generic way in the driver. > > But how do we decide whether to use a single timer channel or one channel per > CPU ? Will the kernel use one clock event device per CPU automatically ? I > have to confess I have no idea how this works. I guess that's the tricky bit about timer support, it is a mix of hardware description and software configuration. So it sounds to me that we need some kind of software configuration interface. But it can probably be considered when/if we add such kind of support to the driver. Probably out of scope for now. Regardless it seems to me that the hardware description in DT doesn't need to care about this. Cheers, / magnus -- 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/
