Re: [PATCH 2/2] ARM: dts: cfa10049: Change the SPI3 bus to spi-gpio
On Fri, Jan 25, 2013 at 09:39:35AM +0100, Maxime Ripard wrote: > The DAC found on the last chip select requires a word length of 12 bits, > which is not supported by the SSP controller of the iMX28. Use > bitbanging for that bus to support such a length. > > Signed-off-by: Maxime Ripard 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] x86/apic: check FADT settings after enable x2apic
* Yinghai Lu wrote: > On Mon, Jan 28, 2013 at 2:11 AM, Ingo Molnar wrote: > > > >> HP has systems that work with x2apic phys mode and BIOS set > >> ACPI_FADT_APIC_PHYSICAL in FADT table, and all cpuid < 255, > >> the spec requires BIOS only put system on xapic mode. Kernel > > > > Which spec? > > > >> will set to x2apic logical mode instead of x2apic phys mode. > > > > Which has exactly what bad effect on users of these systems? > > > > You left out the most important information from the changelog: > > why do users care, what good does the patch do? > > please check you are happy with this: > > --- > From: Stoney Wang > Subject: [PATCH] x86, apic: Check fadt x2apic phys in x2apic_phys_probe() > > HP has systems that only work with x2apic phys mode and BIOS set > ACPI_FADT_APIC_PHYSICAL in FADT table. But all apicid < 255, > according to x2apic-spec, chapter 2.9, BIOS need to pass the control > to the OS with xapic mode. > Kernel will set apic driver wrong to x2apic cluster instead of x2apic phys. > > The user will have to append nox2apic in boot command line to stay xapic mode, > or append x2apic_phys to switch to x2apic phys mode. This still does not explain what happens if none of this user action is taken. I.e. what exact _user visible problem_ does the patch fix? Is this really so unimportant to you? Almost everyone will start a changelog with explaining what badness happens. Not you - you explain everything from how the fix works to how to work around the bug - except describing the most important thing: theuser visible problem itself ... Weird. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/6] ARM: davinci: da850: add OF_DEV_AUXDATA entry for I2C0
Add OF_DEV_AUXDATA for I2C0 controller driver in da850 board
dt file to use I2C0 clock.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
Changes since V1:
- updated name for auxdata lookup
da850_evm_auxdata_lookup -> da850_auxdata_lookup
:100644 100644 37c27af... 95ca4e9... M arch/arm/mach-davinci/da8xx-dt.c
arch/arm/mach-davinci/da8xx-dt.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..95ca4e9 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -37,11 +37,17 @@ static void __init da8xx_init_irq(void)
of_irq_init(da8xx_irq_match);
}
+struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
+ {}
+};
+
#ifdef CONFIG_ARCH_DAVINCI_DA850
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+ da850_auxdata_lookup, NULL);
da8xx_uart_clk_enable();
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 6/6] ARM: davinci: da850: add tps6507x regulator DT data
Add tps6507x regulator device tree data to da850-evm by
adding regulator consumers with tightened constraints
and regulator-name.TPS6507x regulator handle can be obtained
by using this regulator name.
Regulator constraints are added as per da850 board file.
Regulator names are given as per maximum output voltage the
regulator is capable to provide.
for e.g. regulator name for dcdc1 is "VDCDC1_3.3V".
Also, add tps6507x PMIC I2C slave device under I2C0 node.
Tested on da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
Changes since V1:
- No change
:100644 100644 c9ed683... 58e6961... M arch/arm/boot/dts/da850-evm.dts
arch/arm/boot/dts/da850-evm.dts | 63 +++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index c9ed683..58e6961 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -31,6 +31,10 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+
+ tps: tps@48 {
+ reg = <0x48>;
+ };
};
};
nand_cs3@6200 {
@@ -38,4 +42,63 @@
pinctrl-names = "default";
pinctrl-0 = <_cs3_pins>;
};
+ vbat: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbat";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ };
+};
+
+/include/ "tps6507x.dtsi"
+
+ {
+vdcdc1_2-supply = <>;
+vdcdc3-supply = <>;
+vldo1_2-supply = <>;
+
+regulators {
+vdcdc1_reg: regulator@0 {
+regulator-name = "VDCDC1_3.3V";
+regulator-min-microvolt = <315>;
+regulator-max-microvolt = <345>;
+regulator-always-on;
+regulator-boot-on;
+};
+
+vdcdc2_reg: regulator@1 {
+regulator-name = "VDCDC2_3.3V";
+regulator-min-microvolt = <171>;
+regulator-max-microvolt = <345>;
+regulator-always-on;
+regulator-boot-on;
+ti,defdcdc_default = <1>;
+};
+
+vdcdc3_reg: regulator@2 {
+regulator-name = "VDCDC3_1.2V";
+regulator-min-microvolt = <95>;
+regulator-max-microvolt = <135>;
+regulator-always-on;
+regulator-boot-on;
+ti,defdcdc_default = <1>;
+};
+
+ldo1_reg: regulator@3 {
+regulator-name = "LDO1_1.8V";
+regulator-min-microvolt = <171>;
+regulator-max-microvolt = <189>;
+regulator-always-on;
+regulator-boot-on;
+};
+
+ldo2_reg: regulator@4 {
+regulator-name = "LDO2_1.2V";
+regulator-min-microvolt = <114>;
+regulator-max-microvolt = <132>;
+regulator-always-on;
+regulator-boot-on;
+};
+};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/6] ARM: davinci: da850: add DT node for I2C0
Add I2C0 device tree node information to da850-evm.
Also, add I2C0 pin muxing information in da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
Changes since V1:
- Updated i2c0 node names in dts and dtsi file.
- Removed interrupt parent from i2c0 node.
- Handled i2c0 pin mux inside i2c0 node.
:100644 100644 433027f... c9ed683... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 5e0eb5c... 245ab9a... M arch/arm/boot/dts/da850.dtsi
arch/arm/boot/dts/da850-evm.dts |5 +
arch/arm/boot/dts/da850.dtsi| 15 +++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 433027f..c9ed683 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,6 +27,11 @@
serial2: serial@1d0d000 {
status = "okay";
};
+ i2c0: i2c0@1c22000 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ };
};
nand_cs3@6200 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 5e0eb5c..245ab9a 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,6 +56,12 @@
0x30 0x0110 0x0ff0
>;
};
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,bits = <
+ /* I2C0_SDA,I2C0_SCL */
+ 0x10 0x2200 0xff00
+ >;
+ };
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -81,6 +87,15 @@
interrupts = <61>;
status = "disabled";
};
+ i2c0: i2c0@1c22000 {
+ compatible = "ti,davinci-i2c";
+ reg = <0x22000 0x1000>;
+ clock-frequency = <10>;
+ interrupts = <15>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
nand_cs3@6200 {
compatible = "ti,davinci-nand";
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 5/6] ARM: regulator: add tps6507x device tree data
Add device tree data for tps6507x regulator by adding
all tps6507x regulator nodes. Regulators are initialized
based on compatible name provided in tps6507x DT file.
All tps6507x PMIC regulator device tree nodes are placed
in a separate device tree include file (tps6507x.dtsi).
tps6507x.dtsi file is created using datasheet
http://www.ti.com/lit/ds/symlink/tps65070.pdf
Tested on da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
Changes since V1:
- Updated Copyright information.
:00 100644 000... 4c326e5... A arch/arm/boot/dts/tps6507x.dtsi
arch/arm/boot/dts/tps6507x.dtsi | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tps6507x.dtsi b/arch/arm/boot/dts/tps6507x.dtsi
new file mode 100644
index 000..4c326e5
--- /dev/null
+++ b/arch/arm/boot/dts/tps6507x.dtsi
@@ -0,0 +1,47 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65070.pdf
+ */
+
+ {
+ compatible = "ti,tps6507x";
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vdcdc1_reg: regulator@0 {
+ reg = <0>;
+ regulator-compatible = "VDCDC1";
+ };
+
+ vdcdc2_reg: regulator@1 {
+ reg = <1>;
+ regulator-compatible = "VDCDC2";
+ };
+
+ vdcdc3_reg: regulator@2 {
+ reg = <2>;
+ regulator-compatible = "VDCDC3";
+ };
+
+ ldo1_reg: regulator@3 {
+ reg = <3>;
+ regulator-compatible = "LDO1";
+ };
+
+ ldo2_reg: regulator@4 {
+ reg = <4>;
+ regulator-compatible = "LDO2";
+ };
+
+ };
+};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 4/6] mfd: tps6507x: add device-tree support.
Add device tree based initialization support for TI's
tps6507x mfd device.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
Changes since V1:
- updated subject line for commit.
:100644 100644 409afa2... 5ad4b77... M drivers/mfd/tps6507x.c
drivers/mfd/tps6507x.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c
index 409afa2..5ad4b77 100644
--- a/drivers/mfd/tps6507x.c
+++ b/drivers/mfd/tps6507x.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -116,11 +117,19 @@ static const struct i2c_device_id tps6507x_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, tps6507x_i2c_id);
+#ifdef CONFIG_OF
+static struct of_device_id tps6507x_of_match[] = {
+ {.compatible = "ti,tps6507x", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tps6507x_of_match);
+#endif
static struct i2c_driver tps6507x_i2c_driver = {
.driver = {
.name = "tps6507x",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(tps6507x_of_match),
},
.probe = tps6507x_i2c_probe,
.remove = tps6507x_i2c_remove,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit
Currently, I2C driver gets probed before pinctrl driver.
To achieve I2C pin muxing via pinctrl driver before I2C
probe get called, register pinctrl driver in arch_initcall.
Also, add module_exit to unregister pinctrl driver.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
:100644 100644 f6a360b... 3a96390... M drivers/pinctrl/pinctrl-single.c
drivers/pinctrl/pinctrl-single.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index f6a360b..3a96390 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1089,7 +1089,17 @@ static struct platform_driver pcs_driver = {
},
};
-module_platform_driver(pcs_driver);
+static int __init pcs_pinctrl_init(void)
+{
+ return platform_driver_register(_driver);
+}
+arch_initcall(pcs_pinctrl_init);
+
+static void __exit pcs_pinctrl_exit(void)
+{
+ platform_driver_unregister(_driver);
+}
+module_exit(pcs_pinctrl_exit);
MODULE_AUTHOR("Tony Lindgren ");
MODULE_DESCRIPTION("One-register-per-pin type device tree based pinctrl
driver");
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/6] davinci: DT support for i2c0 and tps6507x
This patch series enables device tree support for I2C0 and for regulator via tps6507x mfd device on da850-evm. Applies on top of v3.8-rc5 of linus tree. Tested on da850-evm device. Test procedure followed as below: Once device boots up, issue command as: $for reg in /sys/class/regulator/*; do echo $reg `cat $reg/name` `cat $reg/state` `cat $reg/microvolts`; done Depends on: - ARM: davinci: da850: add interrupt-parent property in soc node https://patchwork.kernel.org/patch/2044101/ - ARM: davinci: da850: add pinctrl support http://comments.gmane.org/gmane.linux.davinci/25993 Changes since V1: - Updated i2c0 node name in da850 dts and dtsi file. - Removed interrupt parent from i2c0 node. - Updated name for da850 auxdata lookup. - Added a patch in series to update pin control driver registration. Vishwanathrao Badarkhe, Manish (6): pinctrl: pinctrl-single: use arch_initcall and module_exit ARM: davinci: da850: add OF_DEV_AUXDATA entry for I2C0 ARM: davinci: da850: add DT node for I2C0 mfd: tps6507x: add device-tree support. ARM: regulator: add tps6507x device tree data ARM: davinci: da850: add tps6507x regulator DT data arch/arm/boot/dts/da850-evm.dts | 68 ++ arch/arm/boot/dts/da850.dtsi | 15 arch/arm/boot/dts/tps6507x.dtsi | 47 ++ arch/arm/mach-davinci/da8xx-dt.c |8 - drivers/mfd/tps6507x.c |9 + drivers/pinctrl/pinctrl-single.c | 12 ++- 6 files changed, 157 insertions(+), 2 deletions(-) create mode 100644 arch/arm/boot/dts/tps6507x.dtsi -- 1.7.4.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 0/2] kvm: IOMMU read-only mapping support
On 01/29/2013 02:50 PM, Gleb Natapov wrote: > On Tue, Jan 29, 2013 at 11:06:43AM +0800, Xiao Guangrong wrote: >> On 01/28/2013 06:59 PM, Gleb Natapov wrote: >>> On Fri, Jan 25, 2013 at 11:28:40AM +0800, Xiao Guangrong wrote: On 01/25/2013 09:17 AM, Takuya Yoshikawa wrote: > On Thu, 24 Jan 2013 15:03:57 -0700 > Alex Williamson wrote: > >> A couple patches to make KVM IOMMU support honor read-only mappings. >> This causes an un-map, re-map when the read-only flag changes and >> makes use of it when setting IOMMU attributes. Thanks, > > Looks good to me. > > I think I can naturally update my patch after this gets merged. > Please wait. The commit c972f3b1 changed the write-protect behaviour - it does wirte-protection only when dirty flag is set. [ I did not see this commit when we discussed the problem before. ] Further more, i notice that write-protect is not enough, when do sync shadow page: FNAME(sync_page): host_writable = sp->spt[i] & SPTE_HOST_WRITEABLE; set_spte(vcpu, >spt[i], pte_access, PT_PAGE_TABLE_LEVEL, gfn, spte_to_pfn(sp->spt[i]), true, false, host_writable); It sets spte based on the old value that means the readonly flag check is missed. We need to call kvm_arch_flush_shadow_all under this case. >>> Why not just disallow changing memory region KVM_MEM_READONLY flag >>> without deleting the region? >> >> It will introduce some restriction when VM-sharing-mem is being implemented, >> but we need to do some optimization for it, at least, properly write-protect >> readonly pages (fix sync_page()) instead of zap_all_page. >> > What is VM-sharing-mem? Sharing memory between different guests. > >> So, i guess we can do the simple fix first. >> > By simple fix you mean calling kvm_arch_flush_shadow_all() on READONLY > flag change? Simply disallow READONLY flag changing. -- 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] ARM: davinci: da850: add RTC DT entries
On Mon, Jan 28, 2013 at 21:32:13, Nori, Sekhar wrote:
> Hi Mrugesh,
>
> On 1/28/2013 1:17 PM, Mrugesh Katepallewar wrote:
> > Add RTC DT entries in da850 dts file.
> >
> > Signed-off-by: Mrugesh Katepallewar
> > ---
> > Applies on top of v3.8-rc4 of linus tree.
> >
> > This patch is depending on
> > "ARM: davinci: da850: add interrupt-parent property in soc node"
> > https://patchwork.kernel.org/patch/2044101/
>
> > Tested on da850-evm device.
> >
> > Test Procedure:
> > date 2013.01.28-10:00:00 (usage: date[.]MM.DD-hh:mm[:ss]) hwclock
> > -w reset board and check system time.
>
> Queuing this for v3.9. The testing information above is useful and should be
> part of the changelog. I moved it there while committing.
>
> It will be nice to check the alarm functionality as well. Can you check that
> and let me know that works as well?
I tried to test RTC alarm using "rtcwake" command, however it is not working
and returning following error
"rtcwake: /dev/rtc0 not enabled for wakeup events"
This is coming because we have not registered RTC device as a wakeup source
yet.
For checking RTC alarm interrupt, I developed one simple program which opens
RTC device, set alarm and exits.
Then by entering "cat /proc/interrupts" checked RTC interrupt count.
Using above test it confirms that RTC alarm functionality is working fine.
>
> Thanks,
> Sekhar
>
Regards,
Mrugesh
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 4/4] ACPI / platform: Use struct acpi_scan_handler for creating devices
On Mon, Jan 28, 2013 at 02:01:14PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Currently, the ACPI namespace scanning code creates platform device > objects for ACPI device nodes whose IDs match the contents of the > acpi_platform_device_ids[] table. However, this adds a superfluous > special case into acpi_bus_device_attach() and makes it more > difficult to follow than it has to be. It also will make it more > difficult to implement removal code for those platform device objects > in the future. > > For the above reasons, introduce a struct acpi_scan_handler object > for creating platform devices and move the code related to that from > acpi_bus_device_attach() to the .attach() callback of that object. > Also move the acpi_platform_device_ids[] table to acpi_platform.c. > > Signed-off-by: Rafael J. Wysocki I've tested this with Haswell machine and once you fix the problem pointed out by Yasuaki Ishimat (returning always when ACPI_PLATFORM_CLK is set) the platform device creation works well. This is a nice cleanup and localizes the hard coded platform device table in one file making maintenance bit easier. Feel free to add: Reviewed-by: Mika Westerberg Tested-by: Mika Westerberg -- 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 0/4] Add support for LZ4-compressed kernels
On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote: > > It's a lot of code for a 50ms boot-time improvement. Does anyone have > any opinions on whether or not the benefits are worth the cost? In the embedded space, quick boot is a really important feature to have. Many people resort to awful hacks in order to improve boot time, and so I would welcome this option. I have seen arm systems that boot in 300 ms. I would say that 50 ms is maybe not such a small improvement after all. Thanks, Richard -- 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] Tracepoint Event: Add 4 tracepoint events for vfs subsystem.
From: chenggang@gmail.com If the engineers want to analyze the file access behavior of some applications without source code, perf tools with some appropriate tracepoints events in the VFS subsystem are excellent choice. The system engineers or developers of server software require to know what files are accessed by the target processes with in a period of time. Then they can find the hot applications and the hot files. For this requirements, we added 2 tracepoint events at the begin of generic_file_aio_read() and generic_file_aio_write(). Many database systems use their own page cache subsystems and use the direct IO to access the disks. Sometimes, the system engineers want to know the misses rate of the database system's page cache. This requirements can be satisfied by recording the database's file access behavior through the way of direct IO. So, we added 2 tracepoint events at the direct IO branch in generic_file_aio_read() and generic_file_aio_write(). Then, we will extend the perf's function by python script to use these new tracepoint events. The 4 new tracepoint events are: 1) generic_file_aio_read Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:unsigned char fname[100]; offset:32; size:100; signed:0; 2) generic_file_aio_write Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:unsigned char fname[100]; offset:32; size:100; signed:0; 3) direct_io_read Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:unsigned char fname[100]; offset:32; size:100; signed:0; 4) direct_io_write Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:unsigned char fname[100]; offset:32; size:100; signed:0; Cc: Steven Rostedt Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: David Ahern Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Cc: Arjan van de Ven Cc: Namhyung Kim Cc: Yanmin Zhang Cc: Wu Fengguang Cc: Mike Galbraith Cc: Andrew Morton Signed-off-by: Chenggang Qin --- include/trace/events/vfs.h | 110 mm/filemap.c | 18 2 files changed, 128 insertions(+) create mode 100644 include/trace/events/vfs.h diff --git a/include/trace/events/vfs.h b/include/trace/events/vfs.h new file mode 100644 index 000..33498e1 --- /dev/null +++ b/include/trace/events/vfs.h @@ -0,0 +1,110 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM vfs +#define TRACE_INCLUDE_FILE vfs + +#if !defined(_TRACE_EVENTS_VFS_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_EVENTS_VFS_H + +#include + +#include + +TRACE_EVENT(generic_file_aio_read, + + TP_PROTO(long long pos, unsigned long bytes, unsigned char *fname), + + TP_ARGS(pos, bytes, fname), + + TP_STRUCT__entry( + __field(long long, pos ) + __field(unsigned long, bytes ) + __array(unsigned char, fname, 100
[PATCH 6/6] MFD:rtsx: Optimize card detect flow
From: Wei WANG
1. Schedule card detect work at the end of ISR
2. Callback function ops->cd_deglitch may delay for a period of time.
It is not proper to call this callback when local irq disabled
3. Card detect flow can't be exectued in parallel with other card reader
operations, so it's better to be protected by mutex
Signed-off-by: Wei WANG
---
drivers/mfd/rtsx_pcr.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 67bb34e..9016932 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -752,7 +752,7 @@ static void rtsx_pci_card_detect(struct work_struct *work)
struct delayed_work *dwork;
struct rtsx_pcr *pcr;
unsigned long flags;
- unsigned int card_detect = 0;
+ unsigned int card_detect = 0, card_inserted, card_removed;
u32 irq_status;
dwork = to_delayed_work(work);
@@ -760,25 +760,32 @@ static void rtsx_pci_card_detect(struct work_struct *work)
dev_dbg(&(pcr->pci->dev), "--> %s\n", __func__);
+ mutex_lock(>pcr_mutex);
spin_lock_irqsave(>lock, flags);
irq_status = rtsx_pci_readl(pcr, RTSX_BIPR);
dev_dbg(&(pcr->pci->dev), "irq_status: 0x%08x\n", irq_status);
- if (pcr->card_inserted || pcr->card_removed) {
+ irq_status &= CARD_EXIST;
+ card_inserted = pcr->card_inserted & irq_status;
+ card_removed = pcr->card_removed;
+ pcr->card_inserted = 0;
+ pcr->card_removed = 0;
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ if (card_inserted || card_removed) {
dev_dbg(&(pcr->pci->dev),
"card_inserted: 0x%x, card_removed: 0x%x\n",
- pcr->card_inserted, pcr->card_removed);
+ card_inserted, card_removed);
if (pcr->ops->cd_deglitch)
- pcr->card_inserted = pcr->ops->cd_deglitch(pcr);
+ card_inserted = pcr->ops->cd_deglitch(pcr);
- card_detect = pcr->card_inserted | pcr->card_removed;
- pcr->card_inserted = 0;
- pcr->card_removed = 0;
+ card_detect = card_inserted | card_removed;
}
- spin_unlock_irqrestore(>lock, flags);
+ mutex_unlock(>pcr_mutex);
if ((card_detect & SD_EXIST) && pcr->slots[RTSX_SD_CARD].card_event)
pcr->slots[RTSX_SD_CARD].card_event(
@@ -830,10 +837,6 @@ static irqreturn_t rtsx_pci_isr(int irq, void *dev_id)
}
}
- if (pcr->card_inserted || pcr->card_removed)
- schedule_delayed_work(>carddet_work,
- msecs_to_jiffies(200));
-
if (int_reg & (NEED_COMPLETE_INT | DELINK_INT)) {
if (int_reg & (TRANS_FAIL_INT | DELINK_INT)) {
pcr->trans_result = TRANS_RESULT_FAIL;
@@ -846,6 +849,10 @@ static irqreturn_t rtsx_pci_isr(int irq, void *dev_id)
}
}
+ if (pcr->card_inserted || pcr->card_removed)
+ schedule_delayed_work(>carddet_work,
+ msecs_to_jiffies(200));
+
spin_unlock(>lock);
return IRQ_HANDLED;
}
--
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 4/6] MFD:rtsx: Fix checkpatch warning
From: Wei WANG
WARNING: Avoid CamelCase:
+ u8 N, min_N, max_N, clk_divider;
WARNING: Avoid CamelCase:
+ u8 N, min_N, max_N, clk_divider;
Signed-off-by: Wei WANG
---
drivers/mfd/rtsx_pcr.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index b2cfd2e..4897c39 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -590,7 +590,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
u8 ssc_depth, bool initial_mode, bool double_clk, bool vpclk)
{
int err, clk;
- u8 N, min_N, max_N, clk_divider;
+ u8 n, min_n, max_n, clk_divider;
u8 mcu_cnt, div, max_div;
u8 depth[] = {
[RTSX_SSC_DEPTH_4M] = SSC_DEPTH_4M,
@@ -615,8 +615,8 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
card_clock /= 100;
dev_dbg(&(pcr->pci->dev), "Switch card clock to %dMHz\n", card_clock);
- min_N = 80;
- max_N = 208;
+ min_n = 80;
+ max_n = 208;
max_div = CLK_DIV_8;
clk = card_clock;
@@ -630,30 +630,30 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
return 0;
if (pcr->ops->conv_clk_and_div_n)
- N = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
+ n = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
else
- N = (u8)(clk - 2);
- if ((clk <= 2) || (N > max_N))
+ n = (u8)(clk - 2);
+ if ((clk <= 2) || (n > max_n))
return -EINVAL;
mcu_cnt = (u8)(125/clk + 3);
if (mcu_cnt > 15)
mcu_cnt = 15;
- /* Make sure that the SSC clock div_n is equal or greater than min_N */
+ /* Make sure that the SSC clock div_n is equal or greater than min_n */
div = CLK_DIV_1;
- while ((N < min_N) && (div < max_div)) {
+ while ((n < min_n) && (div < max_div)) {
if (pcr->ops->conv_clk_and_div_n) {
- int dbl_clk = pcr->ops->conv_clk_and_div_n(N,
+ int dbl_clk = pcr->ops->conv_clk_and_div_n(n,
DIV_N_TO_CLK) * 2;
- N = (u8)pcr->ops->conv_clk_and_div_n(dbl_clk,
+ n = (u8)pcr->ops->conv_clk_and_div_n(dbl_clk,
CLK_TO_DIV_N);
} else {
- N = (N + 2) * 2 - 2;
+ n = (n + 2) * 2 - 2;
}
div++;
}
- dev_dbg(&(pcr->pci->dev), "N = %d, div = %d\n", N, div);
+ dev_dbg(&(pcr->pci->dev), "n = %d, div = %d\n", n, div);
ssc_depth = depth[ssc_depth];
if (double_clk)
@@ -670,7 +670,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_CTL1, SSC_RSTB, 0);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_CTL2,
SSC_DEPTH_MASK, ssc_depth);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_DIV_N_0, 0xFF, N);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_DIV_N_0, 0xFF, n);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_CTL1, SSC_RSTB, SSC_RSTB);
if (vpclk) {
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_VPCLK0_CTL,
--
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 1/6] MFD:rtsx: Fix typo in comment
From: Wei WANG Fix a misspelling word in comment Signed-off-by: Wei WANG --- include/linux/mfd/rtsx_pci.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index 4b117a3..3f2bf26 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -465,7 +465,7 @@ #defineSD_RSP_TYPE_R6 0x01 #defineSD_RSP_TYPE_R7 0x01 -/* SD_CONFIURE3 */ +/* SD_CONFIGURE3 */ #defineSD_RSP_80CLK_TIMEOUT_EN 0x01 /* Card Transfer Reset Register */ -- 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 3/6] MFD:rtsx: Declare that the DMA address limitation is 32bit explicitly
From: Wei WANG Realtek PCIe card reader only supports 32bit DMA. This declaration can improve the readability Signed-off-by: Wei WANG --- drivers/mfd/rtsx_pcr.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c index c021ce3..b2cfd2e 100644 --- a/drivers/mfd/rtsx_pcr.c +++ b/drivers/mfd/rtsx_pcr.c @@ -1029,6 +1029,10 @@ static int rtsx_pci_probe(struct pci_dev *pcidev, pci_name(pcidev), (int)pcidev->vendor, (int)pcidev->device, (int)pcidev->revision); + ret = pci_set_dma_mask(pcidev, DMA_BIT_MASK(32)); + if (ret < 0) + return ret; + ret = pci_enable_device(pcidev); if (ret) return ret; -- 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 2/6] MFD:rtsx: Remove redundant code
From: Wei WANG In function rtsx_pci_add_sg_tbl, the statement "ptr++" is useless. Signed-off-by: Wei WANG Acked-by: Borislav Petkov --- drivers/mfd/rtsx_pcr.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c index 9fc5700..c021ce3 100644 --- a/drivers/mfd/rtsx_pcr.c +++ b/drivers/mfd/rtsx_pcr.c @@ -325,7 +325,6 @@ static void rtsx_pci_add_sg_tbl(struct rtsx_pcr *pcr, val = ((u64)addr << 32) | ((u64)len << 12) | option; put_unaligned_le64(val, ptr); - ptr++; pcr->sgi++; } -- 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 0/6] MFD:rtsx: Fix coding style and optimize flow
From: Wei WANG This patchset fixes some coding style issues, and optimizes card detect flow to improve the stability when inserting card. Wei WANG (6): MFD:rtsx: Fix typo in comment MFD:rtsx: Remove redundant code MFD:rtsx: Declare that the DMA address limitation is 32bit explicitly MFD:rtsx: Fix checkpatch warning MFD:rtsx: Use macro defines to replace some variables MFD:rtsx: Optimize card detect flow drivers/mfd/rtsx_pcr.c | 63 +++--- drivers/mfd/rtsx_pcr.h |3 ++ include/linux/mfd/rtsx_pci.h |2 +- 3 files changed, 38 insertions(+), 30 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 5/6] MFD:rtsx: Use macro defines to replace some variables
From: Wei WANG
In function rtsx_pci_switch_clock, some variables, such as min_n, max_n,
and max_div, are not necessary. And those assigned values look very
obscure for others. It's more proper to use macro definitions here to
replace these variables.
Signed-off-by: Wei WANG
Acked-by: Borislav Petkov
---
drivers/mfd/rtsx_pcr.c | 13 -
drivers/mfd/rtsx_pcr.h |3 +++
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 4897c39..67bb34e 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -590,8 +590,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
u8 ssc_depth, bool initial_mode, bool double_clk, bool vpclk)
{
int err, clk;
- u8 n, min_n, max_n, clk_divider;
- u8 mcu_cnt, div, max_div;
+ u8 n, clk_divider, mcu_cnt, div;
u8 depth[] = {
[RTSX_SSC_DEPTH_4M] = SSC_DEPTH_4M,
[RTSX_SSC_DEPTH_2M] = SSC_DEPTH_2M,
@@ -615,10 +614,6 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
card_clock /= 100;
dev_dbg(&(pcr->pci->dev), "Switch card clock to %dMHz\n", card_clock);
- min_n = 80;
- max_n = 208;
- max_div = CLK_DIV_8;
-
clk = card_clock;
if (!initial_mode && double_clk)
clk = card_clock * 2;
@@ -633,16 +628,16 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
n = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
else
n = (u8)(clk - 2);
- if ((clk <= 2) || (n > max_n))
+ if ((clk <= 2) || (n > MAX_DIV_N_PCR))
return -EINVAL;
mcu_cnt = (u8)(125/clk + 3);
if (mcu_cnt > 15)
mcu_cnt = 15;
- /* Make sure that the SSC clock div_n is equal or greater than min_n */
+ /* Make sure that the SSC clock div_n is not less than MIN_DIV_N_PCR */
div = CLK_DIV_1;
- while ((n < min_n) && (div < max_div)) {
+ while ((n < MIN_DIV_N_PCR) && (div < CLK_DIV_8)) {
if (pcr->ops->conv_clk_and_div_n) {
int dbl_clk = pcr->ops->conv_clk_and_div_n(n,
DIV_N_TO_CLK) * 2;
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 12462c1..33c210b 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -25,6 +25,9 @@
#include
+#define MIN_DIV_N_PCR 80
+#define MAX_DIV_N_PCR 208
+
void rts5209_init_params(struct rtsx_pcr *pcr);
void rts5229_init_params(struct rtsx_pcr *pcr);
void rtl8411_init_params(struct rtsx_pcr *pcr);
--
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/
Re: [PATCH 2/3] ARM: dts: mxs: Add muxing options for the third PWM
On Fri, Jan 25, 2013 at 09:54:06AM +0100, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard
Applied, thanks.
> ---
> arch/arm/boot/dts/imx28.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 13b7053..7ba4966 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -502,6 +502,16 @@
> fsl,pull-up = <0>;
> };
>
> + pwm3_pins_b: pwm3@1 {
> + reg = <1>;
> + fsl,pinmux-ids = <
> + 0x3141 /*
> MX28_PAD_SAIF0_MCLK__PWM3 */
> + >;
> + fsl,drive-strength = <0>;
> + fsl,voltage = <1>;
> + fsl,pull-up = <0>;
> + };
> +
> pwm4_pins_a: pwm4@0 {
> reg = <0>;
> fsl,pinmux-ids = <
> --
> 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: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial write
On Tue, Jan 29, 2013 at 1:21 AM, Minchan Kim wrote:
> How about this?
> - >8 ---
>
> From 9f8756ae0b0f2819f93cb94dcd38da372843aa12 Mon Sep 17 00:00:00 2001
> From: Minchan Kim
> Date: Mon, 21 Jan 2013 13:58:52 +0900
> Subject: [RESEND PATCH v5 1/4] zram: Fix deadlock bug in partial read/write
>
> Now zram allocates new page with GFP_KERNEL in zram I/O path
> if IO is partial. Unfortunately, It may cause deadlock with
> reclaim path like below.
>
> write_page from fs
> fs_lock
> allocation(GFP_KERNEL)
> reclaim
> pageout
> write_page from fs
> fs_lock <-- deadlock
>
> This patch fixes it by using GFP_ATOMIC and GFP_NOIO.
> In read path, we called kmap_atomic so that we need GFP_ATOMIC
> while we need GFP_NOIO in write path.
The patch description makes sense now. Thanks!
On Tue, Jan 29, 2013 at 1:21 AM, Minchan Kim wrote:
> We could use GFP_IO instead of GFP_ATOMIC in zram_bvec_read with
> some modification related to buffer allocation in case of partial IO.
> But it needs more churn and prevent merge this patch into stable
> if we should send this to stable so I'd like to keep it as simple
> as possbile. GFP_IO usage could be separate patch after we merge it.
I don't see why something like below couldn't be merged for stable.
Going for GFP_ATOMIC might seem like the simplest thing to go for but
usually bites you in the end.
Pekka
- >8 ---
>From 936a12b423c58542628d6fd683e859f752eb3d41 Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Mon, 21 Jan 2013 13:58:52 +0900
Subject: [PATCH] zram: Fix deadlock bug in partial read/write
Now zram allocates new page with GFP_KERNEL in zram I/O path
if IO is partial. Unfortunately, It may cause deadlock with
reclaim path like below.
write_page from fs
fs_lock
allocation(GFP_KERNEL)
reclaim
pageout
write_page from fs
fs_lock <-- deadlock
This patch fixes it by using GFP_NOIO. In read path, we
reorganize code flow so that kmap_atomic is called after the
GFP_NOIO allocation.
Cc: sta...@vger.kernel.org
Cc: Jerome Marchand
Acked-by: Nitin Gupta
Signed-off-by: Minchan Kim
[ penb...@kernel.org: don't use GFP_ATOMIC ]
Signed-off-by: Pekka Enberg
---
drivers/staging/zram/zram_drv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index f2a73bd..071e058 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -228,11 +228,12 @@ static int zram_bvec_read(struct zram *zram, struct
bio_vec *bvec,
return 0;
}
- user_mem = kmap_atomic(page);
if (is_partial_io(bvec))
/* Use a temporary buffer to decompress the page */
- uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
- else
+ uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
+
+ user_mem = kmap_atomic(page);
+ if (!is_partial_io(bvec))
uncmem = user_mem;
if (!uncmem) {
@@ -279,7 +280,7 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
* This is a partial IO. We need to read the full page
* before to write the changes.
*/
- uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
if (!uncmem) {
pr_info("Error allocating temp memory!\n");
ret = -ENOMEM;
--
1.7.11.7
--
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: [Ilw] iwlwifi/iwldvm soft lockup with 3.8.0-rc5 (was: almost unusable on 3.8.0-rc5)
> > Hello all, > > Oh the irony, I was just starting an email saying wifi is almost unusable for > me > with 3.8 and my machine (a thinkpad t530) completely froze while typing it... > > I was going to say I'm getting a lot of: > iwlwifi :03:00.0: fail to flush all tx fifo queues > Please try this one: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3e5d7181afb66657393066bccce0956fab09ab3 as you can see, it is in mainline already. - A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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 7/9] block: check for timeout function in blk_rq_timed_out()
rq_timed_out_fn might have been unset while the request
was in flight, so we need to check for it in blk_rq_timed_out().
Cc: Jens Axboe
Signed-off-by: Hannes Reinecke
---
block/blk-timeout.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/block/blk-timeout.c b/block/blk-timeout.c
index 6e4744c..65f1035 100644
--- a/block/blk-timeout.c
+++ b/block/blk-timeout.c
@@ -82,9 +82,10 @@ void blk_delete_timer(struct request *req)
static void blk_rq_timed_out(struct request *req)
{
struct request_queue *q = req->q;
- enum blk_eh_timer_return ret;
+ enum blk_eh_timer_return ret = BLK_EH_RESET_TIMER;
- ret = q->rq_timed_out_fn(req);
+ if (q->rq_timed_out_fn)
+ ret = q->rq_timed_out_fn(req);
switch (ret) {
case BLK_EH_HANDLED:
__blk_complete_request(req);
--
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/
[PATCH 5/9] dasd: Reduce amount of messages for specific errors
Whenever a request has been aborted internally by the driver
there is no sense data to be had. And printing lots of messages
stalls the system, so better to print out a short one-liner.
Signed-off-by: Hannes Reinecke
---
drivers/s390/block/dasd_erp.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/s390/block/dasd_erp.c b/drivers/s390/block/dasd_erp.c
index d01ef82..908b9a0 100644
--- a/drivers/s390/block/dasd_erp.c
+++ b/drivers/s390/block/dasd_erp.c
@@ -159,6 +159,14 @@ dasd_log_sense(struct dasd_ccw_req *cqr, struct irb *irb)
struct dasd_device *device;
device = cqr->startdev;
+ if (cqr->intrc == -ETIMEDOUT) {
+ dev_err(>cdev->dev, "cqr %p timeout error", cqr);
+ return;
+ }
+ if (cqr->intrc == -ENOLINK) {
+ dev_err(>cdev->dev, "cqr %p transport error", cqr);
+ return;
+ }
/* dump sense data */
if (device->discipline && device->discipline->dump_sense)
device->discipline->dump_sense(device, cqr, irb);
--
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/
[PATCH 8/9] dasd: Add 'timeout' attribute
This patch adds a 'timeout' attibute to the DASD driver.
When set to non-zero, the blk_timeout function will
be enabled with the timeout specified in the attribute.
Setting 'timeout' to '0' will disable block timeouts.
Signed-off-by: Hannes Reinecke
---
drivers/s390/block/dasd.c|2 +
drivers/s390/block/dasd_devmap.c | 56 ++
drivers/s390/block/dasd_int.h|4 +++
3 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index d806b98..61080df 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -2785,6 +2785,8 @@ enum blk_eh_timer_return dasd_times_out(struct request
*req)
return BLK_EH_NOT_HANDLED;
device = cqr->startdev ? cqr->startdev : block->base;
+ if (!device->blk_timeout)
+ return BLK_EH_RESET_TIMER;
DBF_DEV_EVENT(DBF_WARNING, device,
" dasd_times_out cqr %p status %x",
cqr, cqr->status);
diff --git a/drivers/s390/block/dasd_devmap.c b/drivers/s390/block/dasd_devmap.c
index d237e31..1ca85f6 100644
--- a/drivers/s390/block/dasd_devmap.c
+++ b/drivers/s390/block/dasd_devmap.c
@@ -1281,6 +1281,61 @@ dasd_retries_store(struct device *dev, struct
device_attribute *attr,
static DEVICE_ATTR(retries, 0644, dasd_retries_show, dasd_retries_store);
+static ssize_t
+dasd_timeout_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct dasd_device *device;
+ int len;
+
+ device = dasd_device_from_cdev(to_ccwdev(dev));
+ if (IS_ERR(device))
+ return -ENODEV;
+ len = snprintf(buf, PAGE_SIZE, "%lu\n", device->blk_timeout);
+ dasd_put_device(device);
+ return len;
+}
+
+static ssize_t
+dasd_timeout_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct dasd_device *device;
+ struct request_queue *q;
+ unsigned long val, flags;
+
+ device = dasd_device_from_cdev(to_ccwdev(dev));
+ if (IS_ERR(device))
+ return -ENODEV;
+
+ if ((strict_strtoul(buf, 10, ) != 0) ||
+ val > ULONG_MAX / HZ) {
+ dasd_put_device(device);
+ return -EINVAL;
+ }
+ q = device->block->request_queue;
+ if (!q) {
+ dasd_put_device(device);
+ return -ENODEV;
+ }
+ spin_lock_irqsave(>block->request_queue_lock, flags);
+ if (!val)
+ blk_queue_rq_timed_out(q, NULL);
+ else
+ blk_queue_rq_timed_out(q, dasd_times_out);
+
+ device->blk_timeout = val;
+
+ blk_queue_rq_timeout(q, device->blk_timeout * HZ);
+ spin_unlock_irqrestore(>block->request_queue_lock, flags);
+
+ dasd_put_device(device);
+ return count;
+}
+
+static DEVICE_ATTR(timeout, 0644,
+ dasd_timeout_show, dasd_timeout_store);
+
static ssize_t dasd_reservation_policy_show(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -1392,6 +1447,7 @@ static struct attribute * dasd_attrs[] = {
_attr_failfast.attr,
_attr_expires.attr,
_attr_retries.attr,
+ _attr_timeout.attr,
_attr_reservation_policy.attr,
_attr_last_known_reservation_state.attr,
_attr_safe_offline.attr,
diff --git a/drivers/s390/block/dasd_int.h b/drivers/s390/block/dasd_int.h
index 375ba1f..d00d07a 100644
--- a/drivers/s390/block/dasd_int.h
+++ b/drivers/s390/block/dasd_int.h
@@ -469,6 +469,8 @@ struct dasd_device {
unsigned long default_expires;
unsigned long default_retries;
+ unsigned long blk_timeout;
+
struct dentry *debugfs_dentry;
struct dasd_profile profile;
};
@@ -662,6 +664,8 @@ void dasd_free_device(struct dasd_device *);
struct dasd_block *dasd_alloc_block(void);
void dasd_free_block(struct dasd_block *);
+enum blk_eh_timer_return dasd_times_out(struct request *req);
+
void dasd_enable_device(struct dasd_device *);
void dasd_set_target_state(struct dasd_device *, int);
void dasd_kick_device(struct dasd_device *);
--
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/
[PATCH 9/9] dasd: Fail all requests when DASD_FLAG_ABORTIO is set
Whenever a DASD request encounters a timeout we might
need to abort all outstanding requests on this or
even other devices.
This is especially useful if one wants to fail all
devices on one side of a RAID10 configuration, even
though only one device exhibited an error.
To handle this I've introduced a new device flag
DASD_FLAG_ABORTIO.
This flag is evaluated in __dasd_process_request_queue()
and will invoke blk_abort_request() for all
outstanding requests with DASD_CQR_FLAGS_FAILFAST set.
This will cause any of these requests to be aborted
immediately if the blk_timeout function is activated.
The DASD_FLAG_ABORTIO is also evaluated in
__dasd_process_request_queue to abort all
new request which would have the
DASD_CQR_FLAGS_FAILFAST bit set.
The flag can be set with the new ioctls 'BIODASDABORTIO'
and removed with 'BIODASDALLOWIO'.
Signed-off-by: Hannes Reinecke
---
arch/s390/include/uapi/asm/dasd.h |4 ++
drivers/s390/block/dasd.c | 13 ++--
drivers/s390/block/dasd_int.h |3 ++
drivers/s390/block/dasd_ioctl.c | 59 +
4 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/arch/s390/include/uapi/asm/dasd.h
b/arch/s390/include/uapi/asm/dasd.h
index 38eca3b..a2ea496 100644
--- a/arch/s390/include/uapi/asm/dasd.h
+++ b/arch/s390/include/uapi/asm/dasd.h
@@ -261,6 +261,10 @@ struct dasd_snid_ioctl_data {
#define BIODASDQUIESCE _IO(DASD_IOCTL_LETTER,6)
/* Resume IO on device */
#define BIODASDRESUME _IO(DASD_IOCTL_LETTER,7)
+/* Abort all I/O on a device */
+#define BIODASDABORTIO _IO(DASD_IOCTL_LETTER,240)
+/* Allow I/O on a device */
+#define BIODASDALLOWIO _IO(DASD_IOCTL_LETTER,241)
/* retrieve API version number */
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index 61080df..9f8dbbb 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -38,9 +38,6 @@
*/
#define DASD_CHANQ_MAX_SIZE 4
-#define DASD_SLEEPON_START_TAG (void *) 1
-#define DASD_SLEEPON_END_TAG (void *) 2
-
/*
* SECTION: exported variables of dasd.c
*/
@@ -2446,6 +2443,16 @@ static void __dasd_process_request_queue(struct
dasd_block *block)
__blk_end_request_all(req, -EIO);
continue;
}
+ if (test_bit(DASD_FLAG_ABORTALL, >flags) &&
+ (basedev->features & DASD_FEATURE_FAILFAST ||
+blk_noretry_request(req))) {
+ DBF_DEV_EVENT(DBF_ERR, basedev,
+ "Rejecting failfast request %p",
+ req);
+ blk_start_request(req);
+ __blk_end_request_all(req, -ETIMEDOUT);
+ continue;
+ }
cqr = basedev->discipline->build_cp(basedev, block, req);
if (IS_ERR(cqr)) {
if (PTR_ERR(cqr) == -EBUSY)
diff --git a/drivers/s390/block/dasd_int.h b/drivers/s390/block/dasd_int.h
index d00d07a..a4f3050 100644
--- a/drivers/s390/block/dasd_int.h
+++ b/drivers/s390/block/dasd_int.h
@@ -523,7 +523,10 @@ struct dasd_block {
#define DASD_FLAG_SUSPENDED9 /* The device was suspended */
#define DASD_FLAG_SAFE_OFFLINE 10 /* safe offline processing requested*/
#define DASD_FLAG_SAFE_OFFLINE_RUNNING 11 /* safe offline running */
+#define DASD_FLAG_ABORTALL 12 /* Abort all noretry requests */
+#define DASD_SLEEPON_START_TAG (void *) 1
+#define DASD_SLEEPON_END_TAG (void *) 2
void dasd_put_device_wake(struct dasd_device *);
diff --git a/drivers/s390/block/dasd_ioctl.c b/drivers/s390/block/dasd_ioctl.c
index 03c0e04..d59bdb6 100644
--- a/drivers/s390/block/dasd_ioctl.c
+++ b/drivers/s390/block/dasd_ioctl.c
@@ -141,6 +141,59 @@ static int dasd_ioctl_resume(struct dasd_block *block)
}
/*
+ * Abort all failfast I/O on a device.
+ */
+static int dasd_ioctl_abortio(struct dasd_block *block)
+{
+ unsigned long flags;
+ struct dasd_device *base;
+ struct dasd_ccw_req *cqr, *n;
+
+ base = block->base;
+ if (!capable (CAP_SYS_ADMIN))
+ return -EACCES;
+
+ if (test_and_set_bit(DASD_FLAG_ABORTALL, >flags))
+ return 0;
+ DBF_DEV_EVENT(DBF_NOTICE, base, "%s", "abortall flag set");
+
+ spin_lock_irqsave(>request_queue_lock, flags);
+ spin_lock(>queue_lock);
+ list_for_each_entry_safe(cqr, n, >ccw_queue, blocklist) {
+ if (test_bit(DASD_CQR_FLAGS_FAILFAST, >flags) &&
+ cqr->callback_data &&
+ cqr->callback_data != DASD_SLEEPON_START_TAG &&
+ cqr->callback_data != DASD_SLEEPON_END_TAG ) {
+ spin_unlock(>queue_lock);
+ blk_abort_request(cqr->callback_data);
+ spin_lock(>queue_lock);
+ }
+ }
+ spin_unlock(>queue_lock);
+
[PATCH 6/9] dasd: detailed I/O errors
The DASD driver is using FASTFAIL as an equivalent to the
transport errors in SCSI. And the 'steal lock' function maps
roughly to a reservation error. So we should be returning the
appropriate error codes when completing a request.
Cc: Jens Axboe
Signed-off-by: Hannes Reinecke
---
block/blk-core.c |3 +++
drivers/s390/block/dasd.c | 16 +---
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index c973249..d5579c2 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2291,6 +2291,9 @@ bool blk_update_request(struct request *req, int error,
unsigned int nr_bytes)
case -EBADE:
error_type = "critical nexus";
break;
+ case -ETIMEDOUT:
+ error_type = "timeout";
+ break;
case -EIO:
default:
error_type = "I/O";
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index 0406325..d806b98 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -2174,7 +2174,7 @@ static int _dasd_sleep_on(struct dasd_ccw_req *maincqr,
int interruptible)
test_bit(DASD_CQR_FLAGS_FAILFAST, >flags) &&
(!dasd_eer_enabled(device))) {
cqr->status = DASD_CQR_FAILED;
- cqr->intrc = -EAGAIN;
+ cqr->intrc = -ENOLINK;
continue;
}
/* Don't try to start requests if device is stopped */
@@ -2501,8 +2501,17 @@ static void __dasd_cleanup_cqr(struct dasd_ccw_req *cqr)
req = (struct request *) cqr->callback_data;
dasd_profile_end(cqr->block, cqr, req);
status = cqr->block->base->discipline->free_cp(cqr, req);
- if (status <= 0)
- error = status ? status : -EIO;
+ if (status < 0)
+ error = status;
+ else if (status == 0) {
+ if (cqr->intrc == -EPERM)
+ error = -EBADE;
+ else if (cqr->intrc == -ENOLINK ||
+cqr->intrc == -ETIMEDOUT)
+ error = cqr->intrc;
+ else
+ error = -EIO;
+ }
__blk_end_request_all(req, error);
}
@@ -2603,6 +2612,7 @@ static void __dasd_block_start_head(struct dasd_block
*block)
test_bit(DASD_CQR_FLAGS_FAILFAST, >flags) &&
(!dasd_eer_enabled(block->base))) {
cqr->status = DASD_CQR_FAILED;
+ cqr->intrc = -ENOLINK;
dasd_schedule_block_bh(block);
continue;
}
--
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/
[PATCH 3/9] dasd: process all requests in the device tasklet
Originally the DASD device tasklet would process the entries on
the ccw_queue until the first non-final request was found.
Which was okay as long as all requests have the same retries and
expires parameter.
However, as we're now allowing to modify both it is possible to
have requests _after_ the first request which already have expired.
So we need to check all requests in the device tasklet.
Signed-off-by: Hannes Reinecke
---
drivers/s390/block/dasd.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index 09ddf70..20b7517 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -1778,11 +1778,11 @@ static void __dasd_device_process_ccw_queue(struct
dasd_device *device,
list_for_each_safe(l, n, >ccw_queue) {
cqr = list_entry(l, struct dasd_ccw_req, devlist);
- /* Stop list processing at the first non-final request. */
+ /* Skip any non-final request. */
if (cqr->status == DASD_CQR_QUEUED ||
cqr->status == DASD_CQR_IN_IO ||
cqr->status == DASD_CQR_CLEAR_PENDING)
- break;
+ continue;
if (cqr->status == DASD_CQR_ERROR) {
__dasd_device_recovery(device, cqr);
}
--
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/
[PATCH 0/9] dasd: implement block timeout
This patch series implements a block timeout handler for DASDs. The main impetus was to allow for a fixed upper timeout value after which a request is aborted. This is required eg when implementing a host-based mirroring system where otherwise the entire mirror would stall under certain circumstances. Please apply. Hannes Reinecke (9): dasd: Clarify comment dasd: make number of retries configurable dasd: process all requests in the device tasklet dasd: Implement block timeout handling dasd: Reduce amount of messages for specific errors dasd: detailed I/O errors block: check for timeout function in blk_rq_timed_out() dasd: Add 'timeout' attribute dasd: Fail all requests when DASD_FLAG_ABORTIO is set arch/s390/include/uapi/asm/dasd.h |4 + block/blk-core.c |3 + block/blk-timeout.c |5 +- drivers/s390/block/dasd.c | 115 + drivers/s390/block/dasd_devmap.c | 97 +++ drivers/s390/block/dasd_diag.c|8 ++- drivers/s390/block/dasd_eckd.c| 15 - drivers/s390/block/dasd_erp.c |8 +++ drivers/s390/block/dasd_fba.c | 10 +++- drivers/s390/block/dasd_int.h | 10 +++ drivers/s390/block/dasd_ioctl.c | 59 +++ 11 files changed, 313 insertions(+), 21 deletions(-) -- 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/
[PATCH 1/9] dasd: Clarify comment
dasd_cancel_req will never return 1, only 0. Signed-off-by: Hannes Reinecke --- drivers/s390/block/dasd.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c index 29225e1..09ddf70 100644 --- a/drivers/s390/block/dasd.c +++ b/drivers/s390/block/dasd.c @@ -2313,8 +2313,7 @@ int dasd_sleep_on_immediatly(struct dasd_ccw_req *cqr) * Cancels a request that was started with dasd_sleep_on_req. * This is useful to timeout requests. The request will be * terminated if it is currently in i/o. - * Returns 1 if the request has been terminated. - *0 if there was no need to terminate the request (not started yet) + * Returns 0 if request termination was successful *negative error code if termination failed * Cancellation of a request is an asynchronous operation! The calling * function has to wait until the request is properly returned via callback. @@ -2351,7 +2350,6 @@ int dasd_cancel_req(struct dasd_ccw_req *cqr) return rc; } - /* * SECTION: Operations of the dasd_block layer. */ -- 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/
[PATCH 2/9] dasd: make number of retries configurable
Instead of having the number of retries hard-coded in the various
functions we should be using a default retry value, which can
be modified via sysfs.
Signed-off-by: Hannes Reinecke
---
drivers/s390/block/dasd_devmap.c | 41 ++
drivers/s390/block/dasd_diag.c |3 +-
drivers/s390/block/dasd_eckd.c | 11 ++---
drivers/s390/block/dasd_fba.c|5 +++-
drivers/s390/block/dasd_int.h|3 ++
5 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/drivers/s390/block/dasd_devmap.c b/drivers/s390/block/dasd_devmap.c
index c196827..d237e31 100644
--- a/drivers/s390/block/dasd_devmap.c
+++ b/drivers/s390/block/dasd_devmap.c
@@ -1241,6 +1241,46 @@ dasd_expires_store(struct device *dev, struct
device_attribute *attr,
static DEVICE_ATTR(expires, 0644, dasd_expires_show, dasd_expires_store);
+static ssize_t
+dasd_retries_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct dasd_device *device;
+ int len;
+
+ device = dasd_device_from_cdev(to_ccwdev(dev));
+ if (IS_ERR(device))
+ return -ENODEV;
+ len = snprintf(buf, PAGE_SIZE, "%lu\n", device->default_retries);
+ dasd_put_device(device);
+ return len;
+}
+
+static ssize_t
+dasd_retries_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct dasd_device *device;
+ unsigned long val;
+
+ device = dasd_device_from_cdev(to_ccwdev(dev));
+ if (IS_ERR(device))
+ return -ENODEV;
+
+ if ((strict_strtoul(buf, 10, ) != 0) ||
+ (val > DASD_RETRIES_MAX)) {
+ dasd_put_device(device);
+ return -EINVAL;
+ }
+
+ if (val)
+ device->default_retries = val;
+
+ dasd_put_device(device);
+ return count;
+}
+
+static DEVICE_ATTR(retries, 0644, dasd_retries_show, dasd_retries_store);
+
static ssize_t dasd_reservation_policy_show(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -1351,6 +1391,7 @@ static struct attribute * dasd_attrs[] = {
_attr_erplog.attr,
_attr_failfast.attr,
_attr_expires.attr,
+ _attr_retries.attr,
_attr_reservation_policy.attr,
_attr_last_known_reservation_state.attr,
_attr_safe_offline.attr,
diff --git a/drivers/s390/block/dasd_diag.c b/drivers/s390/block/dasd_diag.c
index 704488d..905b2c0 100644
--- a/drivers/s390/block/dasd_diag.c
+++ b/drivers/s390/block/dasd_diag.c
@@ -359,6 +359,7 @@ dasd_diag_check_device(struct dasd_device *device)
}
device->default_expires = DIAG_TIMEOUT;
+ device->default_retries = DIAG_MAX_RETRIES;
/* Figure out position of label block */
switch (private->rdc_data.vdev_class) {
@@ -555,7 +556,7 @@ static struct dasd_ccw_req *dasd_diag_build_cp(struct
dasd_device *memdev,
recid++;
}
}
- cqr->retries = DIAG_MAX_RETRIES;
+ cqr->retries = memdev->default_retries;
cqr->buildclk = get_clock();
if (blk_noretry_request(req) ||
block->base->features & DASD_FEATURE_FAILFAST)
diff --git a/drivers/s390/block/dasd_eckd.c b/drivers/s390/block/dasd_eckd.c
index e37bc16..5b5b50b 100644
--- a/drivers/s390/block/dasd_eckd.c
+++ b/drivers/s390/block/dasd_eckd.c
@@ -1679,6 +1679,9 @@ dasd_eckd_check_characteristics(struct dasd_device
*device)
/* set default timeout */
device->default_expires = DASD_EXPIRES;
+ /* set default retry count */
+ device->default_retries = DASD_RETRIES;
+
if (private->gneq) {
value = 1;
for (i = 0; i < private->gneq->timeout.value; i++)
@@ -2529,7 +2532,7 @@ static struct dasd_ccw_req *dasd_eckd_build_cp_cmd_single(
cqr->block = block;
cqr->expires = startdev->default_expires * HZ; /* default 5 minutes */
cqr->lpm = startdev->path_data.ppm;
- cqr->retries = 256;
+ cqr->retries = startdev->default_retries;
cqr->buildclk = get_clock();
cqr->status = DASD_CQR_FILLED;
return cqr;
@@ -2704,7 +2707,7 @@ static struct dasd_ccw_req *dasd_eckd_build_cp_cmd_track(
cqr->block = block;
cqr->expires = startdev->default_expires * HZ; /* default 5 minutes */
cqr->lpm = startdev->path_data.ppm;
- cqr->retries = 256;
+ cqr->retries = startdev->default_retries;
cqr->buildclk = get_clock();
cqr->status = DASD_CQR_FILLED;
return cqr;
@@ -2997,7 +3000,7 @@ static struct dasd_ccw_req *dasd_eckd_build_cp_tpm_track(
cqr->block = block;
cqr->expires = startdev->default_expires * HZ; /* default 5 minutes */
cqr->lpm = startdev->path_data.ppm;
- cqr->retries = 256;
+ cqr->retries = startdev->default_retries;
[PATCH 4/9] dasd: Implement block timeout handling
This patch implements generic block layer timeout handling
callbacks for DASDs. When the timeout expires the respective
cqr is aborted.
With this timeout handler time-critical request abort
is guaranteed as the abort does not depend on the internal
state of the various DASD driver queues.
Signed-off-by: Hannes Reinecke
Acked-by: Stefan Weinhuber
---
drivers/s390/block/dasd.c | 76
drivers/s390/block/dasd_diag.c |5 ++-
drivers/s390/block/dasd_eckd.c |4 ++
drivers/s390/block/dasd_fba.c |5 ++-
4 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index 20b7517..0406325 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -2484,8 +2484,10 @@ static void __dasd_process_request_queue(struct
dasd_block *block)
*/
cqr->callback_data = (void *) req;
cqr->status = DASD_CQR_FILLED;
+ req->completion_data = cqr;
blk_start_request(req);
list_add_tail(>blocklist, >ccw_queue);
+ INIT_LIST_HEAD(>devlist);
dasd_profile_start(block, cqr, req);
}
}
@@ -2753,6 +2755,80 @@ static void do_dasd_request(struct request_queue *queue)
}
/*
+ * Block timeout callback, called from the block layer
+ *
+ * request_queue lock is held on entry.
+ *
+ * Return values:
+ * BLK_EH_RESET_TIMER if the request should be left running
+ * BLK_EH_NOT_HANDLED if the request is handled or terminated
+ *by the driver.
+ */
+enum blk_eh_timer_return dasd_times_out(struct request *req)
+{
+ struct dasd_ccw_req *cqr = req->completion_data;
+ struct dasd_block *block = req->q->queuedata;
+ struct dasd_device *device;
+ int rc = 0;
+
+ if (!cqr)
+ return BLK_EH_NOT_HANDLED;
+
+ device = cqr->startdev ? cqr->startdev : block->base;
+ DBF_DEV_EVENT(DBF_WARNING, device,
+ " dasd_times_out cqr %p status %x",
+ cqr, cqr->status);
+
+ spin_lock(>queue_lock);
+ spin_lock(get_ccwdev_lock(device->cdev));
+ cqr->retries = -1;
+ cqr->intrc = -ETIMEDOUT;
+ if (cqr->status >= DASD_CQR_QUEUED) {
+ spin_unlock(get_ccwdev_lock(device->cdev));
+ rc = dasd_cancel_req(cqr);
+ } else if (cqr->status == DASD_CQR_FILLED ||
+ cqr->status == DASD_CQR_NEED_ERP) {
+ cqr->status = DASD_CQR_TERMINATED;
+ spin_unlock(get_ccwdev_lock(device->cdev));
+ } else if (cqr->status == DASD_CQR_IN_ERP) {
+ struct dasd_ccw_req *searchcqr, *nextcqr, *tmpcqr;
+
+ list_for_each_entry_safe(searchcqr, nextcqr,
+>ccw_queue, blocklist) {
+ tmpcqr = searchcqr;
+ while (tmpcqr->refers)
+ tmpcqr = tmpcqr->refers;
+ if (tmpcqr != cqr)
+ continue;
+ /* searchcqr is an ERP request for cqr */
+ searchcqr->retries = -1;
+ searchcqr->intrc = -ETIMEDOUT;
+ if (searchcqr->status >= DASD_CQR_QUEUED) {
+ spin_lock(get_ccwdev_lock(device->cdev));
+ rc = dasd_cancel_req(searchcqr);
+ spin_unlock(get_ccwdev_lock(device->cdev));
+ } else if ((searchcqr->status == DASD_CQR_FILLED) ||
+ (searchcqr->status == DASD_CQR_NEED_ERP)) {
+ searchcqr->status = DASD_CQR_TERMINATED;
+ rc = 0;
+ } else if (searchcqr->status == DASD_CQR_IN_ERP) {
+ /*
+* Shouldn't happen; most recent ERP
+* request is at the front of queue
+*/
+ continue;
+ }
+ break;
+ }
+ spin_unlock(get_ccwdev_lock(device->cdev));
+ }
+ dasd_schedule_block_bh(block);
+ spin_unlock(>queue_lock);
+
+ return rc ? BLK_EH_RESET_TIMER : BLK_EH_NOT_HANDLED;
+}
+
+/*
* Allocate and initialize request queue and default I/O scheduler.
*/
static int dasd_alloc_queue(struct dasd_block *block)
diff --git a/drivers/s390/block/dasd_diag.c b/drivers/s390/block/dasd_diag.c
index 905b2c0..9e245ce 100644
--- a/drivers/s390/block/dasd_diag.c
+++ b/drivers/s390/block/dasd_diag.c
@@ -583,7 +583,10 @@ dasd_diag_free_cp(struct dasd_ccw_req *cqr, struct request
*req)
static void dasd_diag_handle_terminated_request(struct dasd_ccw_req *cqr)
{
- cqr->status = DASD_CQR_FILLED;
+ if (cqr->retries < 0)
+
Re: [PATCH v4 3/4] ARM: Exynos5250: Add clock information for dwc3-exynos
Hi Tomasz,
On Wed, Jan 16, 2013 at 8:35 PM, Vivek Gautam wrote:
> Hi Tomasz,
>
>
> On Wed, Jan 16, 2013 at 1:19 PM, Tomasz Figa wrote:
>> Hi Vivek,
>>
>> Don't you need also some clkdev lookup entry to make the clock available
>> in the driver?
>>
>
> This clock source we added with a motive of completion, however it's
> not being used as of now.
> As far as i could see the lookup structure contains clocks for devices
> having multiple instances.
> Do you feel that i should be adding an entry in clk_lookup structure ?
> May be i am missing here something. Can you please elaborate on the
> use-case of clk_lookup
> entries.
>
As indicated above "sclk_usbdrd30" is added with a motive of
completion, however it's
not being used as of now.
And "usbdrd30" is the actual device clock used, where 'drd30' is just
an indicative of
'dual role device and usb 3.0'. So the clock name 'usbdrd30' is the
usb 3.0 clock for drd.
Am i missing something that you wanted to convey here ?
>>
>> On Tuesday 15 of January 2013 19:08:31 Vivek Gautam wrote:
>>> Adding necessary device clock to exynos5 needed for
>>> the DWC3 controller.
>>>
>>> Signed-off-by: Vivek Gautam
>>> ---
>>> arch/arm/mach-exynos/clock-exynos5.c | 24
>>> 1 files changed, 24 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/clock-exynos5.c
>>> b/arch/arm/mach-exynos/clock-exynos5.c index 0208c3a..13af020 100644
>>> --- a/arch/arm/mach-exynos/clock-exynos5.c
>>> +++ b/arch/arm/mach-exynos/clock-exynos5.c
>>> @@ -757,6 +757,11 @@ static struct clk exynos5_init_clocks_off[] = {
>>> .enable = exynos5_clk_ip_fsys_ctrl ,
>>> .ctrlbit= (1 << 18),
>>> }, {
>>> + .name = "usbdrd30",
>>> + .parent = _clk_aclk_200.clk,
>>> + .enable = exynos5_clk_ip_fsys_ctrl,
>>> + .ctrlbit= (1 << 19),
>>> + }, {
>>> .name = "usbotg",
>>> .enable = exynos5_clk_ip_fsys_ctrl,
>>> .ctrlbit= (1 << 7),
>>> @@ -1035,6 +1040,16 @@ static struct clksrc_sources exynos5_clkset_group
>>> = { .nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
>>> };
>>>
>>> +struct clk *exynos5_clkset_usbdrd30_list[] = {
>>> + [0] = _clk_mout_mpll.clk,
>>> + [1] = _clk_mout_cpll.clk,
>>> +};
>>> +
>>> +struct clksrc_sources exynos5_clkset_usbdrd30 = {
>>> + .sources= exynos5_clkset_usbdrd30_list,
>>> + .nr_sources = ARRAY_SIZE(exynos5_clkset_usbdrd30_list),
>>> +};
>>> +
>>> /* Possible clock sources for aclk_266_gscl_sub Mux */
>>> static struct clk *clk_src_gscl_266_list[] = {
>>> [0] = _ext_xtal_mux,
>>> @@ -1329,6 +1344,15 @@ static struct clksrc_clk exynos5_clksrcs[] = {
>>> .parent = _clk_mout_cpll.clk,
>>> },
>>> .reg_div = { .reg = EXYNOS5_CLKDIV_GEN, .shift = 4, .size = 3
>> },
>>> + }, {
>>> + .clk= {
>>> + .name = "sclk_usbdrd30",
>>> + .enable = exynos5_clksrc_mask_fsys_ctrl,
>>> + .ctrlbit= (1 << 28),
>>> + },
>>> + .sources = _clkset_usbdrd30,
>>> + .reg_src = { .reg = EXYNOS5_CLKSRC_FSYS, .shift = 28, .size =
>> 1 },
>>> + .reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 24, .size =
>> 4 },
>>> },
>>> };
>
>
--
Thanks & Regards
Vivek
--
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/5] PCI: revert preparing for wakeup in runtime-suspend finalization
Rafael J. Wysocki wrote:
On Monday, January 28, 2013 04:17:42 PM Bjorn Helgaas wrote:
[+cc Rafael]
On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
wrote:
This patch effectively reverts commit 42eca2302146fed51335b95128e949ee6f54478f
("PCI: Don't touch card regs after runtime suspend D3")
| This patch checks whether the pci state is saved and doesn't attempt to hit
| any registers after that point if it is.
This seems completely wrong. Yes, PCI configuration space has been saved by
driver, but this doesn't means that all job is done and device has been
suspended and ready for waking up in the future.
For example driver e1000e for ethernet in my thinkpad x220 saves pci-state
but device cannot wakeup after that, because it needs some ACPI callbacks
which usually called from pci_finish_runtime_suspend().
| Optimus (dual-gpu) laptops seem to have their own form of D3cold, but
| unfortunately enter it on normal D3 transitions via the ACPI callback.
Hardware which disappears from the bus unexpectedly is exception, so let's
handle it as an exception. Its driver should set device state to D3cold and
the rest code will handle it properly.
Functions in D3cold don't have power, so it's completely expected that
they would disappear from the bus and not respond to config accesses.
Maybe Dave was referring to D3hot, where functions *should* respond to
config accesses. I dunno.
Just to be clear, it sounds like 42eca230 caused a regression on your
e1000e device? If so, I guess we should revert it unless you and Dave
can figure out a better patch that fixes both your e1000e device and
the Optimus issue.
Yes, if there's a regression, let's revert it, but I'd like the regression
to be described clearly.
Yep, this is regression.
commit 42eca2302146fed51335b95128e949ee6f54478f ("PCI: Don't touch
card regs after runtime suspend D3") changes state convention during
runtime-suspend transaction too much. If PCI configuration space
has been saved by driver that does not means that all job is done
and device has been suspended and ready for waking up in the future.
e1000e saves pci-config space itself, but it requires operations which
pci_finish_runtime_suspend() does: preparing for wake (calling particular
platform pm-callbacks) and switching to proper sleep state.
Thanks,
Rafael
--
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 V7 0/3] handle polling errors in vhost/vhost_net
On 01/28/2013 07:05 PM, Jason Wang wrote: > This is an update version of last version to fix the handling of polling > errors > in vhost/vhost_net. > > Currently, vhost and vhost_net ignore polling errors which can lead kernel > crashing when it tries to remove itself from waitqueue after the polling > failure. Fix this by: > > - examing the POLLERR when setting backend and report erros to userspace > - let tun always add to waitqueue in .poll() after the queue is created even > if > it was detached. Fixed my kernel oops here, thank you. Tested-by: Wanlong Gao > > Changes from V6: > - don't use RCU to protect the tfile->detached. > > Changes from V5: > - use rcu_dereference() instead of the wrong rtnl_dereference() in data path > - test with CONFIG_PROVE_RCU > > Changes from V4: > - check the detached state by tfile->detached and protect it by RCU > > Changes from V3: > - make a smaller patch that doesn't touch the whole polling state and only > check > the polliner errors in backend setting. > - add a patch that allows tuntap to do polling/reading/writing when detached > which could simplify the work of its user. > > Changes from v2: > - check poll->wqh instead of the wrong assumption about POLLERR and waitqueue > - drop the whole tx polling state check since it was replaced by the wqh > checking > - drop the buggy tuntap patch > > Changes from v1: > - restore the state before the ioctl when vhost_init_used() fails > - log the error when meet polling errors in the data path > - don't put into waitqueue when tun_chr_poll() return POLLERR > > Jason Wang (3): > vhost_net: correct error handling in vhost_net_set_backend() > vhost_net: handle polling errors when setting backend > tuntap: allow polling/writing/reading when detached > > drivers/net/tun.c | 25 - > drivers/vhost/net.c | 41 - > drivers/vhost/vhost.c | 18 +++--- > drivers/vhost/vhost.h |2 +- > 4 files changed, 60 insertions(+), 26 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/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: davinci: da850: configure CS2(aemif) for norflash
Hello Kumar,
On 29.01.2013 06:19, Kumar, Anil wrote:
> Configure 16 bit data bus width for CS2(aemif) to use the norflash on
> DA850.
>
> Signed-off-by: Kumar, Anil
> ---
> :100644 100644 37c27af... 540e284... March/arm/mach-davinci/da8xx-dt.c
> arch/arm/mach-davinci/da8xx-dt.c | 17 +
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
> b/arch/arm/mach-davinci/da8xx-dt.c
> index 37c27af..540e284 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -38,12 +38,29 @@ static void __init da8xx_init_irq(void)
> }
>
> #ifdef CONFIG_ARCH_DAVINCI_DA850
> +#define DA8XX_AEMIF_CE2CFG_OFFSET 0x10
> +#define DA8XX_AEMIF_ASIZE_16BIT 0x1
Hmm... I am not really happy with such defines, because different
boards need maybe different settings, and this should be catched
by the device tree ... Couldn't we add this infos in the
device tree? I tried such an approach here:
First post and some discussion:
https://lists.ozlabs.org/pipermail/devicetree-discuss/2011-December/010030.html
Nori suggested here
https://lists.ozlabs.org/pipermail/devicetree-discuss/2011-December/011330.html
to move such an driver out of arch/arm and IIRC it was
suggested to move it into the mfd framework. I currently
not know, if there was such a sort of patches, to get this
in the mfd subsystem, but I think, this CS settings should be
done like the pinmux settings ...
My last posted version of this patch:
https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-March/013036.html
Maybe it is worth to discuss this again?
> +
> +static void __init da8xx_init_nor(void)
> +{
> + void __iomem *aemif_addr;
> +
> + aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K);
> +
> + /* Configure data bus width of CS2 to 16 bit */
> + writel(readl(aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET) |
> + DA8XX_AEMIF_ASIZE_16BIT,
> + aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET);
I vote for avoiding such board specific code in a generic
approach ...
> +
> + iounmap(aemif_addr);
> +}
>
> static void __init da850_init_machine(void)
> {
> of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>
> da8xx_uart_clk_enable();
> + da8xx_init_nor();
> }
>
> static const char *da850_boards_compat[] __initdata = {
>
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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: the patch "perf tools: Update Makefile for Android" broke 3.8-rc perf build.
Hi Thomas,
On Tue, 29 Jan 2013 05:45:29 +0200, Thomas Backlund wrote:
> Linux Kernel Mailing List skrev 12.12.2012 05:13:
>> Gitweb:
>> http://git.kernel.org/linus/;a=commit;h=d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4
>> Commit: d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4
>> Parent: 78da39faf7c903bb6e3c20a726fde1bf98d10af8
>> Author: Irina Tirdea
>> AuthorDate: Mon Oct 8 09:43:27 2012 +0300
>> Committer: Arnaldo Carvalho de Melo
>> CommitDate: Mon Oct 8 17:42:16 2012 -0300
>>
>> perf tools: Update Makefile for Android
>>
>> For cross-compiling on Android, some specific changes are needed in
>> the Makefile.
>>
>
> The above patch broke perf build on i586 and x86_64:
>
> [tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1
> HAVE_CPLUS_DEMANGLE=1 prefix=%{_prefix} all
> CHK -fstack-protector-all
> CHK -Wstack-protector
> CHK -Wvolatile-register-var
> CHK bionic
> :1:31: fatal error: android/api-level.h: No such file or directory
> compilation terminated.
Are you sure does it break your build? In my case, it only hid the
compilation from user and kept the work behind us. When I run a clean
build I could see a final perf binary there.
It's because QUIET_{CC,LINK,...} honour the -s option but TRY_CC_MSG not
and maybe we need something like this:
>From 5015f5f4961006e31b9298caeb86b3cc0e31bcf7 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Tue, 29 Jan 2013 15:48:36 +0900
Subject: [PATCH] perf tools: Hide feature test result on make -s
Other commands like QUIET_CC already honour -s option of make so the
try-cc should do the same. Make it really quiet if -s option is given
and ignore V=1 (it's only meaningful without -s option).
Reported-by: Thomas Backlund
Signed-off-by: Namhyung Kim
---
tools/perf/config/utilities.mak | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/perf/config/utilities.mak b/tools/perf/config/utilities.mak
index e5413125e6bb..9d202fce1306 100644
--- a/tools/perf/config/utilities.mak
+++ b/tools/perf/config/utilities.mak
@@ -181,10 +181,13 @@ _gea_err = $(if $(1),$(error Please set '$(1)'
appropriately))
# try-cc
# Usage: option = $(call try-cc, source-to-build, cc-options, msg)
-ifndef V
TRY_CC_OUTPUT= > /dev/null 2>&1
-endif
+ifneq ($(findstring $(MAKEFLAGS),s),s)
TRY_CC_MSG=echo "CHK $(3)" 1>&2;
+ifdef V
+TRY_CC_OUTPUT=
+endif
+endif
try-cc = $(shell sh -c \
'TMP="$(OUTPUT)$(TMPOUT)."; \
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] introduce static_vm for ARM-specific static mapped area
On Mon, Jan 28, 2013 at 01:04:24PM -0500, Nicolas Pitre wrote: > On Mon, 28 Jan 2013, Will Deacon wrote: > > > Hello, > > > > On Thu, Jan 24, 2013 at 01:28:51AM +, Joonsoo Kim wrote: > > > In current implementation, we used ARM-specific flag, that is, > > > VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area. > > > The purpose of static mapped area is to re-use static mapped area when > > > entire physical address range of the ioremap request can be covered > > > by this area. > > > > > > This implementation causes needless overhead for some cases. > > > For example, assume that there is only one static mapped area and > > > vmlist has 300 areas. Every time we call ioremap, we check 300 areas for > > > deciding whether it is matched or not. Moreover, even if there is > > > no static mapped area and vmlist has 300 areas, every time we call > > > ioremap, we check 300 areas in now. > > > > > > If we construct a extra list for static mapped area, we can eliminate > > > above mentioned overhead. > > > With a extra list, if there is one static mapped area, > > > we just check only one area and proceed next operation quickly. > > > > > > In fact, it is not a critical problem, because ioremap is not frequently > > > used. But reducing overhead is better idea. > > > > > > Another reason for doing this work is for removing vm_struct list > > > management, > > > entirely. For more information, look at the following link. > > > http://lkml.org/lkml/2012/12/6/184 > > > > First patch looks good (removing the unused vmregion stuff) but I'm not so > > sure about the rest of it. If you really care about ioremap performance, > > perhaps it would be better to have a container struct around the vm_struct > > for static mappings and then stick them in an augmented rbtree so you can > > efficiently find the mapping encompassing a particular physical address? > > How can ioremap performance be a problem is the question I had since the > beginning. > > Firstly, ioremap is _not_ meant to be used in performance critical > paths. > > Secondly, there shouldn't be _that_ many entries on the vmlist such as > 300. That sounds a bit excessive. > > So please, can we discuss the reasons that motivated those patches in > the first place? Maybe that's where the actual problem is. Hello, Wiil and Nicolas. First of all, thanks for reviewing. There is another reason for doing this work. As mentioned above, I try to remove list management for vm_struct(vmlist), entirely. For that purpose, removing architecture dependency against vmlist is needed. Below link is for my RFC patch trying to remove list management for vm_struct. http://lkml.org/lkml/2012/12/6/184 Removing dependency for other architectures is rather trivial, but for ARM, it is not trivial case. So I prepared this patchset. My description makes you missleading possibly. Sorry for this. Answer for your other questions is below. I know ioremap is _not_ meant to be used in performance critical paths, and I mentioned it earlier. "In fact, it is not a critical problem, because ioremap is not frequently used. But reducing overhead is better idea." And, there are many entries on the vmlist for my test devices(Android phone). I saw more than 300 entries in former days, but today, I re-check it and find 230~250 entries. 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 0/2] kvm: IOMMU read-only mapping support
On Tue, Jan 29, 2013 at 11:06:43AM +0800, Xiao Guangrong wrote: > On 01/28/2013 06:59 PM, Gleb Natapov wrote: > > On Fri, Jan 25, 2013 at 11:28:40AM +0800, Xiao Guangrong wrote: > >> On 01/25/2013 09:17 AM, Takuya Yoshikawa wrote: > >>> On Thu, 24 Jan 2013 15:03:57 -0700 > >>> Alex Williamson wrote: > >>> > A couple patches to make KVM IOMMU support honor read-only mappings. > This causes an un-map, re-map when the read-only flag changes and > makes use of it when setting IOMMU attributes. Thanks, > >>> > >>> Looks good to me. > >>> > >>> I think I can naturally update my patch after this gets merged. > >>> > >> > >> Please wait. > >> > >> The commit c972f3b1 changed the write-protect behaviour - it does > >> wirte-protection only when dirty flag is set. > >> [ I did not see this commit when we discussed the problem before. ] > >> > >> Further more, i notice that write-protect is not enough, when do sync > >> shadow page: > >> > >> FNAME(sync_page): > >> > >>host_writable = sp->spt[i] & SPTE_HOST_WRITEABLE; > >> > >>set_spte(vcpu, >spt[i], pte_access, > >> PT_PAGE_TABLE_LEVEL, gfn, > >> spte_to_pfn(sp->spt[i]), true, false, > >> host_writable); > >> > >> It sets spte based on the old value that means the readonly flag check > >> is missed. We need to call kvm_arch_flush_shadow_all under this case. > > Why not just disallow changing memory region KVM_MEM_READONLY flag > > without deleting the region? > > It will introduce some restriction when VM-sharing-mem is being implemented, > but we need to do some optimization for it, at least, properly write-protect > readonly pages (fix sync_page()) instead of zap_all_page. > What is VM-sharing-mem? > So, i guess we can do the simple fix first. > By simple fix you mean calling kvm_arch_flush_shadow_all() on READONLY flag change? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] e1000e: fix pci device enable counter balance
Bjorn Helgaas wrote:
[+cc Rafael @sisk.pl]
On Mon, Jan 28, 2013 at 4:09 PM, Bjorn Helgaas wrote:
[+cc Rafael]
On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
wrote:
__e1000_shutdown() calls pci_disable_device() at the end, thus __e1000_resume()
should call pci_enable_device_mem() to keep enable counter in balance.
Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35
Signed-off-by: Konstantin Khlebnikov
Cc: e1000-de...@lists.sourceforge.net
Cc: Jeff Kirsher
Cc: Bruce Allan
---
drivers/net/ethernet/intel/e1000e/netdev.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 2853c11..6bce796 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5598,6 +5598,13 @@ static int __e1000_resume(struct pci_dev *pdev)
pci_restore_state(pdev);
pci_save_state(pdev);
+ err = pci_enable_device_mem(pdev);
+ if (err) {
+ dev_err(>dev,
+ "Cannot re-enable PCI device after suspend.\n");
+ return err;
+ }
Reviewed-by: Bjorn Helgaas
Seems right to me, and the other users I looked at (igb, azx,
virtio_pci) call pci_disable_device() in .suspend() and call
pci_enable_device() in .resume() as you propose to do here.
I assume the e1000 folks will handle this patch (and the previous one).
+
e1000e_set_interrupt_capability(adapter);
if (netif_running(netdev)) {
err = e1000_request_irq(adapter);
I'm still missing something. In your original report
(https://lkml.org/lkml/2013/1/1/25), you noticed that "enable_cnt ==
0" immediately after boot, after e1000e had claimed the device:
Yep, it rise counter from 0 to 1, and runtime-suspend immediately
decrease it back to 0.
Right after boot it looks like this:
root@zurg:/sys/bus/pci/devices# lspci
...
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network
Connection (rev 04)
...
root@zurg:/sys/bus/pci/devices# cat \:00\:19.0/enable
0
here must be '1', not '0'
But these patches only change the e1000e suspend/resume path. How
could they change the enable_cnt before you've even done a suspend?
suspend/resume and runtime_suspend/runtime_resume callbacks calls the one
set of functions: __e1000_shutdown() / __e1000_resume()
Any suspend-resume cycle breaks enable_ent balance.
Thus right after boot and first runtime-suspend device cannot wake up
due to first sort of bugs and after first s2ram suspend-resume cycle
driver breaks it's enable_cnt and device no longer can sleep due to
second sort of bugs.
Bjorn
--
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: One of these things (CONFIG_HZ) is not like the others..
Jon, On Tuesday 29 January 2013 05:31 AM, John Stultz wrote: On 01/27/2013 10:08 PM, Santosh Shilimkar wrote: On Tuesday 22 January 2013 08:35 PM, Santosh Shilimkar wrote: On Tuesday 22 January 2013 08:21 PM, Russell King - ARM Linux wrote: On Tue, Jan 22, 2013 at 03:44:03PM +0530, Santosh Shilimkar wrote: [..] Thanks for expanding it. It is really helpful. And I think further discussion is pointless until such research has been done (or someone who _really_ knows the time keeping/timer/sched code inside out comments.) Fully agree about experimentation to re-asses the drift. From what I recollect from past, few OMAP customers did report the time drift issue and that is how the switch from 100 --> 128 happened. Anyway I have added the suggested task to my long todo list. So I tried to see if any time drift with HZ = 100 on OMAP. I ran the setup for 62 hours and 27 mins with time synced up once with NTP server. I measure about ~174 millisecond drift which is almost noise considering the observed duration was ~22482 milliseconds. So 174ms drift doesn't sound great, as < 2ms (often much less - though that depends on how close the server is) can be expected with NTP. Although its not clear how you were measuring: Did you see a max 174ms offset while trying to sync with NTP? Was that offset shortly after starting NTP or after NTP converged down? To avoid the server latency, we didn't do continuous sync. The time was synced in the beginning and after 62.5 hours (#ntpd -qg) and the drift of about 174 ms was observed. As you said this could be because of server sync time along with probably some addition from system calls from #ntpd. As mentioned, the other run with HZ = 128 which started 15 hours 20 mins is already showing about 24 mS drift now. I will let it run for couple of more days just to have similar duration run. Regards, santosh -- 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/core/rcu 4/4] rcu: Make rcutorture's shuffler task shuffle recently added tasks
On Sun, Jan 27, 2013 at 09:47:47PM +1100, Josh Triplett wrote:
> On Sat, Jan 26, 2013 at 04:05:20PM -0800, Paul E. McKenney wrote:
> > From: "Paul E. McKenney"
> >
> > A number of kthreads have been added to rcutorture, but the shuffler
> > task was not informed of them, and thus did not shuffle them. This
> > commit therefore adds the requisite shuffling.
> >
> > Signed-off-by: Paul E. McKenney
>
> This also makes an unrelated semantic change, and several unrelated
> whitespace changes.
>
> > ---
> > kernel/rcutorture.c | 24
> > 1 files changed, 20 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
> > index a583f1c..3ebc8bf 100644
> > --- a/kernel/rcutorture.c
> > +++ b/kernel/rcutorture.c
> > @@ -846,7 +846,7 @@ static int rcu_torture_boost(void *arg)
> > /* Wait for the next test interval. */
> > oldstarttime = boost_starttime;
> > while (ULONG_CMP_LT(jiffies, oldstarttime)) {
> > - schedule_timeout_uninterruptible(1);
> > + schedule_timeout_interruptible(oldstarttime - jiffies);
>
> This change doesn't seem related, and the commit message doesn't explain
> it either. Could you split it out into a separate commit and document
> the rationale, please?
Ah, it is related because the shuffling is trying to keep CPUs idle,
which means that we don't want all the boost kthreads waking up every
CPU every jiffy. I agree that this is not obvious, so I have updated
the commit message to call this out.
> > rcu_stutter_wait("rcu_torture_boost");
> > if (kthread_should_stop() ||
> > fullstop != FULLSTOP_DONTSTOP)
> > @@ -1318,19 +1318,35 @@ static void rcu_torture_shuffle_tasks(void)
> > set_cpus_allowed_ptr(reader_tasks[i],
> > shuffle_tmp_mask);
> > }
> > -
> > if (fakewriter_tasks) {
> > for (i = 0; i < nfakewriters; i++)
> > if (fakewriter_tasks[i])
> > set_cpus_allowed_ptr(fakewriter_tasks[i],
> > shuffle_tmp_mask);
> > }
> > -
> > if (writer_task)
> > set_cpus_allowed_ptr(writer_task, shuffle_tmp_mask);
> > -
>
> These three whitespace changes seem unrelated as well.
Some cleanup while in the neighborhood. ;-)
I added this to the commit message as well.
Thanx, Paul
> > if (stats_task)
> > set_cpus_allowed_ptr(stats_task, shuffle_tmp_mask);
> > + if (stutter_task)
> > + set_cpus_allowed_ptr(stutter_task, shuffle_tmp_mask);
> > + if (fqs_task)
> > + set_cpus_allowed_ptr(fqs_task, shuffle_tmp_mask);
> > + if (shutdown_task)
> > + set_cpus_allowed_ptr(shutdown_task, shuffle_tmp_mask);
> > +#ifdef CONFIG_HOTPLUG_CPU
> > + if (onoff_task)
> > + set_cpus_allowed_ptr(onoff_task, shuffle_tmp_mask);
> > +#endif /* #ifdef CONFIG_HOTPLUG_CPU */
> > + if (stall_task)
> > + set_cpus_allowed_ptr(stall_task, shuffle_tmp_mask);
> > + if (barrier_cbs_tasks)
> > + for (i = 0; i < n_barrier_cbs; i++)
> > + if (barrier_cbs_tasks[i])
> > + set_cpus_allowed_ptr(barrier_cbs_tasks[i],
> > +shuffle_tmp_mask);
> > + if (barrier_task)
> > + set_cpus_allowed_ptr(barrier_task, shuffle_tmp_mask);
>
> The rest of this seems fine.
>
> - Josh Triplett
>
--
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-next: manual merge of the tty tree with the input tree
Hi Joe, On Mon, Jan 28, 2013 at 10:26:47PM -0800, Joe Millenbach wrote: > On Mon, Jan 28, 2013 at 9:33 PM, Dmitry Torokhov > wrote: > > Please revert the input changes and add *ONE* new dependency to the > > serport driver. > > > > Thanks. > > > > -- > > Dmitry > > Apologies on this. I must have misunderstood the problem originally, > and I definitely misunderstood your solution until I looked at it > again. I just went through applying the changes I'd created minus the > driver/input changes, plus your SERPORT TTY dependency. You were > right that it solves the dependency issue and is much more elegant. I > thought it was going to leave dangling select dependencies for users > to deal with later. Sorry I was so hesitant at first. > > I'll be making up a new patch for Greg after I get it reviewed. Thank you for making the changes. By the "dangling select dependencies" I assume you mean "select SERIO" that several drivers do? "select SERIO" selects only serio core which is self contained and has no additional dependencies [so far], that is why it is being selected rather than being depended upon. Thanks. -- Dmitry -- 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/5] e1000e: fix resuming from runtime-suspend
Rafael J. Wysocki wrote:
On Monday, January 28, 2013 04:05:33 PM Bjorn Helgaas wrote:
[+cc Rafael, author of patch you cited]
On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
wrote:
Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35
Signed-off-by: Konstantin Khlebnikov
Cc: e1000-de...@lists.sourceforge.net
Cc: Jeff Kirsher
Cc: Bruce Allan
---
drivers/net/ethernet/intel/e1000e/netdev.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index fbf75fd..2853c11 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5691,14 +5691,17 @@ static int e1000_runtime_suspend(struct device *dev)
struct pci_dev *pdev = to_pci_dev(dev);
struct net_device *netdev = pci_get_drvdata(pdev);
struct e1000_adapter *adapter = netdev_priv(netdev);
+ int retval;
+ bool wake;
- if (e1000e_pm_ready(adapter)) {
- bool wake;
+ if (!e1000e_pm_ready(adapter))
+ return 0;
- __e1000_shutdown(pdev,, true);
- }
+ retval = __e1000_shutdown(pdev,, true);
+ if (!retval)
+ e1000_power_off(pdev, true, wake);
- return 0;
+ return retval;
}
static int e1000_idle(struct device *dev)
I'd like the changelog to say what the bug is and how it is being fixed in
general terms.
Ok, my bad.
Problem: ethernet device does not work (no carrier signal).
Right after boot it goes to runtime-suspend and never wake up.
Original code (before your commit) calls pci_prepare_to_sleep() and it
calls pci_enable_wake() and switches device to one of D3 state.
It seems redundant, because pci_pm_runtime_suspend() do the same thing
after calling ->runtime_suspend callback. Or rather it did it before commit
42eca2302146fed51335b95128e949ee6f54478f ("PCI: Don't touch card regs after
runtime suspend D3") and third patch aimed fix this damage.
More over seems like calling pci_enable_wake() from e1000e isn't enough for my
case,
because my enthernet cannot wakeup from runtime-suspend without third patch.
Seems like it's because pci_enable_wake() and pci_finish_runtime_suspend()
calls different pratform-pm callbacks -- platform_pci_run_wake() /
platform_pci_sleep_wake().
All this looks messy and I don't know how it should work.
If you prefer to minimize changes -- I can test how it would work without
first (this) patch. Probably fine.
Thanks,
Rafael
--
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 5/6] zswap: add to mm/
First feeling is it's simple and nice approach. Although we have some problems to decide policy, it could solve by later patch so I hope we make basic infrasture more solid by lots of comment. There are two things to review hard. 1. data structure life - when any data structure is died by whom? Please write down it in changelog or header of zswap.c 2. Flush routine - I hope it would be nice to separate it as another incremental patches if it is possible. If it's impossible, let's add lots of words. On Mon, Jan 28, 2013 at 03:49:26PM -0600, Seth Jennings wrote: > zswap is a thin compression backend for frontswap. It receives > pages from frontswap and attempts to store them in a compressed > memory pool, resulting in an effective partial memory reclaim and > dramatically reduced swap device I/O. > > Additional, in most cases, pages can be retrieved from this > compressed store much more quickly than reading from tradition > swap devices resulting in faster performance for many workloads. > > This patch adds the zswap driver to mm/ > > Signed-off-by: Seth Jennings > --- > mm/Kconfig | 15 + > mm/Makefile |1 + > mm/zswap.c | 1073 > +++ > 3 files changed, 1089 insertions(+) > create mode 100644 mm/zswap.c > > diff --git a/mm/Kconfig b/mm/Kconfig > index 278e3ab..14b9acb 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -446,3 +446,18 @@ config FRONTSWAP > and swap data is stored as normal on the matching swap device. > > If unsure, say Y to enable frontswap. > + > +config ZSWAP > + bool "In-kernel swap page compression" > + depends on FRONTSWAP && CRYPTO Couldn't we support CRYPTO optionally? > + select CRYPTO_LZO > + select ZSMALLOC > + default n > + help > + Zswap is a backend for the frontswap mechanism in the VMM. > + It receives pages from frontswap and attempts to store them > + in a compressed memory pool, resulting in an effective > + partial memory reclaim. In addition, pages and be retrieved > + from this compressed store much faster than most tradition > + swap devices resulting in reduced I/O and faster performance > + for many workloads. > diff --git a/mm/Makefile b/mm/Makefile > index 3a46287..1b1ed5c 100644 > --- a/mm/Makefile > +++ b/mm/Makefile > @@ -32,6 +32,7 @@ obj-$(CONFIG_HAVE_MEMBLOCK) += memblock.o > obj-$(CONFIG_BOUNCE) += bounce.o > obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o > obj-$(CONFIG_FRONTSWAP) += frontswap.o > +obj-$(CONFIG_ZSWAP) += zswap.o > obj-$(CONFIG_HAS_DMA)+= dmapool.o > obj-$(CONFIG_HUGETLBFS) += hugetlb.o > obj-$(CONFIG_NUMA) += mempolicy.o > diff --git a/mm/zswap.c b/mm/zswap.c > new file mode 100644 > index 000..050b6db > --- /dev/null > +++ b/mm/zswap.c > @@ -0,0 +1,1073 @@ > +/* > + * zswap-drv.c - zswap driver file > + * > + * zswap is a backend for frontswap that takes pages that are in the > + * process of being swapped out and attempts to compress them and store > + * them in a RAM-based memory pool. This results in a significant I/O > + * reduction on the real swap device and, in the case of a slow swap > + * device, can also improve workload performance. > + * > + * Copyright (C) 2012 Seth Jennings > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > +*/ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > + > +/* > +* statistics > +**/ > +/* Number of memory pages used by the compressed pool */ > +static atomic_t zswap_pool_pages = ATOMIC_INIT(0); > +/* The number of compressed pages currently stored in zswap */ > +static atomic_t zswap_stored_pages = ATOMIC_INIT(0); > +/* The number of outstanding pages awaiting writeback */ > +static atomic_t zswap_outstanding_flushes = ATOMIC_INIT(0); > + > +/* > + * The statistics below are not protected from concurrent access for > + * performance reasons so they may not be a 100% accurate. However, > + * the do provide useful information on roughly how many times a > + * certain event is occurring. > +*/ > +static u64 zswap_flushed_pages; > +static u64 zswap_reject_compress_poor; > +static u64 zswap_flush_attempted; > +static u64 zswap_reject_tmppage_fail; > +static u64
Re: linux-next: manual merge of the tty tree with the input tree
On Mon, Jan 28, 2013 at 9:33 PM, Dmitry Torokhov wrote: > Please revert the input changes and add *ONE* new dependency to the > serport driver. > > Thanks. > > -- > Dmitry Apologies on this. I must have misunderstood the problem originally, and I definitely misunderstood your solution until I looked at it again. I just went through applying the changes I'd created minus the driver/input changes, plus your SERPORT TTY dependency. You were right that it solves the dependency issue and is much more elegant. I thought it was going to leave dangling select dependencies for users to deal with later. Sorry I was so hesitant at first. I'll be making up a new patch for Greg after I get it reviewed. And thank you for your help and persistence in this, Dmitry. - Joe -- 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 0/4] Add support for LZ4-compressed kernels
Uhm... you're saying we have to be at one extreme or the other? We probably could drop the legacy lzma format, but someone might rely on it. Nicolas Pitre wrote: >On Mon, 28 Jan 2013, Andrew Morton wrote: > >> On Sat, 26 Jan 2013 14:50:43 +0900 >> Kyungsik Lee wrote: >> >> > This patchset is for supporting LZ4 compressed kernel and initial >ramdisk on >> > the x86 and ARM architectures. >> > >> > According to http://code.google.com/p/lz4/, LZ4 is a very fast >lossless >> > compression algorithm and also features an extremely fast decoder. >> > >> > Kernel Decompression APIs are based on implementation by Yann >Collet >> > (http://code.google.com/p/lz4/source/checkout). >> > De/compression Tools are also provided from the site above. >> > >> > The initial test result on ARM(v7) based board shows that the size >of kernel >> > with LZ4 compressed is 8% bigger than LZO compressed but the >decompressing >> > speed is faster(especially under the enabled unaligned memory >access). >> > >> > Test: 3.4 based kernel built with many modules >> > Uncompressed kernel size: 13MB >> > lzo: 6.3MB, 301ms >> > lz4: 6.8MB, 251ms(167ms, with enabled unaligned memory access) >> > >> > It seems that it___s worth trying LZ4 compressed kernel image or >ramdisk >> > for making the kernel boot more faster. >> > >> > ... >> > >> > 20 files changed, 663 insertions(+), 3 deletions(-) >> > >> > ... >> > >> >> What's this "with enabled unaligned memory access" thing? You mean >"if >> the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so, >> that's only x86, which isn't really in the target market for this >> patch, yes? > >I'm guessing this is referring to commit 5010192d5a. > >> It's a lot of code for a 50ms boot-time improvement. Does anyone >have >> any opinions on whether or not the benefits are worth the cost? > >Well, we used to have only one compressed format. Now we have nearly >half a dozen, with the same worthiness issue between themselves. >Either we keep it very simple, or we make it very flexible. The former > >would argue in favor of removing some of the existing formats, the >later >would let this new format in. > > >Nicolas -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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: Failure due to missing (Exynos related) pinctrl patch
Sachin Kamat wrote: > > Hi Linus, Kukjin, > > Patch titled "pinctrl: exynos: change PINCTRL_EXYNOS option" > (linux-next commit Id: 7452b64d) which is present in linux-next is > missing in the mainline kernel. This patch is required along with the > patch "gpio: samsung: fix pinctrl condition for exynos and exynos5440" > (mainline commit Id: e4a5da51) which has already made it into > mainline. Without the missing patch we get the following boot up > warnings and subsequent failures with dt boot on 4412 based board: > > WARNING: at drivers/gpio/gpio-samsung.c:3102 > samsung_gpiolib_init+0x29c/0x2e8() > Unknown SoC in gpio-samsung, no GPIOs added > Modules linked in: > [] (unwind_backtrace+0x0/0xf8) from [] > (warn_slowpath_common+0x4c/0x64) > [] (warn_slowpath_common+0x4c/0x64) from [] > (warn_slowpath_fmt+0x30/0x40) > [] (warn_slowpath_fmt+0x30/0x40) from [] > (samsung_gpiolib_init+0x29c/0x2e8) > [] (samsung_gpiolib_init+0x29c/0x2e8) from [] > (do_one_initcall+0x34/0x174) > [] (do_one_initcall+0x34/0x174) from [] > (kernel_init_freeable+0xfc/0x1c8) > [] (kernel_init_freeable+0xfc/0x1c8) from [] > (kernel_init+0x8/0xe4) > [] (kernel_init+0x8/0xe4) from [] > (ret_from_fork+0x14/0x3c) > Sachin, thanks for your information. Linus, can you check following again? https://lkml.org/lkml/2013/1/18/461 Thanks. - Kukjin -- 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/
Avoid high order memory allocating with kmalloc, when read large seq file
Subject: [PATCH] [SEQ_FILE] Avoid high order memory allocating with kmalloc
when read large seq file
currently, when dumpstate access /proc/xxx/binder , this binder include
lots of info,
it will use seq_read in kernel, in this function, it will trigger high
order memory alloc,
when read binder info or other large file, this will cause memory
presure when system
don't have contious high order memory, it will lead to high kswap
workload to reclaim the
page. so change kmalloc to vmalloc, it can avoid contiously high order
memory allocating.
[ 4356.532357] dumpstate: page allocation failure: order:4, mode:0x40d0
[ 4356.532400] Pid: 18256, comm: dumpstate Tainted: G C
3.0.34-141128-g4be7088 #1
[ 4356.532416] Call Trace:
[ 4356.532443] [] ? printk+0x1d/0x1f
[ 4356.532467] [] warn_alloc_failed+0xbf/0xf0
[ 4356.532491] [] __alloc_pages_nodemask+0x4ba/0x6a0
[ 4356.532521] [] __get_free_pages+0x1c/0x30
[ 4356.532541] [] kmalloc_order_trace+0x21/0xd0
[ 4356.532561] [] ? seq_read+0x137/0x390
[ 4356.532579] [] __kmalloc+0x20a/0x230
[ 4356.532596] [] ? seq_read+0x137/0x390
[ 4356.532616] [] ? put_page+0x2c/0x40
[ 4356.532634] [] ? kfree+0xcd/0x160
[ 4356.532655] [] ? mutex_unlock+0xd/0x10
[ 4356.532675] [] seq_read+0x149/0x390
[ 4356.532697] [] vfs_read+0x8c/0x160
[ 4356.532716] [] ? seq_lseek+0x180/0x180
[ 4356.532735] [] sys_read+0x3d/0x70
[ 4356.532755] [] syscall_call+0x7/0xb
[ 4356.532777] [] ? log_dir_items+0x33d/0x40c
Signed-off-by: xiaobing tu
Signed-off-by: linX z chen
Signed-off-by: guifang tang
Change-Id: I892c97d02cf25e59b23c9bc68dff754ea01c1d56
---
fs/seq_file.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index dba43c3..20b8e36 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -209,8 +209,17 @@ ssize_t seq_read(struct file *file, char __user
*buf, size_t size, loff_t *ppos)
if (m->count < m->size)
goto Fill;
m->op->stop(m, p);
-kfree(m->buf);
-m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
+if (m->size > 2 * PAGE_SIZE) {
+vfree(m->buf);
+} else
+kfree(m->buf);
+m->size <<= 1;
+if (m->size > 2 * PAGE_SIZE) {
+m->buf = vmalloc(m->size);
+} else
+m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
+
+
if (!m->buf)
goto Enomem;
m->count = 0;
@@ -325,7 +334,10 @@ EXPORT_SYMBOL(seq_lseek);
int seq_release(struct inode *inode, struct file *file)
{
struct seq_file *m = file->private_data;
-kfree(m->buf);
+if (m->size > 2 * PAGE_SIZE) {
+vfree(m->buf);
+} else
+kfree(m->buf);
kfree(m);
return 0;
}
--
1.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] PCI: Document PCIE BUS MPS parameters
On 2013/1/29 13:00, Jon Mason wrote: > On Fri, Jan 25, 2013 at 2:36 AM, Yijing Wang wrote: >> v0->v1: Update MPS parameters as non-arch and add MRRS >> description into pcie_bus_perf parameter suggested >> by Andrew Murray. >> v1->v2: Update some semantic problems and add MPS and MRRS >> explanation suggested by Joe Lawrence and Randy Dunlap. >> v2->v3: Update some semantic problems and the description >> of pcie_bus_safe and pcie_bus_peer2peer suggested >> by Bjorn Helgaas. >> >> Document PCIE BUS MPS parameters pcie_bus_tune_off, pcie_bus_safe, >> pcie_bus_peer2peer, pcie_bus_perf into Documentation/kernel-parameters.txt. >> These parameters were introduced by Jon Mason at >> commit 5f39e6705 and commit b03e7495a8. >> >> Signed-off-by: Yijing Wang >> --- >> Documentation/kernel-parameters.txt | 13 + >> 1 files changed, 13 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/kernel-parameters.txt >> b/Documentation/kernel-parameters.txt >> index 363e348..2997df2 100644 >> --- a/Documentation/kernel-parameters.txt >> +++ b/Documentation/kernel-parameters.txt >> @@ -2227,6 +2227,19 @@ bytes respectively. Such letter suffixes can also be >> entirely omitted. >> This sorting is done to get a device >> order compatible with older (<= 2.4) kernels. >> nobfsortDon't sort PCI devices into breadth-first >> order. >> + pcie_bus_tune_off Disable PCIe MPS (Max Payload Size) >> + tuning and use the BIOS-configured MPS >> defaults. >> + pcie_bus_safe Use the smallest supported MPS of any device >> + below a root complex. > > This isn't correct. It should be something like "The largest MPS > common to all devices below the root complex". Hi Jon, Thanks for your review and comment! What about "Set every device's MPS to the largest MPSS (Max Payload Size Support) common to all devices below the root complex" ? > >> + pcie_bus_perf Configure device MPS to the largest >> + allowable MPS based on its parent bus. Also >> set >> + MRRS (Max Read Request Size) to the largest >> supported >> + value (no larger than the MPS that the >> device or bus >> + can support) for best performance. >> + pcie_bus_peer2peer Set every device's MPS to 128B, which >> + every device is guaranteed to support. This >> + configuration allows peer-to-peer DMA >> between any pair >> + of devices possibly at the cost of reduced >> performance. >> cbiosize=nn[KMG]The fixed amount of bus space which >> is >> reserved for the CardBus bridge's IO window. >> The default value is 256 bytes. >> -- >> 1.7.1 >> >> > > . > -- 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/
Re: [PATCH] slub: assign refcount for kmalloc_caches
On Thu, Jan 24, 2013 at 10:32:32PM -0500, CAI Qian wrote: > > > - Original Message - > > From: "Greg Kroah-Hartman" > > To: "Joonsoo Kim" > > Cc: "Paul Hargrove" , "Pekka Enberg" > > , linux-kernel@vger.kernel.org, > > linux...@kvack.org, "Christoph Lameter" > > Sent: Tuesday, January 15, 2013 3:23:36 AM > > Subject: Re: [PATCH] slub: assign refcount for kmalloc_caches > > > > On Fri, Jan 11, 2013 at 04:52:54PM +0900, Joonsoo Kim wrote: > > > On Thu, Jan 10, 2013 at 08:47:39PM -0800, Paul Hargrove wrote: > > > > I just had a look at patch-3.7.2-rc1, and this change doesn't > > > > appear to > > > > have made it in yet. > > > > Am I missing something? > > > > > > > > -Paul > > > > > > I try to check it. > > > Ccing to Greg. > > > > > > Hello, Pekka and Greg. > > > > > > v3.8-rcX has already fixed by another stuff, but it is not simple > > > change. > > > So I made a new patch and sent it. > > > > > > How this kind of patch (only for stable v3.7) go into stable tree? > > > through Pekka's slab tree? or send it to Greg, directly? > > > > > > I don't know how to submit this kind of patch to stable tree > > > exactly. > > > Could anyone help me? > > > > Please redo it, and send it to sta...@vger.kernel.org, and say > > exactly > > why it isn't in Linus's tree, and that it should only be applied to > > 3.7-stable. > I also met this during the testing, so I'll re-send it then. Hello, CAI Qian. I totally forget this. Thanks for this work. -- 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] sched: move scheduler sysctl bits into dedicated header file
Hi Clark, On Mon, 28 Jan 2013 14:31:20 -0600, Clark Williams wrote: > Move all the scheduler sysctl-related bits out of include/linux/sched.h > into a new file include/linux/sched_sysctl.h. > > Signed-off-by: Clark Williams > --- [snip] > diff --git a/include/linux/sched_sysctl.h b/include/linux/sched_sysctl.h > new file mode 100644 > index 000..912adab > --- /dev/null > +++ b/include/linux/sched_sysctl.h > @@ -0,0 +1,121 @@ > +#ifndef _SCHED_SYSCTL_H > +#define _SCHED_SYSCTL_H > + > + > +/* provide a home for sysctl scheduler tuning knobs */ > + > +/* > + * default timeslice is 100 msecs (used only for SCHED_RR tasks). > + * Timeslices get refilled after they expire. > + */ > +#define RR_TIMESLICE (100 * HZ / 1000) It seems this line came from sched.h but I can't find that part deleted. 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] x86, reboot: skip reboot_fixups in early boot phase
On Thu, Jan 24, 2013 at 08:52:32PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Jan 24, 2013 at 09:21:52PM -0700, Bjorn Helgaas wrote:
> > On Thu, Jan 24, 2013 at 9:14 PM, Greg Kroah-Hartman
> > wrote:
> > > On Thu, Jan 24, 2013 at 07:59:01PM -0700, Bjorn Helgaas wrote:
> > >> [+cc Greg for driver core]
> > >>
> > >> On Fri, Jan 25, 2013 at 10:13:03AM +0900, Joonsoo Kim wrote:
> > >> > Hello, Bjorn.
> > >> >
> > >> > On Thu, Jan 24, 2013 at 10:45:13AM -0700, Bjorn Helgaas wrote:
> > >> > > On Fri, Dec 28, 2012 at 6:50 AM, Joonsoo Kim
> > >> > > wrote:
> > >> > > > During early boot phase, PCI bus subsystem is not yet initialized.
> > >> > > > If panic is occured in early boot phase and panic_timeout is set,
> > >> > > > code flow go into emergency_restart() and hit
> > >> > > > mach_reboot_fixups(), then
> > >> > > > encounter another panic. When second panic, we can't hold a
> > >> > > > panic_lock, so
> > >> > > > code flow go into panic_smp_self_stop() which prevent system to
> > >> > > > restart.
> > >> > > >
> > >> > > > For avoid second panic, skip reboot_fixups in early boot phase.
> > >> > > > It makes panic_timeout works in early boot phase.
> > >> > > >
> > >> > > > Cc: Thomas Gleixner
> > >> > > > Cc: Ingo Molnar
> > >> > > > Cc: "H. Peter Anvin"
> > >> > > > Signed-off-by: Joonsoo Kim
> > >> > > >
> > >> > > > diff --git a/arch/x86/kernel/reboot_fixups_32.c
> > >> > > > b/arch/x86/kernel/reboot_fixups_32.c
> > >> > > > index c8e41e9..b9b8ec9 100644
> > >> > > > --- a/arch/x86/kernel/reboot_fixups_32.c
> > >> > > > +++ b/arch/x86/kernel/reboot_fixups_32.c
> > >> > > > @@ -89,6 +89,10 @@ void mach_reboot_fixups(void)
> > >> > > > if (in_interrupt())
> > >> > > > return;
> > >> > > >
> > >> > > > + /* During early boot phase, PCI is not yet initialized */
> > >> > > > + if (system_state == SYSTEM_BOOTING)
> > >> > > > + return;
> > >> > > > +
> > >> > > > for (i=0; i < ARRAY_SIZE(fixups_table); i++) {
> > >> > > > cur = &(fixups_table[i]);
> > >> > > > dev = pci_get_device(cur->vendor, cur->device,
> > >> > > > NULL);
> > >> > >
> > >> > > I guess you're saying that if we call pci_get_device() too early, it
> > >> > > panics? Did you figure out why that happens?
> > >> > >
> > >> > > If we call pci_get_device() before PCI has been initialized, it would
> > >> > > be good if it just returned NULL, indicating that we didn't find any
> > >> > > matching device. I looked briefly, and I thought that's what would
> > >> > > happen, but apparently I'm missing something.
> > >> >
> > >> > In bus_find_device(), klist_iter_init_node() is called with
> > >> > @bus->p->klist_device. Before initialization, bus->p is NULL,
> > >> > so panic is occured.
> > >>
> > >> I see. pci_bus_type.p is initialized by __bus_register() in this path:
> > >>
> > >> pci_driver_init# postcore_initcall
> > >> bus_register(_bus_type)
> > >> __bus_register
> > >> priv = kzalloc(sizeof(struct subsys_private))
> > >> bus->p = priv
> > >> klist_init(>klist_devices, klist_devices_get,
> > >> klist_devices_put)
> > >>
> > >> I was hoping we could statically initialize the klist, but that doesn't
> > >> seem likely.
> > >>
> > >> But I wonder if we could do something like the following. If we could,
> > >> then callers wouldn't have to worry about whether or not the bus has been
> > >> initialized.
> > >
> > >
> > >
> > > I have no objection to that patch, but really, someone wants to call
> > > pci_find_device() before PCI is initialized? Can't that be fixed
> > > instead, as that is the root problem, not the driver core.
> > >
> > > But, to paper over your subsystem's bugs, I guess I can take it :)
> >
> > The caller is in the native_machine_emergency_restart() path.
> > Joonsoo's original patch does what I think you're suggesting:
> >
> > >> > > > + /* During early boot phase, PCI is not yet initialized */
> > >> > > > + if (system_state == SYSTEM_BOOTING)
> > >> > > > + return;
> > >> > > > +
> > >> > > > for (i=0; i < ARRAY_SIZE(fixups_table); i++) {
> > >> > > > cur = &(fixups_table[i]);
> > >> > > > dev = pci_get_device(cur->vendor, cur->device,
> > >> > > > NULL);
> >
> > I think it's sort of ugly to check system_state before using
> > pci_get_device(), and there's not really an obvious connection between
> > system_state and PCI initialization.
> >
> > But if you prefer that, Joonsoo's original patch is fine with me.
>
> Both probably would be best, as there are probably other things that you
> don't want to touch when you are still booting and trying to restart the
> machine at the same time.
I agree that my patch is ugly :)
So I drop it and wait for your patch.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Re: [patch v4 0/18] sched: simplified fork, release load avg and power awareness scheduling
On 01/28/2013 01:19 PM, Alex Shi wrote: > On 01/27/2013 06:40 PM, Borislav Petkov wrote: >> On Sun, Jan 27, 2013 at 10:41:40AM +0800, Alex Shi wrote: >>> Just rerun some benchmarks: kbuild, specjbb2005, oltp, tbench, aim9, >>> hackbench, fileio-cfq of sysbench, dbench, aiostress, multhreads >>> loopback netperf. on my core2, nhm, wsm, snb, platforms. no clear >>> performance change found. >> >> Ok, good, You could put that in one of the commit messages so that it is >> there and people know that this patchset doesn't cause perf regressions >> with the bunch of benchmarks. >> >>> I also tested balance policy/powersaving policy with above benchmark, >>> found, the specjbb2005 drop much 30~50% on both of policy whenever >>> with openjdk or jrockit. and hackbench drops a lots with powersaving >>> policy on snb 4 sockets platforms. others has no clear change. Sorry, the testing configuration is unfair for this specjbb2005 results here. I set JVM hard pin and use hugepage for peak performance. When remove the hard pin and no hugepage, the balance/powersaving both drop about 5% VS performance policy, and performance policy result is similar with 3.8-rc5. >> >> I guess this is expected because there has to be some performance hit >> when saving power... >> > > BTW, I had tested the v3 version based on sched numa -- on tip/master. > The specjbb just has about 5~7% dropping on balance/powersaving policy. > The power scheduling done after the numa scheduling logical. > -- 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 tip/core/rcu 1/2] rcu: Provide RCU CPU stall warnings for tiny RCU
On Sun, Jan 27, 2013 at 09:57:08PM +1100, Josh Triplett wrote: > On Sat, Jan 26, 2013 at 04:23:46PM -0800, Paul E. McKenney wrote: > > From: "Paul E. McKenney" > > > > Tiny RCU has historically omitted RCU CPU stall warnings in order to > > reduce memory requirements, however, lack of these warnings caused > > Thomas Gleixner some debugging pain recently. Therefore, this commit > > adds RCU CPU stall warnings to tiny RCU if RCU_TRACE=y. This keeps > > the memory footprint small, while still enabling CPU stall warnings > > in kernels built to enable them. > > > > Updated to include Josh Triplett's suggested use of RCU_STALL_COMMON > > config variable to simplify #if expressions. > > > > Reported-by: Thomas Gleixner > > Signed-off-by: Paul E. McKenney > > Signed-off-by: Paul E. McKenney > > One suggestion below; with that change, > Reviewed-by: Josh Triplett > > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -486,6 +486,14 @@ config PREEMPT_RCU > > This option enables preemptible-RCU code that is common between > > the TREE_PREEMPT_RCU and TINY_PREEMPT_RCU implementations. > > > > +config RCU_STALL_COMMON > > + def_bool ( TREE_RCU || TREE_PREEMPT_RCU || RCU_TRACE ) > > + help > > + This option enables RCU CPU stall code that is common between > > + the TINY and TREE variants of RCU. The purpose is to allow > > + the tiny variants to disable RCU CPU stall warnings, while > > + making these warnings mandatory for the tree variants. > > + > [...] > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -970,7 +970,7 @@ config RCU_TORTURE_TEST_RUNNABLE > > > > config RCU_CPU_STALL_TIMEOUT > > int "RCU CPU stall timeout in seconds" > > - depends on TREE_RCU || TREE_PREEMPT_RCU > > + depends on TREE_RCU || TREE_PREEMPT_RCU || RCU_TRACE > > depends on RCU_STALL_COMMON Good catch, fixed! Thanx, Paul -- 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 2/2] usb: phy: samsung: Add PHY support for USB 3.0 controller
CC: Doug Anderson
On Mon, Jan 28, 2013 at 3:56 PM, Vivek Gautam wrote:
> Adding PHY driver support for USB 3.0 controller for Samsung's
> SoCs.
>
> Signed-off-by: Vivek Gautam
> ---
>
> Changes from v3:
> - Making SAMSUNG_USB3PHY dependent on SAMSUNG_USBPHY.
> - Adding USB_DWC3 to dependencies of SAMSUNG_USB2PHY since
>dwc3 controller also looks for USB2 type PHY.
>
> drivers/usb/phy/Kconfig | 11 +-
> drivers/usb/phy/Makefile |1 +
> drivers/usb/phy/samsung-usb3.c | 349
> ++
> drivers/usb/phy/samsung-usbphy.h | 81 +
> 4 files changed, 441 insertions(+), 1 deletions(-)
> create mode 100644 drivers/usb/phy/samsung-usb3.c
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index cc0d230..9325a95 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -52,14 +52,23 @@ config SAMSUNG_USBPHY
> help
> Enable this to support Samsung USB phy controllers for Samsung
> SoCs.
> + Further enable USB 2.0 type PHY or USB 3.0 type PHY as required
> + for USB controllers in use.
>
> if SAMSUNG_USBPHY
>
> config SAMSUNG_USB2PHY
> bool "Samsung USB 2.0 PHY controller Driver"
> - depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS
> + depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS ||
> USB_DWC3
> help
> Enable this to support Samsung USB 2.0 (High Speed) phy controller
> for Samsung SoCs.
>
> +config SAMSUNG_USB3PHY
> + bool "Samsung USB 3.0 PHY controller Driver"
> + depends on USB_DWC3
> + help
> + Enable this to support Samsung USB 3.0 (Super Speed) phy controller
> + for samsung SoCs.
> +
> endif
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index 7ba9862..b8505ac 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
> obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
> obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
> obj-$(CONFIG_SAMSUNG_USB2PHY) += samsung-usb2.o
> +obj-$(CONFIG_SAMSUNG_USB3PHY) += samsung-usb3.o
> diff --git a/drivers/usb/phy/samsung-usb3.c b/drivers/usb/phy/samsung-usb3.c
> new file mode 100644
> index 000..29e1321
> --- /dev/null
> +++ b/drivers/usb/phy/samsung-usb3.c
> @@ -0,0 +1,349 @@
> +/* linux/drivers/usb/phy/samsung-usb3.c
> + *
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Author: Vivek Gautam
> + *
> + * Samsung USB 3.0 PHY transceiver; talks to DWC3 controller.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "samsung-usbphy.h"
> +
> +/*
> + * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock
> core.
> + */
> +static u32 samsung_usb3_phy_set_refclk(struct samsung_usbphy *sphy)
> +{
> + u32 reg;
> + u32 refclk;
> +
> + refclk = sphy->ref_clk_freq;
> +
> + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
> + PHYCLKRST_FSEL(refclk);
> +
> + switch (refclk) {
> + case FSEL_CLKSEL_50M:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case FSEL_CLKSEL_20M:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case FSEL_CLKSEL_19200K:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + case FSEL_CLKSEL_24M:
> + default:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + }
> +
> + return reg;
> +}
> +
> +static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy)
> +{
> + void __iomem *regs = sphy->regs;
> + u32 phyparam0;
> + u32 phyparam1;
> + u32 linksystem;
> + u32 phybatchg;
> + u32 phytest;
> + u32 phyclkrst;
> +
> + /* Reset USB 3.0 PHY */
> + writel(0x0, regs + EXYNOS5_DRD_PHYREG0);
> +
> + phyparam0 = readl(regs + EXYNOS5_DRD_PHYPARAM0);
> + /* Select PHY CLK source */
> + phyparam0 &=
Re: linux-next: manual merge of the tty tree with the input tree
On Tue, Jan 29, 2013 at 04:13:21PM +1100, Josh Triplett wrote:
> On Mon, Jan 28, 2013 at 04:23:57PM -0800, Dmitry Torokhov wrote:
> > On Tue, Jan 29, 2013 at 10:59:17AM +1100, Josh Triplett wrote:
> > > On Mon, Jan 28, 2013 at 02:44:43PM -0800, Dmitry Torokhov wrote:
> > > > On Mon, Jan 28, 2013 at 02:09:31PM -0800, Joe Millenbach wrote:
> > > > > On Mon, Jan 28, 2013 at 9:33 AM, Dmitry Torokhov
> > > > > wrote:
> > > > > > On Mon, Jan 28, 2013 at 06:46:15AM -0800, Greg KH wrote:
> > > > > >> On Mon, Jan 28, 2013 at 08:44:24PM +1100, Stephen Rothwell wrote:
> > > > > >> > Hi Greg,
> > > > > >> >
> > > > > >> > Today's linux-next merge of the tty tree got a conflict in
> > > > > >> > drivers/input/keyboard/Kconfig between commit 6f2ac009f29b
> > > > > >> > ("Input:
> > > > > >> > goldfish - virtual input event driver") from the input tree and
> > > > > >> > commit
> > > > > >> > 4f73bc4dd3e8 ("tty: Added a CONFIG_TTY option to allow removal
> > > > > >> > of TTY")
> > > > > >> > from the tty tree.
> > > > > >> >
> > > > > >> > I fixed it up (see below - I am not sure if GOLDFISH_EVENTS
> > > > > >> > needs TTY or
> > > > > >> > not) and can carry the fix as necessary (no action is required).
> > > > > >> >
> > > > > >> > --
> > > > > >> > Cheers,
> > > > > >> > Stephen Rothwells...@canb.auug.org.au
> > > > > >> >
> > > > > >> > diff --cc drivers/input/keyboard/Kconfig
> > > > > >> > index 078305e,008f96a..000
> > > > > >> > --- a/drivers/input/keyboard/Kconfig
> > > > > >> > +++ b/drivers/input/keyboard/Kconfig
> > > > > >> > @@@ -479,16 -482,8 +482,18 @@@ config KEYBOARD_SAMSUN
> > > > > >> > To compile this driver as a module, choose M here: the
> > > > > >> > module will be called samsung-keypad.
> > > > > >> >
> > > > > >> > + if TTY
> > > > > >> > +
> > > > > >> > +config KEYBOARD_GOLDFISH_EVENTS
> > > > > >> > + depends on GOLDFISH
> > > > > >> > + tristate "Generic Input Event device for Goldfish"
> > > > > >> > + help
> > > > > >> > +Say Y here to get an input event device for the Goldfish
> > > > > >> > virtual
> > > > > >>
> > > > > >> Looks good, thanks.
> > > > > >
> > > > > > Greg,
> > > > > >
> > > > > > Please drop 4f73bc4dd3e8563ef4109f293a092820dff66d92, at least the
> > > > > > parts
> > > > > > related to input. As far as I know nothing except serport driver
> > > > > > depends on tty and we do not need to introduce this kind of
> > > > > > dependencie. Anyone needing slim config can simply try disabling
> > > > > > input (or parts of it) without needing an artificial dependencies.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > --
> > > > > > Dmitry
> > > > >
> > > > > Dmitry and Greg,
> > > > >
> > > > > SERIO needs TTY,
> > > >
> > > > No it does not. There is only one (1) serio driver that needs the tty
> > > > layer and that is serport.
> > > >
> > > > > and the majority of the input changes are adding "depends on TTY" to
> > > > > things that "select SERIO" as they break the dependency chain. In
> > > > > other words, enabling a component that selects SERIO will turn SERIO
> > > > > on even when SERIO depends on TTY and TTY is disabled.
> > > >
> > > > Except that it does not. Are you confusing SERIO with SERIAL by any
> > > > chance?
> > >
> > > A few serial drivers don't actually need the TTY layer. However, most
> >
> > Can you please tell me why you are talking about serial layer here?
>
> Probably terminology sloppiness. Insert noun for "things that depend on
> SERIO" here.
Still does not make sense as SERIO subsystem does not depend on TTY, a
single driver belonging to it does.
> > > do, including many that don't obviously appear to at first glance. For
> > > instance, MOUSE_PS2 doesn't *appear* to need TTY, but without the
> > > dependency, having MOUSE_PS2 enabled and TTY disabled produces a kernel
> > > that doesn't build.
> >
> > Compile log please.
>
> http://marc.info/?l=linux-kernel=134555498507747=1
>
> IIRC, produced by dropping the "depends on TTY" from MOUSE_PS2, enabling
> MOUSE_PS2, leaving TTY disabled, and changing nothing else. (In
> particular, not changing anything related to serport directly.)
Right, because serport (one single diriver outr of all of them) does
depend on TTY.
>
> > > (Also keep in mind that many other headers include
> > > .) Many of the drivers that don't actually need TTY
> > > nonetheless won't typically appear on systems small enough to want to
> > > compile out TTY.
> > >
> > > In any case, it seems simple enough to whittle down dependencies on TTY
> > > later on, but for a first pass, the conserative approach seems
> > > preferable.
> >
> > However my approach would be not to touch anything except serport
> > driver (which indeed depends on TTY layer).
>
> Quite a bit more than that depends on the TTY layer.
No, if you look at the log you mention above the only build failure is
coming from serport driver, exactly as I said. There is exactly
[PATCH 0/2] DaVinci: da850: Add NOR flash DT node support
Add NOR flash DT node support for DA850 EVM and related pin mux. Configure 16 bit data bus width for CS2(aemif) to use the norflash on DA850. This series is based on top of 3.8-rc4 and the following patches. -drivers/pinctrl: grab default handles from device core https://patchwork.kernel.org/patch/1862231/ -ARM: davinci: da850: add pinctrl driver DT entries Tested on DA850 EVM. Kumar, Anil (2): ARM: davinci: da850 evm: add norflash DT node ARM: davinci: da850: configure CS2(aemif) for norflash arch/arm/boot/dts/da850-evm.dts | 25 +++ arch/arm/boot/dts/da850.dtsi | 41 ++ arch/arm/mach-davinci/da8xx-dt.c | 17 +++ 3 files changed, 83 insertions(+), 0 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: davinci: da850 evm: add norflash DT node
Add norflash DT node on DA850 EVM and related pin mux.
Signed-off-by: Kumar, Anil
---
:100644 100644 087ba28... 95ffeca... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 160ebac... 036b02a... M arch/arm/boot/dts/da850.dtsi
arch/arm/boot/dts/da850-evm.dts | 25 +++
arch/arm/boot/dts/da850.dtsi| 41 +++
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 087ba28..95ffeca 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -28,4 +28,29 @@
status = "okay";
};
};
+ norflash_cs2@6000 {
+ compatible = "intel,PC28F640P30T85", "cfi-flash";
+ reg = <0x6000 0x1FF>;
+ bank-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ linux,mtd-name = "physmap-flash";
+ pinctrl-names = "default";
+ pinctrl-0 = <_cs2_pins>;
+
+ bootloaders_env@0 {
+ label = "bootloaders_env";
+ reg = <0 0x8>;
+ };
+
+ kernel@8 {
+ label = "kernel";
+ reg = <0x8 0x20>;
+ };
+
+ filesystem@28 {
+ label = "filesystem";
+ reg = <0x28 0x58>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 160ebac..036b02a 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -38,6 +38,47 @@
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x>;
status = "disabled";
+
+ norflash_cs2_pins: pinmux_norflash_pins{
+ pinctrl-single,bits = <
+ /* EMA_BA[1] */
+ 0x14 0x0100 0x0f00
+ /* EMA_CLK, EMA_WAIT[1] */
+ 0x18 0x0101 0x0f0f
+ /* EMA_OE, EMA_WE, EMA_CS[2] */
+ 0x1c 0x00110001 0x00ff000f
+ /*
+* EMA_D[0], EMA_D[1], EMA_D[2],
+* EMA_D[3], EMA_D[4], EMA_D[5],
+* EMA_D[6], EMA_D[7]
+*/
+ 0x24 0x 0x
+ /*
+* EMA_D[8], EMA_D[9], EMA_D[10],
+* EMA_D[11], EMA_D[12], EMA_D[13],
+* EMA_D[14], EMA_D[15]
+*/
+ 0x20 0x 0x
+ /*
+* EMA_A[0], EMA_A[1], EMA_A[2],
+* EMA_A[3], EMA_A[4], EMA_A[5],
+* EMA_A[6], EMA_A[7]
+*/
+ 0x30 0x 0x
+ /*
+* EMA_A[8], EMA_A[9], EMA_A[10],
+* EMA_A[11], EMA_A[12], EMA_A[13],
+* EMA_A[14], EMA_A[15]
+*/
+ 0x2c 0x 0x
+ /*
+* EMA_A[16], EMA_A[17], EMA_A[18],
+* EMA_A[19], EMA_A[20], EMA_A[21],
+* EMA_A[22]
+*/
+ 0x28 0x1110 0xfff0
+ >;
+ };
};
serial0: serial@1c42000 {
compatible = "ns16550a";
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: davinci: da850: configure CS2(aemif) for norflash
Configure 16 bit data bus width for CS2(aemif) to use the norflash on
DA850.
Signed-off-by: Kumar, Anil
---
:100644 100644 37c27af... 540e284... M arch/arm/mach-davinci/da8xx-dt.c
arch/arm/mach-davinci/da8xx-dt.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..540e284 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -38,12 +38,29 @@ static void __init da8xx_init_irq(void)
}
#ifdef CONFIG_ARCH_DAVINCI_DA850
+#define DA8XX_AEMIF_CE2CFG_OFFSET 0x10
+#define DA8XX_AEMIF_ASIZE_16BIT 0x1
+
+static void __init da8xx_init_nor(void)
+{
+ void __iomem *aemif_addr;
+
+ aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K);
+
+ /* Configure data bus width of CS2 to 16 bit */
+ writel(readl(aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET) |
+ DA8XX_AEMIF_ASIZE_16BIT,
+ aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET);
+
+ iounmap(aemif_addr);
+}
static void __init da850_init_machine(void)
{
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
da8xx_uart_clk_enable();
+ da8xx_init_nor();
}
static const char *da850_boards_compat[] __initdata = {
--
1.7.4.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] dw_dmac: adjust slave_id accordingly to request line base
On Tue, Jan 29, 2013 at 10:29:43AM +0530, Viresh Kumar wrote:
> Next time, please direct these mails to my Linaro id :)
>
> On Mon, Jan 28, 2013 at 4:34 PM, Andy Shevchenko
> wrote:
> > On some hardware configurations we have got the request line with the
> > offset.
> > The patch introduces convert_slave_id() helper for that cases. The request
> > line
> > base is got from the platform device resources provided by the
> > IORESOURCE_DMA
> > type.
>
> @Vinod: Is IORESOURCE_DMA suitable for this purpose?
We had a discusssion about this with Andy as well. The thing is that there
is no way in current resource to pass DMA request line numbers supported by
the controller to the driver in a generic way. We on the other hand have to
deal this somehow as we have a shared DMA controller on Lynxpoint where the
offset will start from 16 (but it might be something else as well).
Is there something which limits the usage of IORESOUCE_DMA to be only
usable for ISA DMA channels?
We have made supporting code that currently sits in linux-pm/linux-next
tree that parses an ACPI CSRT table and creates the platform devices with
suitable resources here: 13176bbf183c8 (ACPI: add support for CSRT table).
> > Signed-off-by: Mika Westerberg
> > Signed-off-by: Andy Shevchenko
> > ---
> > drivers/dma/dw_dmac.c | 13 +
> > drivers/dma/dw_dmac_regs.h |1 +
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> > index 3155c11..8484ca1 100644
> > --- a/drivers/dma/dw_dmac.c
> > +++ b/drivers/dma/dw_dmac.c
> > @@ -995,6 +995,13 @@ static inline void convert_burst(u32 *maxburst)
> > *maxburst = 0;
> > }
> >
> > +static inline void convert_slave_id(struct dw_dma_chan *dwc)
> > +{
> > + struct dw_dma *dw = to_dw_dma(dwc->chan.device);
> > +
> > + dwc->dma_sconfig.slave_id -= dw->request_line_base;
> > +}
> > +
> > static int
> > set_runtime_config(struct dma_chan *chan, struct dma_slave_config *sconfig)
> > {
> > @@ -1009,6 +1016,7 @@ set_runtime_config(struct dma_chan *chan, struct
> > dma_slave_config *sconfig)
> >
> > convert_burst(>dma_sconfig.src_maxburst);
> > convert_burst(>dma_sconfig.dst_maxburst);
> > + convert_slave_id(dwc);
> >
> > return 0;
> > }
> > @@ -1717,6 +1725,11 @@ static int dw_probe(struct platform_device *pdev)
> > memcpy(dw->data_width, pdata->data_width, 4);
> > }
> >
> > + /* Get the base request line if set */
> > + io = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> > + if (io)
> > + dw->request_line_base = (unsigned int)io->start;
> > +
>
> How will it work in case of DT?
Can't the DT version do the same thing and pass IORESOURCE_DMA to the
driver? Or we can check dev->of_node and parse it directly from DT instead
of resource.
--
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-next: manual merge of the tty tree with the input tree
On Mon, Jan 28, 2013 at 04:23:57PM -0800, Dmitry Torokhov wrote:
> On Tue, Jan 29, 2013 at 10:59:17AM +1100, Josh Triplett wrote:
> > On Mon, Jan 28, 2013 at 02:44:43PM -0800, Dmitry Torokhov wrote:
> > > On Mon, Jan 28, 2013 at 02:09:31PM -0800, Joe Millenbach wrote:
> > > > On Mon, Jan 28, 2013 at 9:33 AM, Dmitry Torokhov
> > > > wrote:
> > > > > On Mon, Jan 28, 2013 at 06:46:15AM -0800, Greg KH wrote:
> > > > >> On Mon, Jan 28, 2013 at 08:44:24PM +1100, Stephen Rothwell wrote:
> > > > >> > Hi Greg,
> > > > >> >
> > > > >> > Today's linux-next merge of the tty tree got a conflict in
> > > > >> > drivers/input/keyboard/Kconfig between commit 6f2ac009f29b ("Input:
> > > > >> > goldfish - virtual input event driver") from the input tree and
> > > > >> > commit
> > > > >> > 4f73bc4dd3e8 ("tty: Added a CONFIG_TTY option to allow removal of
> > > > >> > TTY")
> > > > >> > from the tty tree.
> > > > >> >
> > > > >> > I fixed it up (see below - I am not sure if GOLDFISH_EVENTS needs
> > > > >> > TTY or
> > > > >> > not) and can carry the fix as necessary (no action is required).
> > > > >> >
> > > > >> > --
> > > > >> > Cheers,
> > > > >> > Stephen Rothwells...@canb.auug.org.au
> > > > >> >
> > > > >> > diff --cc drivers/input/keyboard/Kconfig
> > > > >> > index 078305e,008f96a..000
> > > > >> > --- a/drivers/input/keyboard/Kconfig
> > > > >> > +++ b/drivers/input/keyboard/Kconfig
> > > > >> > @@@ -479,16 -482,8 +482,18 @@@ config KEYBOARD_SAMSUN
> > > > >> > To compile this driver as a module, choose M here: the
> > > > >> > module will be called samsung-keypad.
> > > > >> >
> > > > >> > + if TTY
> > > > >> > +
> > > > >> > +config KEYBOARD_GOLDFISH_EVENTS
> > > > >> > + depends on GOLDFISH
> > > > >> > + tristate "Generic Input Event device for Goldfish"
> > > > >> > + help
> > > > >> > +Say Y here to get an input event device for the Goldfish
> > > > >> > virtual
> > > > >>
> > > > >> Looks good, thanks.
> > > > >
> > > > > Greg,
> > > > >
> > > > > Please drop 4f73bc4dd3e8563ef4109f293a092820dff66d92, at least the
> > > > > parts
> > > > > related to input. As far as I know nothing except serport driver
> > > > > depends on tty and we do not need to introduce this kind of
> > > > > dependencie. Anyone needing slim config can simply try disabling
> > > > > input (or parts of it) without needing an artificial dependencies.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > --
> > > > > Dmitry
> > > >
> > > > Dmitry and Greg,
> > > >
> > > > SERIO needs TTY,
> > >
> > > No it does not. There is only one (1) serio driver that needs the tty
> > > layer and that is serport.
> > >
> > > > and the majority of the input changes are adding "depends on TTY" to
> > > > things that "select SERIO" as they break the dependency chain. In
> > > > other words, enabling a component that selects SERIO will turn SERIO
> > > > on even when SERIO depends on TTY and TTY is disabled.
> > >
> > > Except that it does not. Are you confusing SERIO with SERIAL by any
> > > chance?
> >
> > A few serial drivers don't actually need the TTY layer. However, most
>
> Can you please tell me why you are talking about serial layer here?
Probably terminology sloppiness. Insert noun for "things that depend on
SERIO" here.
> > do, including many that don't obviously appear to at first glance. For
> > instance, MOUSE_PS2 doesn't *appear* to need TTY, but without the
> > dependency, having MOUSE_PS2 enabled and TTY disabled produces a kernel
> > that doesn't build.
>
> Compile log please.
http://marc.info/?l=linux-kernel=134555498507747=1
IIRC, produced by dropping the "depends on TTY" from MOUSE_PS2, enabling
MOUSE_PS2, leaving TTY disabled, and changing nothing else. (In
particular, not changing anything related to serport directly.)
> > (Also keep in mind that many other headers include
> > .) Many of the drivers that don't actually need TTY
> > nonetheless won't typically appear on systems small enough to want to
> > compile out TTY.
> >
> > In any case, it seems simple enough to whittle down dependencies on TTY
> > later on, but for a first pass, the conserative approach seems
> > preferable.
>
> However my approach would be not to touch anything except serport
> driver (which indeed depends on TTY layer).
Quite a bit more than that depends on the TTY layer.
> > > In the future it would be nice if you CCed people involved in the
> > > subsystem you are changing.
> >
> > Such as the maintainers of the TTY and serial layers? Alan Cox OKed
> > this conservative addition of dependencies in the original version of
> > this change, and Greg had no complaints at the time.
>
> Maintainer of _SERIO_ (not SERIAL, SERIO) layer, yours truly.
This change affected the dependencies of several hundred drivers, and
the output of get_maintainer.pl included hundreds of email addresses.
Spamming *all* of them for a one-line change to the dependencies of a
Kconfig option, when that
Failure due to missing (Exynos related) pinctrl patch
Hi Linus, Kukjin, Patch titled "pinctrl: exynos: change PINCTRL_EXYNOS option" (linux-next commit Id: 7452b64d) which is present in linux-next is missing in the mainline kernel. This patch is required along with the patch "gpio: samsung: fix pinctrl condition for exynos and exynos5440" (mainline commit Id: e4a5da51) which has already made it into mainline. Without the missing patch we get the following boot up warnings and subsequent failures with dt boot on 4412 based board: WARNING: at drivers/gpio/gpio-samsung.c:3102 samsung_gpiolib_init+0x29c/0x2e8() Unknown SoC in gpio-samsung, no GPIOs added Modules linked in: [] (unwind_backtrace+0x0/0xf8) from [] (warn_slowpath_common+0x4c/0x64) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x30/0x40) [] (warn_slowpath_fmt+0x30/0x40) from [] (samsung_gpiolib_init+0x29c/0x2e8) [] (samsung_gpiolib_init+0x29c/0x2e8) from [] (do_one_initcall+0x34/0x174) [] (do_one_initcall+0x34/0x174) from [] (kernel_init_freeable+0xfc/0x1c8) [] (kernel_init_freeable+0xfc/0x1c8) from [] (kernel_init+0x8/0xe4) [] (kernel_init+0x8/0xe4) from [] (ret_from_fork+0x14/0x3c) -- With warm regards, Sachin -- 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] dw_dmac: adjust slave_id accordingly to request line base
Next time, please direct these mails to my Linaro id :)
On Mon, Jan 28, 2013 at 4:34 PM, Andy Shevchenko
wrote:
> On some hardware configurations we have got the request line with the offset.
> The patch introduces convert_slave_id() helper for that cases. The request
> line
> base is got from the platform device resources provided by the IORESOURCE_DMA
> type.
@Vinod: Is IORESOURCE_DMA suitable for this purpose?
> Signed-off-by: Mika Westerberg
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c | 13 +
> drivers/dma/dw_dmac_regs.h |1 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 3155c11..8484ca1 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -995,6 +995,13 @@ static inline void convert_burst(u32 *maxburst)
> *maxburst = 0;
> }
>
> +static inline void convert_slave_id(struct dw_dma_chan *dwc)
> +{
> + struct dw_dma *dw = to_dw_dma(dwc->chan.device);
> +
> + dwc->dma_sconfig.slave_id -= dw->request_line_base;
> +}
> +
> static int
> set_runtime_config(struct dma_chan *chan, struct dma_slave_config *sconfig)
> {
> @@ -1009,6 +1016,7 @@ set_runtime_config(struct dma_chan *chan, struct
> dma_slave_config *sconfig)
>
> convert_burst(>dma_sconfig.src_maxburst);
> convert_burst(>dma_sconfig.dst_maxburst);
> + convert_slave_id(dwc);
>
> return 0;
> }
> @@ -1717,6 +1725,11 @@ static int dw_probe(struct platform_device *pdev)
> memcpy(dw->data_width, pdata->data_width, 4);
> }
>
> + /* Get the base request line if set */
> + io = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> + if (io)
> + dw->request_line_base = (unsigned int)io->start;
> +
How will it work in case of DT?
> /* Calculate all channel mask before DMA setup */
> dw->all_chan_mask = (1 << nr_channels) - 1;
>
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index 88dd8eb..3eeb766 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -248,6 +248,7 @@ struct dw_dma {
> /* hardware configuration */
> unsigned char nr_masters;
> unsigned char data_width[4];
> + unsigned intrequest_line_base;
>
> struct dw_dma_chan chan[0];
> };
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 7/8] fat (exportfs): rebuild directory-inode if fat_dget() fails
2013/1/28, OGAWA Hirofumi : > Namjae Jeon writes: > Although checking several routines to check hang case you said, I didn't find anything. And There is no any race on test result also. Am I missing something ? Let me know your opinion. >>> >>> Hm, it's read-only. So, there may not be race for now, I'm sure there is >>> race on write path though. >> Yes, right. We checked/tested on read-only. >> Maybe have you found race with rename and unlink ? >> If yes, I think we can fix this issue with lock like this. >> >> + mutex_lock(_SB(sb)->s_lock); >> parent_inode = fat_rebuild_parent(sb, >> parent_logstart); >> + mutex_unlock(_SB(sb)->s_lock); > > It is any changes to directory. ->s_lock is not preferred. We need only > per-directory lock (i.e. dir->i_mutex). > > To do this, we need more bigger changes though. E.g. register temporary > inode to central list. Then, find it when building real inode. If found > temporary, grab it, and make update it as real inode. > > Yes, this is a bit complex. But we would need something like this for > write support. First Thanks for review and help. We will try to fix it as your suggestion now for the Write path. There is one suggestion. As per discussion before, your suggestion was that, we will merge read-only support for FAT exportfs first. And the current patch set has no issues for read-only. So If you accept, Can I try to re-send current patch-set (read-only) first? And we will then additionally start to fix issues related with write path step by step. Let me know your opinion. Thanks OGAWA! > > Thanks. > -- > OGAWA Hirofumi > -- 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 00/16] Transparent huge page cache
On Mon, 28 Jan 2013, Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > Here's first steps towards huge pages in page cache. > > The intend of the work is get code ready to enable transparent huge page > cache for the most simple fs -- ramfs. > > It's not yet near feature-complete. It only provides basic infrastructure. > At the moment we can read, write and truncate file on ramfs with huge pages in > page cache. The most interesting part, mmap(), is not yet there. For now > we split huge page on mmap() attempt. > > I can't say that I see whole picture. I'm not sure if I understand locking > model around split_huge_page(). Probably, not. > Andrea, could you check if it looks correct? > > Next steps (not necessary in this order): > - mmap(); > - migration (?); > - collapse; > - stats, knobs, etc.; > - tmpfs/shmem enabling; > - ... > > Kirill A. Shutemov (16): > block: implement add_bdi_stat() > mm: implement zero_huge_user_segment and friends > mm: drop actor argument of do_generic_file_read() > radix-tree: implement preload for multiple contiguous elements > thp, mm: basic defines for transparent huge page cache > thp, mm: rewrite add_to_page_cache_locked() to support huge pages > thp, mm: rewrite delete_from_page_cache() to support huge pages > thp, mm: locking tail page is a bug > thp, mm: handle tail pages in page_cache_get_speculative() > thp, mm: implement grab_cache_huge_page_write_begin() > thp, mm: naive support of thp in generic read/write routines > thp, libfs: initial support of thp in > simple_read/write_begin/write_end > thp: handle file pages in split_huge_page() > thp, mm: truncate support for transparent huge page cache > thp, mm: split huge page on mmap file page > ramfs: enable transparent huge page cache > > fs/libfs.c | 54 +--- > fs/ramfs/inode.c|6 +- > include/linux/backing-dev.h | 10 +++ > include/linux/huge_mm.h |8 ++ > include/linux/mm.h | 15 > include/linux/pagemap.h | 14 ++- > include/linux/radix-tree.h |3 + > lib/radix-tree.c| 32 +-- > mm/filemap.c| 204 > +++ > mm/huge_memory.c| 62 +++-- > mm/memory.c | 22 + > mm/truncate.c | 12 +++ > 12 files changed, 375 insertions(+), 67 deletions(-) Interesting. I was starting to think about Transparent Huge Pagecache a few months ago, but then got washed away by incoming waves as usual. Certainly I don't have a line of code to show for it; but my first impression of your patches is that we have very different ideas of where to start. Perhaps that's good complementarity, or perhaps I'll disagree with your approach. I'll be taking a look at yours in the coming days, and trying to summon back up my own ideas to summarize them for you. Perhaps I was naive to imagine it, but I did intend to start out generically, independent of filesystem; but content to narrow down on tmpfs alone where it gets hard to support the others (writeback springs to mind). khugepaged would be migrating little pages into huge pages, where it saw that the mmaps of the file would benefit (and for testing I would hack mmap alignment choice to favour it). I had arrived at a conviction that the first thing to change was the way that tail pages of a THP are refcounted, that it had been a mistake to use the compound page method of holding the THP together. But I'll have to enter a trance now to recall the arguments ;) Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] PCI: Document PCIE BUS MPS parameters
On Fri, Jan 25, 2013 at 2:36 AM, Yijing Wang wrote: > v0->v1: Update MPS parameters as non-arch and add MRRS > description into pcie_bus_perf parameter suggested > by Andrew Murray. > v1->v2: Update some semantic problems and add MPS and MRRS > explanation suggested by Joe Lawrence and Randy Dunlap. > v2->v3: Update some semantic problems and the description > of pcie_bus_safe and pcie_bus_peer2peer suggested > by Bjorn Helgaas. > > Document PCIE BUS MPS parameters pcie_bus_tune_off, pcie_bus_safe, > pcie_bus_peer2peer, pcie_bus_perf into Documentation/kernel-parameters.txt. > These parameters were introduced by Jon Mason at > commit 5f39e6705 and commit b03e7495a8. > > Signed-off-by: Yijing Wang > --- > Documentation/kernel-parameters.txt | 13 + > 1 files changed, 13 insertions(+), 0 deletions(-) > > diff --git a/Documentation/kernel-parameters.txt > b/Documentation/kernel-parameters.txt > index 363e348..2997df2 100644 > --- a/Documentation/kernel-parameters.txt > +++ b/Documentation/kernel-parameters.txt > @@ -2227,6 +2227,19 @@ bytes respectively. Such letter suffixes can also be > entirely omitted. > This sorting is done to get a device > order compatible with older (<= 2.4) kernels. > nobfsortDon't sort PCI devices into breadth-first > order. > + pcie_bus_tune_off Disable PCIe MPS (Max Payload Size) > + tuning and use the BIOS-configured MPS > defaults. > + pcie_bus_safe Use the smallest supported MPS of any device > + below a root complex. This isn't correct. It should be something like "The largest MPS common to all devices below the root complex". > + pcie_bus_perf Configure device MPS to the largest > + allowable MPS based on its parent bus. Also > set > + MRRS (Max Read Request Size) to the largest > supported > + value (no larger than the MPS that the device > or bus > + can support) for best performance. > + pcie_bus_peer2peer Set every device's MPS to 128B, which > + every device is guaranteed to support. This > + configuration allows peer-to-peer DMA between > any pair > + of devices possibly at the cost of reduced > performance. > cbiosize=nn[KMG]The fixed amount of bus space which is > reserved for the CardBus bridge's IO window. > The default value is 256 bytes. > -- > 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 1/2] cpufreq: Set policy->related_cpus to atleast policy->cpus
On 29 January 2013 10:09, Viresh Kumar wrote: > With the addition of following patch, related_cpus is required to be set by > cpufreq platform drivers: > > commit c1070fd743533efb54e98142252283583f379190 > Author: Viresh Kumar > Date: Mon Jan 14 13:23:04 2013 + > > cpufreq: Simplify cpufreq_add_dev() > > Because this change is required by all platform drivers, why not do this in > the > core itself. Hence, this patch is an attempt towards fixing all broken > drivers. > > From now on, platforms don't really need to set related_cpus from their init() > routines, as the same work is done by core too. > > If platform driver needs to set the related_cpus mask with some additional > cpus, > other than cpus present in policy->cpus, they are free to do it as we aren't > overriding anything. > > Signed-off-by: Viresh Kumar > --- > Inderpal, > > Can you please add your tested-by for this patch? And this will require you to > drop your patch for exynos-cpufreq.c :) ARM mail servers are broken. Patches attached. 0001-cpufreq-Set-policy-related_cpus-to-atleast-policy-cp.patch Description: Binary data 0002-Revert-cpufreq-Don-t-use-cpu-removed-during-cpufreq_.patch Description: Binary data
Re: [PATCH 0/2] Secure Boot: More controversial changes
On Mon, Jan 28, 2013 at 06:05:56PM -0800, H. Peter Anvin wrote: > These at the very least need some kind of CONFIG_WEAK_SECURE_BOOT > option or something like that. Given Eric's views on the kexec patch (and given that there's no point in the hibernate one if kexec's available...), I'm not planning on pushing these until there's a plausible story for limiting kexec to signed images. -- Matthew Garrett | mj...@srcf.ucam.org -- 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 2/2] Revert "cpufreq: Don't use cpu removed during cpufreq_driver_unregister"
This reverts commit 956f33948b95aa91f6cbc6860087671c6ac1de4b. With the addition of following patch, this change/variable is not required: commit b9ba2725343ae57add3f324dfa5074167f48de96 Author: Viresh Kumar Date: Mon Jan 14 13:23:03 2013 + cpufreq: Simplify __cpufreq_remove_dev() Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index db81382..8d521422 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -47,9 +47,6 @@ static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor); #endif static DEFINE_SPINLOCK(cpufreq_driver_lock); -/* Used when we unregister cpufreq driver */ -static struct cpumask cpufreq_online_mask; - /* * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure * all cpufreq/hotplug/workqueue/etc related lock issues. @@ -951,7 +948,6 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) * managing offline cpus here. */ cpumask_and(policy->cpus, policy->cpus, cpu_online_mask); - cpumask_and(policy->cpus, policy->cpus, _online_mask); policy->user_policy.min = policy->min; policy->user_policy.max = policy->max; @@ -1133,7 +1129,6 @@ static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif) if (unlikely(lock_policy_rwsem_write(cpu))) BUG(); - cpumask_clear_cpu(cpu, _online_mask); retval = __cpufreq_remove_dev(dev, sif); return retval; } @@ -1875,8 +1870,6 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data) cpufreq_driver = driver_data; spin_unlock_irqrestore(_driver_lock, flags); - cpumask_setall(_online_mask); - ret = subsys_interface_register(_interface); if (ret) goto err_null_driver; -- 1.7.12.rc2.18.g61b472e -- 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/2] cpufreq: Set policy->related_cpus to atleast policy->cpus
With the addition of following patch, related_cpus is required to be set by
cpufreq platform drivers:
commit c1070fd743533efb54e98142252283583f379190
Author: Viresh Kumar
Date: Mon Jan 14 13:23:04 2013 +
cpufreq: Simplify cpufreq_add_dev()
Because this change is required by all platform drivers, why not do this in the
core itself. Hence, this patch is an attempt towards fixing all broken drivers.
>From now on, platforms don't really need to set related_cpus from their init()
routines, as the same work is done by core too.
If platform driver needs to set the related_cpus mask with some additional cpus,
other than cpus present in policy->cpus, they are free to do it as we aren't
overriding anything.
Signed-off-by: Viresh Kumar
---
Inderpal,
Can you please add your tested-by for this patch? And this will require you to
drop your patch for exynos-cpufreq.c :)
drivers/cpufreq/cpufreq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index f5dc02b..db81382 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -554,8 +554,6 @@ static ssize_t show_cpus(const struct cpumask *mask, char
*buf)
*/
static ssize_t show_related_cpus(struct cpufreq_policy *policy, char *buf)
{
- if (cpumask_empty(policy->related_cpus))
- return show_cpus(policy->cpus, buf);
return show_cpus(policy->related_cpus, buf);
}
@@ -945,6 +943,9 @@ static int cpufreq_add_dev(struct device *dev, struct
subsys_interface *sif)
goto err_unlock_policy;
}
+ /* related cpus should atleast have policy->cpus */
+ cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
+
/*
* affected cpus must always be the one, which are online. We aren't
* managing offline cpus here.
--
1.7.12.rc2.18.g61b472e
--
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] mm: Rename page struct field helpers
On Thu, 24 Jan 2013, Mel Gorman wrote:
> The function names page_xchg_last_nid(), page_last_nid() and
> reset_page_last_nid() were judged to be inconsistent so rename them
> to a struct_field_op style pattern. As it looked jarring to have
> reset_page_mapcount() and page_nid_reset_last() beside each other in
> memmap_init_zone(), this patch also renames reset_page_mapcount() to
> page_mapcount_reset(). There are others like init_page_count() but as it
> is used throughout the arch code a rename would likely cause more conflicts
> than it is worth.
>
> Suggested-by: Andrew Morton
> Signed-off-by: Mel Gorman
Sorry for not piping up in that earlier thread, but I don't understand
Andrew's reasoning on this: it looks to me like unhelpful churn rather
than improvement (and I suspect your heart is not in it either, Mel).
It's true that sometimes we name things object_verb() and sometimes we
name things verb_object(), but we're always going to be inconsistent on
that, and this patch does not change the fact: page_mapcount_reset()
but set_page_private() (named by one akpm, I believe)?
Being English, I really prefer verb_object(); but there are often
subsystems or cfiles where object_verb() narrows the namespace more
nicely.
xchg_page_last_nid() instead of page_xchg_last_nid(), to match
reset_page_last_nid(): I think that would be a fine change.
page_nid_xchg_last() to exchange page->_last_nid? You jest, sir!
Hugh
> ---
> drivers/staging/ramster/zbud.c |2 +-
> drivers/staging/zsmalloc/zsmalloc-main.c |2 +-
> include/linux/mm.h | 20 ++--
> mm/huge_memory.c |2 +-
> mm/mempolicy.c |2 +-
> mm/migrate.c |4 ++--
> mm/mmzone.c |4 ++--
> mm/page_alloc.c | 10 +-
> mm/slob.c|2 +-
> mm/slub.c|2 +-
> 10 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/staging/ramster/zbud.c b/drivers/staging/ramster/zbud.c
> index a7c4361..cc2deff 100644
> --- a/drivers/staging/ramster/zbud.c
> +++ b/drivers/staging/ramster/zbud.c
> @@ -401,7 +401,7 @@ static inline struct page *zbud_unuse_zbudpage(struct
> zbudpage *zbudpage,
> else
> zbud_pers_pageframes--;
> zbudpage_spin_unlock(zbudpage);
> - reset_page_mapcount(page);
> + page_mapcount_reset(page);
> init_page_count(page);
> page->index = 0;
> return page;
> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
> b/drivers/staging/zsmalloc/zsmalloc-main.c
> index 09a9d35..c7785f2 100644
> --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> @@ -475,7 +475,7 @@ static void reset_page(struct page *page)
> set_page_private(page, 0);
> page->mapping = NULL;
> page->freelist = NULL;
> - reset_page_mapcount(page);
> + page_mapcount_reset(page);
> }
>
> static void free_zspage(struct page *first_page)
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 6e4468f..0aa0944 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -366,7 +366,7 @@ static inline struct page *compound_head(struct page
> *page)
> * both from it and to it can be tracked, using atomic_inc_and_test
> * and atomic_add_negative(-1).
> */
> -static inline void reset_page_mapcount(struct page *page)
> +static inline void page_mapcount_reset(struct page *page)
> {
> atomic_set(&(page)->_mapcount, -1);
> }
> @@ -657,28 +657,28 @@ static inline int page_to_nid(const struct page *page)
>
> #ifdef CONFIG_NUMA_BALANCING
> #ifdef LAST_NID_NOT_IN_PAGE_FLAGS
> -static inline int page_xchg_last_nid(struct page *page, int nid)
> +static inline int page_nid_xchg_last(struct page *page, int nid)
> {
> return xchg(>_last_nid, nid);
> }
>
> -static inline int page_last_nid(struct page *page)
> +static inline int page_nid_last(struct page *page)
> {
> return page->_last_nid;
> }
> -static inline void reset_page_last_nid(struct page *page)
> +static inline void page_nid_reset_last(struct page *page)
> {
> page->_last_nid = -1;
> }
> #else
> -static inline int page_last_nid(struct page *page)
> +static inline int page_nid_last(struct page *page)
> {
> return (page->flags >> LAST_NID_PGSHIFT) & LAST_NID_MASK;
> }
>
> -extern int page_xchg_last_nid(struct page *page, int nid);
> +extern int page_nid_xchg_last(struct page *page, int nid);
>
> -static inline void reset_page_last_nid(struct page *page)
> +static inline void page_nid_reset_last(struct page *page)
> {
> int nid = (1 << LAST_NID_SHIFT) - 1;
>
> @@ -687,17 +687,17 @@ static inline void reset_page_last_nid(struct page
> *page)
> }
> #endif /* LAST_NID_NOT_IN_PAGE_FLAGS */
> #else
> -static inline int page_xchg_last_nid(struct page *page, int
Re: [RFC PATCH v5 4/8] ACPI, PCI: avoid building pci_slot as module
On Tue, Jan 29, 2013 at 10:07:22AM +0800, Jiang Liu wrote: > Could we use quirk to auto-disable PCIe native hotplug for > problematic platforms? Do these problematic platforms successfully boot Windows 7? -- Matthew Garrett | mj...@srcf.ucam.org -- 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 v5 4/8] ACPI, PCI: avoid building pci_slot as module
On Mon, Jan 28, 2013 at 03:14:11PM -0700, Bjorn Helgaas wrote: > CONFIG_ACPI_PCI_SLOT=y in RHEL6, so evidently they have this problem. I'm not aware of anyone ever filing any bugs against it, either, though Myron would have a better idea. What's the worst case outcome of someone ending up with an incorrect slot number? -- Matthew Garrett | mj...@srcf.ucam.org -- 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/4] PCI/ACPI: Add target state as parameter to pci_platform_pm_ops->run_wake
Normally, if PCI device uses native PME interrupt for runtime wake up,
platform need not to do anything for runtime wake up.
But per PCI Express Base Specification Revision 2.0 section 5.3.3.2
Link Wakeup, platform support is needed for D3cold waking up to power
on the main link even if there is native PME interrupt support for
D3cold.
So the needed work for platform runtime wake up is different among
different target state. Originally, pci_dev->runtime_d3cold flag is
used for that, but we want to restrict its usage. Now the target
state is added as parameter to pci_platform_pm_ops->run_wake to solve
the issue.
Signed-off-by: Huang Ying
---
drivers/pci/pci-acpi.c |5 +++--
drivers/pci/pci.c |9 +
drivers/pci/pci.h |2 +-
3 files changed, 9 insertions(+), 7 deletions(-)
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -261,7 +261,8 @@ static void acpi_pci_propagate_run_wake(
acpi_pm_device_run_wake(bus->bridge, enable);
}
-static int acpi_pci_run_wake(struct pci_dev *dev, bool enable)
+static int acpi_pci_run_wake(struct pci_dev *dev, bool enable,
+pci_power_t state)
{
/*
* Per PCI Express Base Specification Revision 2.0 section
@@ -269,7 +270,7 @@ static int acpi_pci_run_wake(struct pci_
* waking up to power on the main link even if there is PME
* support for D3cold
*/
- if (dev->pme_interrupt && !dev->runtime_d3cold)
+ if (dev->pme_interrupt && state != PCI_D3cold)
return 0;
if (!acpi_pm_device_run_wake(>dev, enable))
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -484,10 +484,11 @@ static inline int platform_pci_sleep_wak
pci_platform_pm->sleep_wake(dev, enable) : -ENODEV;
}
-static inline int platform_pci_run_wake(struct pci_dev *dev, bool enable)
+static inline int platform_pci_run_wake(struct pci_dev *dev, bool enable,
+ pci_power_t state)
{
return pci_platform_pm ?
- pci_platform_pm->run_wake(dev, enable) : -ENODEV;
+ pci_platform_pm->run_wake(dev, enable, state) : -ENODEV;
}
/**
@@ -1687,7 +1688,7 @@ int __pci_enable_wake(struct pci_dev *de
pci_pme_active(dev, true);
else
ret = 1;
- error = runtime ? platform_pci_run_wake(dev, true) :
+ error = runtime ? platform_pci_run_wake(dev, true, state) :
platform_pci_sleep_wake(dev, true);
if (ret)
ret = error;
@@ -1695,7 +1696,7 @@ int __pci_enable_wake(struct pci_dev *de
dev->wakeup_prepared = true;
} else {
if (runtime)
- platform_pci_run_wake(dev, false);
+ platform_pci_run_wake(dev, false, state);
else
platform_pci_sleep_wake(dev, false);
pci_pme_active(dev, false);
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -61,7 +61,7 @@ struct pci_platform_pm_ops {
pci_power_t (*choose_state)(struct pci_dev *dev);
bool (*can_wakeup)(struct pci_dev *dev);
int (*sleep_wake)(struct pci_dev *dev, bool enable);
- int (*run_wake)(struct pci_dev *dev, bool enable);
+ int (*run_wake)(struct pci_dev *dev, bool enable, pci_power_t state);
};
extern int pci_set_platform_pm(struct pci_platform_pm_ops *ops);
--
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 3/4] PCI/PM: Set pci_dev->set_d3cold in pci_set_power_state
Because now pci_dev->set_d3cold is only used after
pci_set_power_state(, PCI_D3cold) and before pci_set_power_state(,
PCI_D0). And we will use pci_dev->set_d3cold for D3cold support
during system suspend too, but now pci_dev->set_d3cold is set only in
runtime power management code path now.
Signed-off-by: Huang Ying
---
drivers/pci/pci-driver.c |2 --
drivers/pci/pci.c| 12 +++-
2 files changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1036,8 +1036,6 @@ static int pci_pm_runtime_resume(struct
rc = pm->runtime_resume(dev);
- pci_dev->set_d3cold = false;
-
return rc;
}
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -775,6 +775,9 @@ int pci_set_power_state(struct pci_dev *
if (dev->current_state == state)
return 0;
+ if (state == PCI_D3cold)
+ dev->set_d3cold = true;
+
__pci_start_power_transition(dev, state);
/* This device is quirked not to be put into D3, so
@@ -798,6 +801,9 @@ int pci_set_power_state(struct pci_dev *
if (!error && dev->bus->self)
pcie_aspm_powersave_config_link(dev->bus->self);
+ if (error || state != PCI_D3cold)
+ dev->set_d3cold = false;
+
return error;
}
@@ -1833,16 +1839,12 @@ int pci_finish_runtime_suspend(struct pc
if (target_state == PCI_POWER_ERROR)
return -EIO;
- dev->set_d3cold = target_state == PCI_D3cold;
-
__pci_enable_wake(dev, target_state, true, pci_dev_run_wake(dev));
error = pci_set_power_state(dev, target_state);
- if (error) {
+ if (error)
__pci_enable_wake(dev, target_state, true, false);
- dev->set_d3cold = false;
- }
return error;
}
--
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: Tux3 Report: Initial fsck has landed
On Mon, Jan 28, 2013 at 5:40 PM, Theodore Ts'o wrote: > On Mon, Jan 28, 2013 at 04:20:11PM -0800, Darrick J. Wong wrote: >> On Mon, Jan 28, 2013 at 03:27:38PM -0800, David Lang wrote: >> > The situation I'm thinking of is when dealing with VMs, you make a >> > filesystem image once and clone it multiple times. Won't that end up >> > with the same UUID in the superblock? >> >> Yes, but one ought to be able to change the UUID a la tune2fs -U. Even >> still... so long as the VM images have a different UUID than the fs that they >> live on, it ought to be fine. > > ... and this is something most system administrators should be > familiar with. For example, it's one of those things that Norton > Ghost when makes file system image copes (the equivalent of "tune2fs > -U random /dev/XXX") Hmm, maybe I missed something but it does not seem like a good idea to use the volume UID itself to generate unique-per-volume metadata hashes, if users expect to be able to change it. All the metadata hashes would need to be changed. Anyway, our primary line of attack on this problem is not unique hashes, but actually knowing which blocks are in files and which are not. Before (a hypothetical) Tux3 fsck repair would be so bold as to reattach some lost metadata to the place it thinks it belongs, all of the following would need to be satisfied: * The lost metadata subtree is completely detached from the filesystem tree. In other words, it cannot possibly be the contents of some valid file already belonging to the filesystem. I believe this addresses the concern of David Lang at the head of this thread. * The filesystem tree is incomplete. Somwhere in it Tux3 fsck has discovered a hole that needs to be filled. * The lost metadata subree is complete and consistent, except for not being attached to the filesystem tree. * The lost metadata subtree that was found matches a hole where metadata is missing, according to its "uptags", which specify at least the low order bits of the inode the metadata belongs to and the offset at which it belongs. * Tux3 fsck asked the user if this lost metadata (describing it in some reasonable way) should be attached to some particular filesystem object that appears to be incomplete. Alternatively, the lost subtree may be attached to the traditional "lost+found" directory, though we are able to be somewhat more specific about where the subtree might originally have belonged, and can name the lost+found object accordingly. Additionally, Tux3 fsck might consider the following: * If the allocation bitmaps appear to be undamaged, but some or all of a lost filesystem tree is marked as free space, then the subtree is most likely free space and no attempt should be made to attach it to anything. Thanks for your comments. I look forward to further review as things progress. One thing to consider: this all gets much more interesting when versioning arrives. For shared tree snapshotting filesystem designs, this must get very interesting indeed, to the point where even contemplating the corner makes me shudder. But even with versioning, Tux3 still upholds the single-reference rule, therefore our fsck problem will continue to look a lot more like Ext4 than like Btrfs or ZFS. Which suggests some great opportunities for unabashed imitation. Regards, Daniel -- 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 2/4] PCI: Rename pci_dev->runtime_d3cold to pci_dev->set_d3cold
Will use this flag for system suspend in addition to runtime suspend.
Signed-off-by: Huang Ying
---
drivers/pci/pci-driver.c |2 +-
drivers/pci/pci.c|6 +++---
include/linux/pci.h |7 +++
3 files changed, 7 insertions(+), 8 deletions(-)
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1036,7 +1036,7 @@ static int pci_pm_runtime_resume(struct
rc = pm->runtime_resume(dev);
- pci_dev->runtime_d3cold = false;
+ pci_dev->set_d3cold = false;
return rc;
}
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -681,7 +681,7 @@ static void __pci_start_power_transition
* devices powered on/off by corresponding bridge,
* because have already delayed for the bridge.
*/
- if (dev->runtime_d3cold) {
+ if (dev->set_d3cold) {
msleep(dev->d3cold_delay);
/*
* When powering on a bridge from D3cold, the
@@ -1833,7 +1833,7 @@ int pci_finish_runtime_suspend(struct pc
if (target_state == PCI_POWER_ERROR)
return -EIO;
- dev->runtime_d3cold = target_state == PCI_D3cold;
+ dev->set_d3cold = target_state == PCI_D3cold;
__pci_enable_wake(dev, target_state, true, pci_dev_run_wake(dev));
@@ -1841,7 +1841,7 @@ int pci_finish_runtime_suspend(struct pc
if (error) {
__pci_enable_wake(dev, target_state, true, false);
- dev->runtime_d3cold = false;
+ dev->set_d3cold = false;
}
return error;
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -263,10 +263,9 @@ struct pci_dev {
unsigned intmmio_always_on:1; /* disallow turning off io/mem
decoding during bar sizing */
unsigned intwakeup_prepared:1;
- unsigned intruntime_d3cold:1; /* whether go through runtime
- D3cold, not set for devices
- powered on/off by the
- corresponding bridge */
+ unsigned intset_d3cold:1; /* whether go through runtime D3cold,
+ not set for devices powered on/off
+ by the corresponding bridge */
unsigned intd3_delay; /* D3->D0 transition time in ms */
unsigned intd3cold_delay; /* D3cold->D0 transition time in ms */
--
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 4/4] PCI/PM: Enable D3cold support for system suspend
Device may need to be put in D3cold on some platforms, especially
because we treat ACPI_STATE_D3 as ACPI_STATE_D3_COLD now.
Signed-off-by: Huang Ying
---
drivers/pci/pci-driver.c |5 +
drivers/pci/pci.c|4
2 files changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -579,6 +579,7 @@ static bool pci_has_legacy_pm_support(st
static int pci_pm_prepare(struct device *dev)
{
struct device_driver *drv = dev->driver;
+ struct pci_dev *pci_dev = to_pci_dev(dev);
int error = 0;
/*
@@ -592,6 +593,10 @@ static int pci_pm_prepare(struct device
*/
pm_runtime_resume(dev);
+ if (!pci_dev->d3cold_allowed)
+ pci_dev->no_d3cold = true;
+ else
+ pci_dev->no_d3cold = false;
if (drv && drv->pm && drv->pm->prepare)
error = drv->pm->prepare(dev);
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1798,10 +1798,6 @@ int pci_prepare_to_sleep(struct pci_dev
if (target_state == PCI_POWER_ERROR)
return -EIO;
- /* D3cold during system suspend/hibernate is not supported */
- if (target_state > PCI_D3hot)
- target_state = PCI_D3hot;
-
pci_enable_wake(dev, target_state, device_may_wakeup(>dev));
error = pci_set_power_state(dev, target_state);
--
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 0/4] PCI/PM: D3cold support for system suspend
[PATCH 1/4] PCI/ACPI: Add target state as parameter to pci_platform_pm_ops->run_wake [PATCH 2/4] PCI: Rename pci_dev->runtime_d3cold to pci_dev->set_d3cold [PATCH 3/4] PCI/PM: Set pci_dev->set_d3cold in pci_set_power_state [PATCH 4/4] PCI/PM: Enable D3cold support for system suspend Huang Ying Best Regards, -- 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/2] regmap: Add asynchronous I/O support
Some use cases like firmware download can transfer a lot of data in quick
succession. With high speed buses these use cases can benefit from having
multiple transfers scheduled at once since this allows the bus to minimise
the delay between transfers.
Support this by adding regmap_raw_write_async(), allowing raw transfers to
be scheduled, and regmap_async_complete() to wait for them to finish.
Signed-off-by: Mark Brown
---
drivers/base/regmap/internal.h | 15
drivers/base/regmap/regmap.c | 182 +---
include/linux/regmap.h | 28 +++
3 files changed, 215 insertions(+), 10 deletions(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 51f0574..2025186 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
struct regmap;
struct regcache_ops;
@@ -39,6 +40,13 @@ struct regmap_format {
unsigned int (*parse_val)(void *buf);
};
+struct regmap_async {
+ struct list_head list;
+ struct work_struct cleanup;
+ struct regmap *map;
+ void *work_buf;
+};
+
struct regmap {
struct mutex mutex;
spinlock_t spinlock;
@@ -53,6 +61,11 @@ struct regmap {
void *bus_context;
const char *name;
+ spinlock_t async_lock;
+ wait_queue_head_t async_waitq;
+ struct list_head async_list;
+ int async_ret;
+
#ifdef CONFIG_DEBUG_FS
struct dentry *debugfs;
const char *debugfs_name;
@@ -178,6 +191,8 @@ bool regcache_set_val(void *base, unsigned int idx,
unsigned int val, unsigned int word_size);
int regcache_lookup_reg(struct regmap *map, unsigned int reg);
+void regmap_async_complete_cb(struct regmap_async *async, int ret);
+
extern struct regcache_ops regcache_rbtree_ops;
extern struct regcache_ops regcache_lzo_ops;
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 6845a07..e57b7bc 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -41,6 +41,15 @@ static int _regmap_bus_formatted_write(void *context,
unsigned int reg,
static int _regmap_bus_raw_write(void *context, unsigned int reg,
unsigned int val);
+static void async_cleanup(struct work_struct *work)
+{
+ struct regmap_async *async = container_of(work, struct regmap_async,
+ cleanup);
+
+ kfree(async->work_buf);
+ kfree(async);
+}
+
bool regmap_reg_in_ranges(unsigned int reg,
const struct regmap_range *ranges,
unsigned int nranges)
@@ -430,6 +439,10 @@ struct regmap *regmap_init(struct device *dev,
map->cache_type = config->cache_type;
map->name = config->name;
+ spin_lock_init(>async_lock);
+ INIT_LIST_HEAD(>async_list);
+ init_waitqueue_head(>async_waitq);
+
if (config->read_flag_mask || config->write_flag_mask) {
map->read_flag_mask = config->read_flag_mask;
map->write_flag_mask = config->write_flag_mask;
@@ -884,10 +897,13 @@ static int _regmap_select_page(struct regmap *map,
unsigned int *reg,
}
static int _regmap_raw_write(struct regmap *map, unsigned int reg,
-const void *val, size_t val_len)
+const void *val, size_t val_len, bool async)
{
struct regmap_range_node *range;
+ unsigned long flags;
u8 *u8 = map->work_buf;
+ void *work_val = map->work_buf + map->format.reg_bytes +
+ map->format.pad_bytes;
void *buf;
int ret = -ENOTSUPP;
size_t len;
@@ -932,7 +948,7 @@ static int _regmap_raw_write(struct regmap *map, unsigned
int reg,
dev_dbg(map->dev, "Writing window %d/%zu\n",
win_residue, val_len / map->format.val_bytes);
ret = _regmap_raw_write(map, reg, val, win_residue *
- map->format.val_bytes);
+ map->format.val_bytes, async);
if (ret != 0)
return ret;
@@ -955,6 +971,50 @@ static int _regmap_raw_write(struct regmap *map, unsigned
int reg,
u8[0] |= map->write_flag_mask;
+ if (async && map->bus->async_write) {
+ struct regmap_async *async = map->bus->async_alloc();
+ if (!async)
+ return -ENOMEM;
+
+ async->work_buf = kzalloc(map->format.buf_size,
+ GFP_KERNEL | GFP_DMA);
+ if (!async->work_buf) {
+ kfree(async);
+ return -ENOMEM;
+ }
+
+ INIT_WORK(>cleanup, async_cleanup);
+ async->map = map;
+
+
[PATCH 2/2] regmap: spi: Support asynchronous I/O for SPI
Signed-off-by: Mark Brown
---
drivers/base/regmap/regmap-spi.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/drivers/base/regmap/regmap-spi.c b/drivers/base/regmap/regmap-spi.c
index ffa46a9..913274b 100644
--- a/drivers/base/regmap/regmap-spi.c
+++ b/drivers/base/regmap/regmap-spi.c
@@ -15,6 +15,21 @@
#include
#include
+#include "internal.h"
+
+struct regmap_async_spi {
+ struct regmap_async core;
+ struct spi_message m;
+ struct spi_transfer t[2];
+};
+
+static void regmap_spi_complete(void *data)
+{
+ struct regmap_async_spi *async = data;
+
+ regmap_async_complete_cb(>core, async->m.status);
+}
+
static int regmap_spi_write(void *context, const void *data, size_t count)
{
struct device *dev = context;
@@ -40,6 +55,41 @@ static int regmap_spi_gather_write(void *context,
return spi_sync(spi, );
}
+static int regmap_spi_async_write(void *context,
+ const void *reg, size_t reg_len,
+ const void *val, size_t val_len,
+ struct regmap_async *a)
+{
+ struct regmap_async_spi *async = container_of(a,
+ struct regmap_async_spi,
+ core);
+ struct device *dev = context;
+ struct spi_device *spi = to_spi_device(dev);
+
+ async->t[0].tx_buf = reg;
+ async->t[0].len = reg_len;
+ async->t[1].tx_buf = val;
+ async->t[1].len = val_len;
+
+ spi_message_init(>m);
+ spi_message_add_tail(>t[0], >m);
+ spi_message_add_tail(>t[1], >m);
+
+ async->m.complete = regmap_spi_complete;
+ async->m.context = async;
+
+ return spi_async(spi, >m);
+}
+
+static struct regmap_async *regmap_spi_async_alloc(void)
+{
+ struct regmap_async_spi *async_spi;
+
+ async_spi = kzalloc(sizeof(*async_spi), GFP_KERNEL);
+
+ return _spi->core;
+}
+
static int regmap_spi_read(void *context,
const void *reg, size_t reg_size,
void *val, size_t val_size)
@@ -53,6 +103,8 @@ static int regmap_spi_read(void *context,
static struct regmap_bus regmap_spi = {
.write = regmap_spi_write,
.gather_write = regmap_spi_gather_write,
+ .async_write = regmap_spi_async_write,
+ .async_alloc = regmap_spi_async_alloc,
.read = regmap_spi_read,
.read_flag_mask = 0x80,
};
--
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: [RFC PATCH 0/4] Add support for LZ4-compressed kernels
On Mon, 28 Jan 2013, Andrew Morton wrote: > On Sat, 26 Jan 2013 14:50:43 +0900 > Kyungsik Lee wrote: > > > This patchset is for supporting LZ4 compressed kernel and initial ramdisk on > > the x86 and ARM architectures. > > > > According to http://code.google.com/p/lz4/, LZ4 is a very fast lossless > > compression algorithm and also features an extremely fast decoder. > > > > Kernel Decompression APIs are based on implementation by Yann Collet > > (http://code.google.com/p/lz4/source/checkout). > > De/compression Tools are also provided from the site above. > > > > The initial test result on ARM(v7) based board shows that the size of kernel > > with LZ4 compressed is 8% bigger than LZO compressed but the decompressing > > speed is faster(especially under the enabled unaligned memory access). > > > > Test: 3.4 based kernel built with many modules > > Uncompressed kernel size: 13MB > > lzo: 6.3MB, 301ms > > lz4: 6.8MB, 251ms(167ms, with enabled unaligned memory access) > > > > It seems that it___s worth trying LZ4 compressed kernel image or ramdisk > > for making the kernel boot more faster. > > > > ... > > > > 20 files changed, 663 insertions(+), 3 deletions(-) > > > > ... > > > > What's this "with enabled unaligned memory access" thing? You mean "if > the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so, > that's only x86, which isn't really in the target market for this > patch, yes? I'm guessing this is referring to commit 5010192d5a. > It's a lot of code for a 50ms boot-time improvement. Does anyone have > any opinions on whether or not the benefits are worth the cost? Well, we used to have only one compressed format. Now we have nearly half a dozen, with the same worthiness issue between themselves. Either we keep it very simple, or we make it very flexible. The former would argue in favor of removing some of the existing formats, the later would let this new format in. Nicolas -- 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/
perf 3.8-rc build failure: undefined reference to `strlcpy'
[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1
prefix=%{_prefix} all
...
/tmp/ccJEJv6m.o: In function `main':
:(.text+0x14): undefined reference to `strlcpy'
collect2: ld returned 1 exit status
...
This did not show up in 3.7
--
Thomas
--
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: bzImage 2.12
On Mon, Jan 28, 2013 at 7:50 PM, Yinghai Lu wrote: > On Sun, Jan 27, 2013 at 7:36 PM, H. Peter Anvin wrote: > Did you get chance to put them into for-x86-boot? > > You need to skip the first two about memmap= exactmap and reserveram ... > put updated version in git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot for-x86-boot-v7u4 and it is based on Linus tree + tip:x86/mm, tip:x86/mm2, tip:x86/urgent, tip:x86/boot Yinghai -- 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 11/74] perf python: Fix breakage introduced by the test_attr infrastructure
Arnaldo Carvalho de Melo skrev 24.1.2013 22:07:
From: Arnaldo Carvalho de Melo
The test_attr infrastructure hooks on the sys_perf_event_open call,
checking if a variable is set and if so calling a function to intercept
calls and do the checking.
But both the variable and the function aren't on objects that are
linked on the python binding, breaking it:
Atleast this one is 3.8 material as it is a regression since 3.7
[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1
prefix=%{_prefix} all
python_ext_build/tmp/util/evsel.o: In function `sys_perf_event_open':
/mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:183:
undefined reference to `test_attr__enabled'
/mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:184:
undefined reference to `test_attr__open'
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
--
Thomas
# perf test -v 15
15: Try 'use perf' in python, checking link problems :
--- start ---
Traceback (most recent call last):
File "", line 1, in
ImportError: /home/acme/git/build/perf//python/perf.so: undefined symbol:
test_attr__enabled
end
Try 'use perf' in python, checking link problems: FAILED!
#
Fix it by moving the variable to one of the linked object files and
providing a stub for the function in the python.o object, that is only
linked in the python binding.
Now 'perf test' is happy again:
# perf test 15
15: Try 'use perf' in python, checking link problems : Ok
#
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-0rsca2kn44b38rgdpr3tz...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/attr.c | 2 --
tools/perf/util/python.c | 9 +
tools/perf/util/util.c | 2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c
index 25638a9..05b5acb 100644
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -33,8 +33,6 @@
extern int verbose;
-bool test_attr__enabled;
-
static char *dir;
void test_attr__init(void)
diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index a2657fd..925e0c3 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -1045,3 +1045,12 @@ error:
if (PyErr_Occurred())
PyErr_SetString(PyExc_ImportError, "perf: Init failed!");
}
+
+/*
+ * Dummy, to avoid dragging all the test_attr infrastructure in the python
+ * binding.
+ */
+void test_attr__open(struct perf_event_attr *attr, pid_t pid, int cpu,
+ int fd, int group_fd, unsigned long flags)
+{
+}
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 5906e84..252b889 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -12,6 +12,8 @@
*/
unsigned int page_size;
+bool test_attr__enabled;
+
bool perf_host = true;
bool perf_guest = false;
--
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 v4 linux-next] et131x: Promote staging et131x driver to drivers/net
From: Mark Einon
Date: Wed, 23 Jan 2013 16:24:38 +
> +endif # NET_VENDOR_AGERE
> +
Trailing empty line, delete it.
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for the Agere ET-131x ethernet driver
> +#
> +
> +obj-$(CONFIG_ET131X) += et131x.o
> +
Likewise, get rid of this trailing empty line.
> + /* Spinlocks */
> + spinlock_t lock;
> +
> + spinlock_t tcb_send_qlock;
> + spinlock_t tcb_ready_qlock;
> + spinlock_t send_hw_lock;
> +
> + spinlock_t rcv_lock;
> + spinlock_t rcv_pend_lock;
> + spinlock_t fbr_lock;
> +
> + spinlock_t phy_lock;
Do you really need _8_ spinlocks in an ethernet driver? To me that's
way over the top and excessive.
The most recent driver I've written, for the 10Gbit Sun NIU parts,
has only one spinlock.
> + /* Determine if this is a multicast packet coming in */
What in the world are you doing in this huge code block?
Such much complexity, multicast list iteration, etc. just to get some
statistics correct? This stuff is going to run on every multicast
packet receive.
No other driver does crap like this, get rid of this stuff.
> + skb->dev = adapter->netdev;
> + skb->protocol = eth_type_trans(skb, adapter->netdev);
eth_type_trans() sets skb->dev, you don't need to duplicate that.
> + netif_rx_ni(skb);
Why isn't this driver supporting NAPI? If you're going to put this
much time into a driver, use the best interfaces for event processing
rather than something that might have been appropriate in a new driver
two decades ago.
> +static int et131x_tx(struct sk_buff *skb, struct net_device *netdev)
> +{
> + int status = 0;
> + struct et131x_adapter *adapter = netdev_priv(netdev);
> +
> + /* stop the queue if it's getting full */
> + if (adapter->tx_ring.used >= NUM_TCB - 1 &&
> + !netif_queue_stopped(netdev))
> + netif_stop_queue(netdev);
> +
> + /* Save the timestamp for the TX timeout watchdog */
> + netdev->trans_start = jiffies;
> +
> + /* Call the device-specific data Tx routine */
> + status = et131x_send_packets(skb, netdev);
> +
> + /* Check status and manage the netif queue if necessary */
> + if (status != 0) {
> + if (status == -ENOMEM)
> + status = NETDEV_TX_BUSY;
> + else
> + status = NETDEV_TX_OK;
> + }
> + return status;
> +}
Returning NETDEV_TX_BUSY is an error, no driver should ever return
that status under normal circumstances. Some drivers return it
when internal consistency checks fail, but that indicates a driver
bug rather than a normal condition.
Memory allocation erorrs do not denote NETDEV_TX_BUSY, simply drop
the packet silently with kfree_skb() and return NETDEV_TX_OK.
That's about enough for me, this driver still needs a lot of work
and is far from being ready to move out of staging.
--
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 0/18] sched: simplified fork, release load avg and power awareness scheduling
On Tue, 2013-01-29 at 09:45 +0800, Alex Shi wrote: > On 01/28/2013 11:47 PM, Mike Galbraith wrote: > > monteverdi:/abuild/mike/:[0]# echo 1 > /sys/devices/system/cpu/cpufreq/boost > > monteverdi:/abuild/mike/:[0]# massive_intr 10 60 > > 014635 00058160 > > 014633 00058592 > > 014638 00058592 > > 014636 00058160 > > 014632 00058200 > > 014634 00058704 > > 014639 00058704 > > 014641 00058200 > > 014640 00058560 > > 014637 00058560 > > monteverdi:/abuild/mike/:[0]# massive_intr 10 60 > > 014673 00059504 > > 014676 00059504 > > 014674 00059064 > > 014672 00059064 > > 014675 00058560 > > 014671 00058560 > > 014677 00059248 > > 014668 00058864 > > 014669 00059248 > > 014670 00058864 > > monteverdi:/abuild/mike/:[0]# massive_intr 10 60 > > 014686 00043472 > > 014689 00043472 > > 014685 00043760 > > 014690 00043760 > > 014687 00043528 > > 014688 00043528 (hmm) > > 014683 00043216 > > 014692 00043208 > > 014684 00043336 > > 014691 00043336 > > I am sorry Mike. does above 3 times testing has a same sched policy? and > same question for the following testing. Yeah, they're back to back repeats. Using dirt simple massive_intr didn't help clarify aim7 oddity. aim7 is fully repeatable, seems to be saying that consolidation of small independent jobs is a win, that spreading before fully saturated has its price, just as consolidation of large coordinated burst has its price. Seems to cut both ways.. but why not, everything else does. -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 2/2] regmap: spi: Support asynchronous I/O for SPI
On Tue, Jan 29, 2013 at 09:54:11AM +0800, Mark Brown wrote: > It would break anyway, like I say the interface relies on it currently. > The other option is to do a callback into the bus code and return the > contained structure but it seemed more involved and this is fairly > idiomatic. Actually I'll just do that, we have to provide the size to the core anyway. Thanks. signature.asc Description: Digital signature
[PATCH] ia64/mm: fix a bad_page bug when crash kernel booting
On ia64 platform, I set "crashkernel=1024M-:600M", and dmesg shows 128M-728M memory is reserved for crash kernel. Then "echo c > /proc/sysrq-trigger" to test kdump. When crash kernel booting, efi_init() will aligns the memory address in IA64_GRANULE_SIZE(16M), so 720M-728M memory will be dropped, It means crash kernel only manage 128M-720M memory. But initrd start and end are fixed in boot loader, it is before efi_init(), so initrd size maybe overflow when free_initrd_mem(). Here is the dmesg when crash kernel booting: ... Ignoring memory below 128MB Ignoring memory above 720MB // aligns the address in IA64_GRANULE_SIZE(16M) ... Initial ramdisk at: 0xe0002c3f (20176579 bytes) // initrd uses 707M-726M memory ... Kernel command line: root=/dev/disk/by-id/ata-STEC_MACH16_M16ISD2-100UCT_STM000142A2D-part3 console=ttyS0,115200n8 console=tty0 initcall_debug elevator=deadline sysrq=1 reset_devices irqpoll maxcpus=1 initcall_debug linuxrc=trace elfcorehdr=745216K max_addr=728M min_addr=128M // show crash kernel parameters ... Unpacking initramfs... // called by populate_rootfs() Freeing initrd memory: 19648kB freed // called by free_initrd()->free_initrd_mem() BUG: Bad page state in process swapper pfn:02d00 // it is a mistake to free over 720M memory to OS (ia64's page size is 64KB) page:e000102dd800 flags:(null) count:0 mapcount:1 mapping:(null) index:0 Call Trace: [] show_stack+0x80/0xa0 sp=e00021e8fbd0 bsp=e00021e81360 [] dump_stack+0x30/0x50 sp=e00021e8fda0 bsp=e00021e81348 [] bad_page+0x280/0x380 sp=e00021e8fda0 bsp=e00021e81308 [] free_hot_cold_page+0x3a0/0x5c0 sp=e00021e8fda0 bsp=e00021e812a0 [] free_hot_page+0x30/0x60 sp=e00021e8fda0 bsp=e00021e81280 [] __free_pages+0xb0/0xe0 sp=e00021e8fda0 bsp=e00021e81258 [] free_pages+0xa0/0xc0 sp=e00021e8fda0 bsp=e00021e81230 [] free_initrd_mem+0x230/0x290 sp=e00021e8fda0 bsp=e00021e811d8 [] populate_rootfs+0x1c0/0x280 sp=e00021e8fdb0 bsp=e00021e811a0 [] do_one_initcall+0x3b0/0x3e0 sp=e00021e8fdb0 bsp=e00021e81158 [] kernel_init+0x3f0/0x4b0 sp=e00021e8fdb0 bsp=e00021e81108 [] kernel_thread_helper+0xd0/0x100 sp=e00021e8fe30 bsp=e00021e810e0 [] start_kernel_thread+0x20/0x40 sp=e00021e8fe30 bsp=e00021e810e0 Disabling lock debugging due to kernel taint BUG: Bad page state in process swapper pfn:02d01 page:e000102dd838 flags:(null) count:0 mapcount:1 mapping:(null) index:0 Call Trace: [] show_stack+0x80/0xa0 sp=e00021e8fbd0 bsp=e00021e81360 [] dump_stack+0x30/0x50 sp=e00021e8fda0 bsp=e00021e81348 [] bad_page+0x280/0x380 sp=e00021e8fda0 bsp=e00021e81308 [] free_hot_cold_page+0x3a0/0x5c0 sp=e00021e8fda0 bsp=e00021e812a0 [] free_hot_page+0x30/0x60 sp=e00021e8fda0 bsp=e00021e81280 [] __free_pages+0xb0/0xe0 sp=e00021e8fda0 bsp=e00021e81258 [] free_pages+0xa0/0xc0 sp=e00021e8fda0 bsp=e00021e81230 [] free_initrd_mem+0x230/0x290 sp=e00021e8fda0 bsp=e00021e811d8 [] populate_rootfs+0x1c0/0x280 sp=e00021e8fdb0 bsp=e00021e811a0 [] do_one_initcall+0x3b0/0x3e0 sp=e00021e8fdb0 bsp=e00021e81158 [] kernel_init+0x3f0/0x4b0 sp=e00021e8fdb0 bsp=e00021e81108 [] kernel_thread_helper+0xd0/0x100 sp=e00021e8fe30 bsp=e00021e810e0 [] start_kernel_thread+0x20/0x40 sp=e00021e8fe30 bsp=e00021e810e0 ... Signed-off-by: Xishi Qiu --- arch/ia64/include/asm/meminit.h |2 ++ arch/ia64/kernel/efi.c |2 +- arch/ia64/mm/init.c | 11 +++ 3 files changed, 14 insertions(+), 1 deletions(-) diff --git a/arch/ia64/include/asm/meminit.h b/arch/ia64/include/asm/meminit.h index 61c7b17..925ecb5 100644 --- a/arch/ia64/include/asm/meminit.h +++ b/arch/ia64/include/asm/meminit.h @@ -49,6 +49,8 @@ extern int reserve_elfcorehdr(u64 *start, u64 *end); #define GRANULEROUNDDOWN(n)((n) & ~(IA64_GRANULE_SIZE-1)) #define GRANULEROUNDUP(n) (((n)+IA64_GRANULE_SIZE-1) & ~(IA64_GRANULE_SIZE-1)) +extern u64 max_addr; + #ifdef CONFIG_NUMA extern void call_pernode_memory (unsigned
Re: bzImage 2.12
On Sun, Jan 27, 2013 at 7:36 PM, H. Peter Anvin wrote: > Thanks. > > Yinghai Lu wrote: > >>On Sun, Jan 27, 2013 at 11:39 AM, H. Peter Anvin wrote: >>> I'm planning to sort it out... I'll let you know if I run out of >>bandwidth. >>> >>> Yinghai Lu wrote: >>> On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin >>wrote: > > I think we can probably do that, since it doesn't affect anything non-broken > at this point. I'm sorting out what can be done for 3.8 vs 3.9 at this > point. > > Anyway, as you can tell I'm spending this weekend working for a reason. > > It turns out the patch I sent out doesn't actually build. Here is >>an > updated patch. Can I get your ack for this so I can do the appropriate > hacks to your and Yinghai's patchsets? Acked-by: Yinghai Lu Do you want to me to update my patchset on top it and resend? or you are going to sort it out by you self? >> >>To save your some time, please check attached patch. >> >>It would take position of >> >>https://patchwork.kernel.org/patch/2035731/ >> >>[25/35] x86, boot: Add fields to support load bzImage and ramdisk above >>4G >> Did you get chance to put them into for-x86-boot? You need to skip the first two about memmap= exactmap and reserveram ... Thanks Yinghai -- 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 11/11] staging/fwserial: Remove unneeded push work
Since rx push can be performed synchronously with unthrottle,
remove the push work struct and code references to it.
Signed-off-by: Peter Hurley
---
drivers/staging/fwserial/fwserial.c | 2 --
drivers/staging/fwserial/fwserial.h | 4
2 files changed, 6 deletions(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index 121beff..8983911 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -1112,7 +1112,6 @@ static void fwtty_port_shutdown(struct tty_port *tty_port)
cancel_delayed_work_sync(>emit_breaks);
cancel_delayed_work_sync(>drain);
- cancel_work_sync(>push);
spin_lock_bh(>lock);
list_for_each_entry_safe(buf, next, >buf_list, list) {
@@ -2300,7 +2299,6 @@ static int fwserial_create(struct fw_unit *unit)
INIT_DELAYED_WORK(>drain, fwtty_drain_tx);
INIT_DELAYED_WORK(>emit_breaks, fwtty_emit_breaks);
INIT_WORK(>hangup, fwtty_do_hangup);
- INIT_WORK(>push, fwtty_pushrx);
INIT_LIST_HEAD(>buf_list);
init_waitqueue_head(>wait_tx);
port->max_payload = link_speed_to_max_payload(SCODE_100);
diff --git a/drivers/staging/fwserial/fwserial.h
b/drivers/staging/fwserial/fwserial.h
index 33a3a53..6c179f0 100644
--- a/drivers/staging/fwserial/fwserial.h
+++ b/drivers/staging/fwserial/fwserial.h
@@ -223,9 +223,6 @@ struct buffered_rx {
* The work can race with the writer but concurrent sending is
* prevented with the IN_TX flag. Scheduled under lock to
* limit scheduling when fifo has just been drained.
- * @push: work responsible for pushing buffered rx to the ldisc.
- * rx can become buffered if the tty buffer is filled before the
- * ldisc throttles the sender.
* @buf_list: list of buffered rx yet to be sent to ldisc
* @buffered: byte count of buffered rx
* @tx_fifo: fifo used to store & block-up writes for dma to remote
@@ -267,7 +264,6 @@ struct fwtty_port {
spinlock_t lock;
unsigned mctrl;
struct delayed_workdrain;
- struct work_struct push;
struct list_head buf_list;
intbuffered;
struct dma_fifotx_fifo;
--
1.8.1.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/
the patch "perf tools: Update Makefile for Android" broke 3.8-rc perf build.
Linux Kernel Mailing List skrev 12.12.2012 05:13:
Gitweb:
http://git.kernel.org/linus/;a=commit;h=d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4
Commit: d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4
Parent: 78da39faf7c903bb6e3c20a726fde1bf98d10af8
Author: Irina Tirdea
AuthorDate: Mon Oct 8 09:43:27 2012 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon Oct 8 17:42:16 2012 -0300
perf tools: Update Makefile for Android
For cross-compiling on Android, some specific changes are needed in
the Makefile.
The above patch broke perf build on i586 and x86_64:
[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1
prefix=%{_prefix} all
CHK -fstack-protector-all
CHK -Wstack-protector
CHK -Wvolatile-register-var
CHK bionic
:1:31: fatal error: android/api-level.h: No such file or directory
compilation terminated.
This is a regression since 3.7
--
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] regmap: Add "no-bus" option for regmap API
On Sun, Jan 27, 2013 at 10:49:05AM -0800, Andrey Smirnov wrote: > This commit adds provision for "no-bus" usage of the regmap API. In > this configuration user can provide API with two callbacks 'reg_read' > and 'reg_write' which are to be called when reads and writes to one of > device's registers is performed. This is useful for devices that > expose registers but whose register access sequence does not fit the 'bus' > abstraction. Great, thanks for doing this work - I've applied this now. signature.asc Description: Digital signature
Re: [PATCH v7u1 26/31] x86: Don't enable swiotlb if there is not enough ram for it
On Mon, Jan 28, 2013 at 6:27 PM, Shuah Khan wrote: > On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu wrote: > > Your for-x86-boot git boots on AMD system I have. However, with > memmap=4095$1M option, it panics very early in boot. I don't have > physical access to the console and I will try to get you the panic > information tomorrow. panic is good, but it is supposed some kind of late.. I tested on kvm and it panic late as expected: early console in setup code Probing EDD (edd=off to disable)... ok early console in decompress_kernel decompress_kernel: input: [0x2c042c2-0x3555455], output: 0x100, heap: [0x355cc40-0x3564c3f] Decompressing Linux... xz... Parsing ELF... done. Booting the kernel. [0.00] bootconsole [uart0] enabled [0.00]real_mode_data : phys 00014480 [0.00]real_mode_data : virt 88014480 [0.00] boot_params : init virt 831489c0 [0.00] boot_params : phys 031489c0 [0.00] boot_params : virt 8800031489c0 [0.00] boot_command_line : init virt 83036020 [0.00] boot_command_line : phys 03036020 [0.00] boot_command_line : virt 880003036020 [0.00] Kernel Layout: [0.00] .text: [0x0100-0x021825b9] [0.00] .rodata: [0x0220-0x02a24fff] [0.00] .data: [0x02c0-0x02dcc8bf] [0.00] .init: [0x02dce000-0x03133fff] [0.00].bss: [0x03142000-0x03dd] [0.00].brk: [0x03de-0x03e04fff] [0.00] memblock_reserve: [0x0009fc00-0x000f] * BIOS reserved [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.8.0-rc5-yh-01253-gdf8eac2-dirty (y...@linux-siqj.site) (gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #1194 SMP Mon Jan 28 19:36:41 PST 2013 [0.00] memblock_reserve: [0x0100-0x03dd] TEXT DATA BSS [0.00] memblock_reserve: [0x7d9ac000-0x7fffefff] RAMDISK [0.00] Command line: BOOT_IMAGE=linux debug ignore_loglevel memmap=4095M$1M pci=routeirq ramdisk_size=262144 root=/dev/ram0 rw ip=dhcp console=uart8250,io,0x3f8,115200 initrd=initrd.img [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] Physical RAM map: [0.00] raw: [mem 0x-0x0009fbff] usable [0.00] raw: [mem 0x0009fc00-0x0009] reserved [0.00] raw: [mem 0x000f-0x000f] reserved [0.00] raw: [mem 0x0010-0xdfffdfff] usable [0.00] raw: [mem 0xdfffe000-0xdfff] reserved [0.00] raw: [mem 0xfeffc000-0xfeff] reserved [0.00] raw: [mem 0xfffc-0x] reserved [0.00] raw: [mem 0x0001-0x00019fff] usable [0.00] e820: BIOS-provided physical RAM map (sanitized by setup): [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xdfffdfff] usable [0.00] BIOS-e820: [mem 0xdfffe000-0xdfff] reserved [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [0.00] BIOS-e820: [mem 0xfffc-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00019fff] usable [0.00] debug: ignoring loglevel setting. [0.00] NX (Execute Disable) protection: active [0.00] e820: user-defined physical RAM map: [0.00] user: [mem 0x-0x0009fbff] usable [0.00] user: [mem 0x0009fc00-0x0009] reserved [0.00] user: [mem 0x000f-0x] reserved [0.00] user: [mem 0x0001-0x00019fff] usable [0.00] SMBIOS 2.4 present. [0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011 [0.00] .text .data .bss are not marked as E820_RAM! [0.00] e820: remove [mem 0x0100-0x03e04fff] [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x1a max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00E000 mask FFE000 uncachable [0.00] 1 disabled [0.00] 2 disabled [
[GIT PULL] regulator updates for v3.8
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311: Linux 3.8-rc5 (2013-01-25 11:57:28 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-3.8-rc5 for you to fetch changes up to 51b919bae5ea1a14083c54f494f68b6bee737716: Merge remote-tracking branch 'regulator/fix/lrg' into tmp (2013-01-29 11:14:41 +0800) regulator: Fixes for v3.8-rc5 Fairly small stuff - a build failure fix for ST platforms, an error checking fix and an update to the MAINTAINERS file for Liam. Axel Lin (1): regulator: tps80031: Use IS_ERR to check return value of regulator_register() Liam Girdwood (1): regulator: MAINTAINERS: update email address Mark Brown (3): Merge remote-tracking branch 'regulator/fix/db8500' into tmp Merge remote-tracking branch 'regulator/fix/tps80031' into tmp Merge remote-tracking branch 'regulator/fix/lrg' into tmp Steven Rostedt (1): regulators: db8500: Fix compile failure for drivers/regulator/dbx500-prcmu.c MAINTAINERS|2 +- drivers/regulator/dbx500-prcmu.c |1 + drivers/regulator/tps80031-regulator.c |2 +- 3 files changed, 3 insertions(+), 2 deletions(-) signature.asc Description: Digital signature
Re: [PATCH 2/2] regulator: tps65910: Fix using wrong dev argument for calling of_regulator_match
On Mon, Jan 28, 2013 at 05:03:29PM -0700, Stephen Warren wrote: > On 01/23/2013 07:31 PM, Axel Lin wrote: > > The dev parameter is the device requesting the data. > > In this case it should be >dev rather than pdev->dev.parent. > > The dev parameter is used to call devm_kzalloc in > > of_get_regulator_init_data(), > > which means this fixes a memory leak because the memory is allocated every > > time > > probe() is called, thus it should be freed when this driver is unloaded. > With this patch as part of next-20130128, I see a crash when booting my > system. Reverting this patch solves the problem. Hrm, there's nothing obviously wrong with the code here - all we do with dev is call devm_kzalloc(). Can you decode where the crash is actually occurring, that might give a clue as to what's getting upset? In the backtrace it's in regulator_register() but that's a pretty big function. signature.asc Description: Digital signature
[PATCH 02/11] staging/fwserial: Release port regardless of unplug response code
After sending the unplug response, release the port even if an
error occurred.
Signed-off-by: Peter Hurley
---
drivers/staging/fwserial/fwserial.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index b1482ef..055085d 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -2675,10 +2675,9 @@ static void fwserial_handle_unplug_req(struct
work_struct *work)
spin_lock_bh(>lock);
if (peer->state == FWPS_UNPLUG_RESPONDING) {
- if (rcode == RCODE_COMPLETE)
- port = peer_revert_state(peer);
- else
+ if (rcode != RCODE_COMPLETE)
fwtty_err(>unit, "UNPLUG_RSP error (%d)", rcode);
+ port = peer_revert_state(peer);
}
cleanup:
spin_unlock_bh(>lock);
--
1.8.1.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/
