[PATCH v9 0/4] Add a new Rockchip usb2 phy driver
The newer SoCs (rk3366, rk3399) of Rock-chip take a different usb-phy IP block than rk3288 and before, and most of phy-related registers are also different from the past, so a new phy driver is required necessarily. These series patch add phy-rockchip-inno-usb2.c and the corresponding dt-bindings. Changes in v9: - Move the usb gpio config from dtsi to dts. - Add vin-supply (vcc5v0_sys) for vcc5v0_host. - Change some properties' name. Changes in v8: - Added support for rk3399 SoC. - Prepare input clock of phy at probe time. - Improved sm_work function to handle phy-port state more clearly. Changes in v7: - Renamed functions *usb2phy_resume/*usb2phy_suspend to *usb2phy_power_on/usb2phy_power_off. Changes in v6: - Changed '_' to '-' for otg-id and otg-bvalid property in devicetree bindings. - Fixed the output clock would be disabled more than once while phy-port was going to suspend. - Improved the driver to avoid the currently empty otg-port would cause null-pointer dereferences. Changes in v5: - Added 'reg' property both in devicetree bindings and driver to match the different phy-blocks. Changes in v4: - Used 'phy-supply' instead of 'vbus_*-supply'. Changes in v3: - Supplemented some hardware-description into the devicetree bindings. - Resolved the mapping defect between fixed value in driver and the property in devicetree. - Code cleanup. Changes in v2: - Specified more hardware-description into the devicetree bindings. - Optimized some process of driver. Frank Wang (4): Documentation: bindings: add DT documentation for Rockchip USB2PHY phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy arm64: dts: rockchip: add usb2-phy support for rk3399 arm64: dts: rockchip: configure usb2-phy support for rk3399-evb .../bindings/phy/phy-rockchip-inno-usb2.txt| 64 ++ arch/arm64/boot/dts/rockchip/rk3399-evb.dts| 44 ++ arch/arm64/boot/dts/rockchip/rk3399.dtsi | 42 +- drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-rockchip-inno-usb2.c | 707 6 files changed, 864 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c -- 1.7.9.5
[PATCH v9 1/4] Documentation: bindings: add DT documentation for Rockchip USB2PHY
Signed-off-by: Frank Wang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Changed '_' to '-' for otg-id and otg-bvalid property.
Changes in v5:
- Added 'reg' property to identify the different phy-blocks.
Changes in v4:
- Used 'phy-supply' instead of 'vbus_*-supply'.
Changes in v3:
- Added 'clocks' and 'clock-names' optional properties.
- Specified 'otg-port' and 'host-port' as the sub-node name.
Changes in v2:
- Changed vbus_host optional property from gpio to regulator.
- Specified vbus_otg-supply optional property.
- Specified otg_id and otg_bvalid property.
.../bindings/phy/phy-rockchip-inno-usb2.txt| 64
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
new file mode 100644
index 000..3c29c77
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -0,0 +1,64 @@
+ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
+
+Required properties (phy (parent) node):
+ - compatible : should be one of the listed compatibles:
+ * "rockchip,rk3366-usb2phy"
+ * "rockchip,rk3399-usb2phy"
+ - reg : the address offset of grf for usb-phy configuration.
+ - #clock-cells : should be 0.
+ - clock-output-names : specify the 480m output clock name.
+
+Optional properties:
+ - clocks : phandle + phy specifier pair, for the input clock of phy.
+ - clock-names : input clock name of phy, must be "phyclk".
+
+Required nodes : a sub-node is required for each port the phy provides.
+The sub-node name is used to identify host or otg port,
+and shall be the following entries:
+ * "otg-port" : the name of otg port.
+ * "host-port" : the name of host port.
+
+Required properties (port (child) node):
+ - #phy-cells : must be 0. See ./phy-bindings.txt for details.
+ - interrupts : specify an interrupt for each entry in interrupt-names.
+ - interrupt-names : a list which shall be the following entries:
+ * "otg-id" : for the otg id interrupt.
+ * "otg-bvalid" : for the otg vbus interrupt.
+ * "linestate" : for the host/otg linestate interrupt.
+
+Optional properties:
+ - phy-supply : phandle to a regulator that provides power to VBUS.
+ See ./phy-bindings.txt for details.
+
+Example:
+
+grf: syscon@ff77 {
+ compatible = "rockchip,rk3366-grf", "syscon", "simple-mfd";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+...
+
+ u2phy: usb2-phy@700 {
+ compatible = "rockchip,rk3366-usb2phy";
+ reg = <0x700 0x2c>;
+ #clock-cells = <0>;
+ clock-output-names = "sclk_otgphy0_480m";
+
+ u2phy_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = ,
+,
+;
+ interrupt-names = "otg-id", "otg-bvalid", "linestate";
+ status = "okay";
+ };
+
+ u2phy_host: host-port {
+ #phy-cells = <0>;
+ interrupts = ;
+ interrupt-names = "linestate";
+ status = "okay";
+ };
+ };
+};
--
1.7.9.5
[PATCH v9 2/4] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy
The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
than rk3288 and before, and most of phy-related registers are also
different from the past, so a new phy driver is required necessarily.
Signed-off-by: Frank Wang
Suggested-by: Heiko Stuebner
Suggested-by: Guenter Roeck
Suggested-by: Doug Anderson
Reviewed-by: Heiko Stuebner
Reviewed-by: Guenter Roeck
---
Changes in v9:
- Add "Reviewed-by" info.
Changes in v8:
- Added support for rk3399 SoC.
- Prepare input clock of phy at probe time.
- Improved sm_work function to handle phy-port state more clearly.
Changes in v7:
- renamed functions *usb2phy_resume/*usb2phy_suspend to
*usb2phy_power_on/usb2phy_power_off.
Changes in v6:
- Fixed the output clock would be disabled more than once while phy-port was
going to suspend.
- Improved the driver to avoid the currently empty otg-port would cause
null-pointer dereferences.
Changes in v5:
- Added 'reg' in the data block to match the different phy-blocks in dt.
Changes in v4:
- Removed some processes related to 'vbus_host-supply'.
Changes in v3:
- Resolved the mapping defect between fixed value in driver and the property
in devicetree.
- Optimized 480m output clock register function.
- Code cleanup.
Changes in v2:
- Changed vbus_host operation from gpio to regulator in *_probe.
- Improved the fault treatment relate to 480m clock register.
- Cleaned up some meaningless codes in *_clk480m_disable.
- made more clear the comment of *_sm_work.
drivers/phy/Kconfig |7 +
drivers/phy/Makefile |1 +
drivers/phy/phy-rockchip-inno-usb2.c | 707 ++
3 files changed, 715 insertions(+)
create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b869b98..29ef15c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -347,6 +347,13 @@ config PHY_ROCKCHIP_USB
help
Enable this to support the Rockchip USB 2.0 PHY.
+config PHY_ROCKCHIP_INNO_USB2
+ tristate "Rockchip INNO USB2PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Support for Rockchip USB2.0 PHY with Innosilicon IP block.
+
config PHY_ROCKCHIP_EMMC
tristate "Rockchip EMMC PHY Driver"
depends on ARCH_ROCKCHIP && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9c3e73c..4963fbc 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o
obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c
b/drivers/phy/phy-rockchip-inno-usb2.c
new file mode 100644
index 000..ac20310
--- /dev/null
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -0,0 +1,707 @@
+/*
+ * Rockchip USB2.0 PHY with Innosilicon IP block driver
+ *
+ * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * 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
+
+#define BIT_WRITEABLE_SHIFT16
+#define SCHEDULE_DELAY (60 * HZ)
+
+enum rockchip_usb2phy_port_id {
+ USB2PHY_PORT_OTG,
+ USB2PHY_PORT_HOST,
+ USB2PHY_NUM_PORTS,
+};
+
+enum rockchip_usb2phy_host_state {
+ PHY_STATE_HS_ONLINE = 0,
+ PHY_STATE_DISCONNECT= 1,
+ PHY_STATE_CONNECT = 2,
+ PHY_STATE_FS_LS_ONLINE = 4,
+};
+
+struct usb2phy_reg {
+ unsigned intoffset;
+ unsigned intbitend;
+ unsigned intbitstart;
+ unsigned intdisable;
+ unsigned intenable;
+};
+
+/**
+ * struct rockchip_usb2phy_port_cfg: usb-phy port configuration.
+ * @phy_sus: phy suspend register.
+ * @ls_det_en: linestate detection enable register.
+ * @ls_det_st: linestate detection state register.
+ * @ls_det_clr: linestate detection clear register.
+ * @utmi_ls: utmi linestate state register.
+ * @utmi_hstdet: utmi host discon
[PATCH v9 3/4] arm64: dts: rockchip: add usb2-phy support for rk3399
Add usb2-phy nodes and specify phys phandle for ehci.
Signed-off-by: Frank Wang
---
Changes in v9:
- Move the usb gpio config to rk3399-evb.dts
- Fix ehci phy-names property.
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d7f8e06..843d51c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -221,6 +221,8 @@
interrupts = ;
clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>;
clock-names = "hclk_host0", "hclk_host0_arb";
+ phys = <&u2phy0_host>;
+ phy-names = "usb";
status = "disabled";
};
@@ -239,6 +241,8 @@
interrupts = ;
clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>;
clock-names = "hclk_host1", "hclk_host1_arb";
+ phys = <&u2phy1_host>;
+ phy-names = "usb";
status = "disabled";
};
@@ -481,8 +485,44 @@
};
grf: syscon@ff77 {
- compatible = "rockchip,rk3399-grf", "syscon";
+ compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
reg = <0x0 0xff77 0x0 0x1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ u2phy0: usb2-phy@e450 {
+ compatible = "rockchip,rk3399-usb2phy";
+ reg = <0xe450 0x10>;
+ clocks = <&cru SCLK_USB2PHY0_REF>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ clock-output-names = "clk_usbphy0_480m";
+ status = "disabled";
+
+ u2phy0_host: host-port {
+ #phy-cells = <0>;
+ interrupts = ;
+ interrupt-names = "linestate";
+ status = "disabled";
+ };
+ };
+
+ u2phy1: usb2-phy@e460 {
+ compatible = "rockchip,rk3399-usb2phy";
+ reg = <0xe460 0x10>;
+ clocks = <&cru SCLK_USB2PHY1_REF>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ clock-output-names = "clk_usbphy1_480m";
+ status = "disabled";
+
+ u2phy1_host: host-port {
+ #phy-cells = <0>;
+ interrupts = ;
+ interrupt-names = "linestate";
+ status = "disabled";
+ };
+ };
};
watchdog@ff84 {
--
1.7.9.5
[PATCH v9 4/4] arm64: dts: rockchip: configure usb2-phy support for rk3399-evb
Add vcc5v0_host regulator for usb2-phy and enable host-port support.
Signed-off-by: Frank Wang
---
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 44 +++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index 1a3eb14..56aeedb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -69,6 +69,25 @@
regulator-max-microvolt = <330>;
};
+ vcc5v0_sys: vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vcc5v0_host";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
@@ -89,6 +108,24 @@
status = "okay";
};
+&u2phy0 {
+ status = "okay";
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
&uart2 {
status = "okay";
};
@@ -121,4 +158,11 @@
<1 18 RK_FUNC_GPIO &pcfg_pull_down>;
};
};
+
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins =
+ <4 25 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
};
--
1.7.9.5
Re: [PATCH v3 2/5] i2c: Add STM32F4 I2C driver
Hi, thanks for this contribution! Looks mostly good, some comments, though. On Mon, Jun 20, 2016 at 06:22:48PM +0200, M'boumba Cedric Madianga wrote: > This patch adds support for the STM32F4 I2C controller. > > Signed-off-by: M'boumba Cedric Madianga > --- > drivers/i2c/busses/Kconfig | 10 + > drivers/i2c/busses/Makefile | 1 + > drivers/i2c/busses/i2c-stm32f4.c | 863 > +++ > 3 files changed, 874 insertions(+) > create mode 100644 drivers/i2c/busses/i2c-stm32f4.c > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index faa8e68..805acf6 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -873,6 +873,16 @@ config I2C_ST > This driver can also be built as module. If so, the module > will be called i2c-st. > > +config I2C_STM32F4 > + tristate "STMicroelectronics STM32F4 I2C support" > + depends on ARCH_STM32 || COMPILE_TEST? > + help > + Enable this option to add support for STM32 I2C controller embedded > + in STM32F4 SoCs. > + > + This driver can also be built as module. If so, the module > + will be called i2c-stm32f4. > + > config I2C_STU300 > tristate "ST Microelectronics DDC I2C interface" > depends on MACH_U300 > diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile > index 37f2819..2ac0eb2 100644 > --- a/drivers/i2c/busses/Makefile > +++ b/drivers/i2c/busses/Makefile > @@ -84,6 +84,7 @@ obj-$(CONFIG_I2C_SH_MOBILE) += i2c-sh_mobile.o > obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o > obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o > obj-$(CONFIG_I2C_ST) += i2c-st.o > +obj-$(CONFIG_I2C_STM32F4)+= i2c-stm32f4.o > obj-$(CONFIG_I2C_STU300) += i2c-stu300.o > obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o > obj-$(CONFIG_I2C_TEGRA) += i2c-tegra.o > diff --git a/drivers/i2c/busses/i2c-stm32f4.c > b/drivers/i2c/busses/i2c-stm32f4.c > new file mode 100644 > index 000..652d4bf > --- /dev/null > +++ b/drivers/i2c/busses/i2c-stm32f4.c > @@ -0,0 +1,863 @@ > +/* > + * Driver for STMicroelectronics STM32 I2C controller > + * > + * Copyright (C) M'boumba Cedric Madianga 2015 > + * Author: M'boumba Cedric Madianga > + * > + * This driver is based on st-i2c.c i2c-st.c ? > + * > + * License terms: GNU General Public License (GPL), version 2 > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* STM32F4 I2C offset registers */ > +#define STM32F4_I2C_CR1 0x00 > +#define STM32F4_I2C_CR2 0x04 > +#define STM32F4_I2C_DR 0x10 > +#define STM32F4_I2C_SR1 0x14 > +#define STM32F4_I2C_SR2 0x18 > +#define STM32F4_I2C_CCR 0x1C > +#define STM32F4_I2C_TRISE0x20 > +#define STM32F4_I2C_FLTR 0x24 > + > +/* STM32F4 I2C control 1*/ > +#define STM32F4_I2C_CR1_SWRSTBIT(15) > +#define STM32F4_I2C_CR1_POS BIT(11) > +#define STM32F4_I2C_CR1_ACK BIT(10) > +#define STM32F4_I2C_CR1_STOP BIT(9) > +#define STM32F4_I2C_CR1_STARTBIT(8) > +#define STM32F4_I2C_CR1_PE BIT(0) > + > +/* STM32F4 I2C control 2 */ > +#define STM32F4_I2C_CR2_FREQ_MASKGENMASK(5, 0) > +#define STM32F4_I2C_CR2_FREQ(n) ((n & > STM32F4_I2C_CR2_FREQ_MASK)) > +#define STM32F4_I2C_CR2_ITBUFEN BIT(10) > +#define STM32F4_I2C_CR2_ITEVTEN BIT(9) > +#define STM32F4_I2C_CR2_ITERREN BIT(8) > +#define STM32F4_I2C_CR2_IRQ_MASK (STM32F4_I2C_CR2_ITBUFEN \ > + | STM32F4_I2C_CR2_ITEVTEN \ > + | STM32F4_I2C_CR2_ITERREN) > + > +/* STM32F4 I2C Status 1 */ > +#define STM32F4_I2C_SR1_AF BIT(10) > +#define STM32F4_I2C_SR1_ARLO BIT(9) > +#define STM32F4_I2C_SR1_BERR BIT(8) > +#define STM32F4_I2C_SR1_TXE BIT(7) > +#define STM32F4_I2C_SR1_RXNE BIT(6) > +#define STM32F4_I2C_SR1_BTF BIT(2) > +#define STM32F4_I2C_SR1_ADDR BIT(1) > +#define STM32F4_I2C_SR1_SB BIT(0) > +#define STM32F4_I2C_SR1_ITEVTEN_MASK (STM32F4_I2C_SR1_BTF \ > + | STM32F4_I2C_SR1_ADDR \ > + | STM32F4_I2C_SR1_SB) > +#define STM32F4_I2C_SR1_ITBUFEN_MASK (STM32F4_I2C_SR1_TXE \ > + | STM32F4_I2C_SR1_RXNE) > +#define STM32F4_I2C_SR1_ITERREN_MASK (STM32F4_I2C_SR1_AF \ > + | STM32F4_I2C_SR1_ARLO \ > + | STM32F4_I2C_SR1_BERR) > + > +/* STM32F4 I2C Status 2 */ > +#define STM32F4_I2C_SR2_BUSY BIT(1) > + > +/* STM32F4 I2C Control Clock */ > +#define STM32F4_I2C_CCR_CCR_MASK GEN
Re: [RFC PATCH 0/9][V3] Overlayfs SELinux Support
On Thu, Jul 21, 2016 at 11:16 PM, Paul Moore wrote: > Hi Vivek, > > These patches look fine to me, thanks for all your hard work and to > everyone who helped review and provide feedback. I have tagged these > patches for merging into the SELinux next branch after this merge > window. > > Miklos, this patchset depends on patches in your overlayfs-next > branch, I assume you're pushing that branch during the upcoming merge > window? Yes, that's the plan. Thanks, Miklos
linux-next: Tree for Jul 22
Hi all, Changes since 20160721: The powerpc tree gained a build failure for which I applied a fix patch. The fuse tree gained a build failure due to an interaction with the btrfs-kdave tree, so I applied a merge fix patch. The pm tree gained a build failure, so I used the version from next-20160721. The nvdimm tree lost its build failure but gained another due to an interaction with the device-mapper tree. I applied a merge fix patch. Non-merge commits (relative to Linus' tree): 10807 9936 files changed, 548899 insertions(+), 195049 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 239 trees (counting Linus' and 35 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (47ef4ad2684d Merge tag 'for-linus-20160715' of git://git.infradead.org/linux-mtd) Merging fixes/master (5edb56491d48 Linux 4.7-rc3) Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported variables) Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if DW2_UNWIND is disabled) Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 errata initialization) Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs for v4.7-rc2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging powerpc-fixes/fixes (bfa37087aa04 powerpc: Initialise pci_io_base as early as possible) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (6b15d6650c53 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging net/master (882b0f2fba83 net/mlx5e: Fix del vxlan port command buffer memset) Merging ipsec/master (1ba5bf993c6a xfrm: fix crash in XFRM_MSG_GETSA netlink handler) Merging netfilter/master (ea43f860d984 Merge branch 'ethoc-fixes') Merging ipvs/master (3777ed688fba ipvs: fix bind to link-local mcast IPv6 address in backup) Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git) Merging mac80211/master (16a910a6722b cfg80211: handle failed skb allocation) Merging sound-current/for-linus (76df52969711 ALSA: usb-audio: Fix quirks code is not called) Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC code) Merging driver-core.current/driver-core-linus (92d21ac74a9e Linux 4.7-rc7) Merging tty.current/tty-linus (a99cde438de0 Linux 4.7-rc6) Merging usb.current/usb-linus (a99cde438de0 Linux 4.7-rc6) Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command) Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5) Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: otg-fsm: add license to usb-otg-fsm) Merging staging.current/staging-linus (a99cde438de0 Linux 4.7-rc6) Merging char-misc.current/char-misc-linus (33688abb2802 Linux 4.7-rc4) Merging input-current/for-linus (e9003c9cfaa1 Input: tsc200x - report proper input_dev name) Merging crypto-current/master (81dc0365cfa7 crypto: qat - make qat_asym_algs.o depend on asn1 headers) Merging ide/master (1993b176a822 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms vs module insertion race.) Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read) Merging kselftest-fixes/fixes (f80eb4289491 sel
Re: [PATCH v6 2/2] Bindings documentation for ISSI is31fl319x driver
On 07/22/2016 08:42 AM, H. Nikolaus Schaller wrote: Hi, Am 22.07.2016 um 08:36 schrieb Jacek Anaszewski : On 07/20/2016 03:24 AM, Rob Herring wrote: On Tue, Jul 19, 2016 at 01:47:31PM +0200, H. Nikolaus Schaller wrote: Signed-off-by: H. Nikolaus Schaller --- .../devicetree/bindings/leds/is31fl319x.txt| 59 ++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/is31fl319x.txt diff --git a/Documentation/devicetree/bindings/leds/is31fl319x.txt b/Documentation/devicetree/bindings/leds/is31fl319x.txt new file mode 100644 index 000..03287c0 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/is31fl319x.txt @@ -0,0 +1,59 @@ +LEDs connected to is31fl319x LED controller chip + +Required properties: +- compatible : Should be any of + "issi,is31fl3190" + "issi,is31fl3191" + "issi,is31fl3193" + "issi,is31fl3196" + "issi,is31fl3199" + "si-en,sn3199". +- #address-cells: Must be 1. +- #size-cells: Must be 0. +- reg: 0x64, 0x65, 0x66, 0x67. This is an OR or AND? OR it seems. With that, Nikolaus, could you please make it explicit? Yes, Rob's intuition is right. An AND does obviously not make sense for a reg property. It is an OR. So if you perfer, please substitute - reg: 0x64, 0x65, 0x66, or 0x67. Updated the for-4.9 branch accordingly. I also added "led-" prefix to the file name to match it with the vast majority of the remaining ones. -- Best regards, Jacek Anaszewski
Re: [PATCH v2] 2c: mv64xxx: Use clk_enable_prepare and clk_disable_unprepare
On Wed, Jul 20, 2016 at 10:44:18AM +0530, Amitoj Kaur Chawla wrote: > Replace clk_enable and clk_prepare with clk_enable_prepare and > clk_disable and clk_unprepare with clk_disable_unprepare. > > The Coccinelle semantic patch used to make this change is as follows: > @@ > expression e; > @@ > > - clk_prepare(e); > - clk_enable(e); > + clk_prepare_enable(e); > > @@ > expression e; > @@ > > - clk_disable(e); > - clk_unprepare(e); > + clk_disable_unprepare(e); > > Signed-off-by: Amitoj Kaur Chawla > --- > Changes in v2: > -Rebased patch I still can't apply and nothing changed to the previous patch you sent? To what did you rebase? signature.asc Description: PGP signature
Re: [PATCH] ARM: OMAP3: hwmod data: Add sysc information for DSI
* Sebastian Reichel [160623 19:02]: > Add missing sysconfig/sysstatus information > to OMAP3 hwmod. The information has been > checked against OMAP34xx and OMAP36xx TRM. > > Without this change DSI block is not reset > during boot, which is required for working > Nokia N950 display. > > Signed-off-by: Sebastian Reichel > --- > Hi, > > This is an updated version of this patch [0]. Instead > of the workaround implemented in [0], this patch fixes > the root problem - missing hwmod data. I think it should > be added to -rc. > > [0] http://article.gmane.org/gmane.comp.video.dri.devel/153665 Sorry for the delay in replying, I was offline for few weeks. I'll add this into fixes for v4.8 with cc stable as it's not a regression or a oops. Regards, Tony
Re: [PATCH 2/2] ARM: DRA7: select PCI_DOMAINS config
* Arnd Bergmann [160721 05:08]: > On Thursday, July 21, 2016 5:27:56 PM CEST Kishon Vijay Abraham I wrote: > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > > index 1a648e9..8e6e2c0 100644 > > --- a/arch/arm/mach-omap2/Kconfig > > +++ b/arch/arm/mach-omap2/Kconfig > > @@ -86,6 +86,7 @@ config SOC_DRA7XX > > select OMAP_INTERCONNECT_BARRIER > > select PM_OPP if PM > > select ZONE_DMA if ARM_LPAE > > + select PCI_DOMAINS if PCI > > > > config ARCH_OMAP2PLUS > > bool > > > > Should we just set this unconditionally for ARCH_MULTIPLATFORM maybe? Makes sense to me if many SoCs need this. Regards, Tony
Re: [PATCH v6 1/2] [media] atmel-isc: add the Image Sensor Controller code
On 07/22/2016 07:18 AM, Wu, Songjun wrote:
>>> +/*
>>> + * index(0~11): raw formats.
>>> + * index(12~12): the formats which can be converted from raw format by ISC.
>>> + * index(): the formats which can only be provided by subdev.
>>> + */
>>> +static struct isc_format isc_formats[] = {
>>
>> static const
>>
> Some members in structure isc_format need be modified, so it can not be
> const.
OK. Please add a comment about that.
Regards,
Hans
[PATCH 1/1] drm/sti: use new Reset API
Since 0b52297f228 ("reset: Add support for shared reset controls") the
new Reset API now demands consumers choose either an *_exclusive or
a *_shared line when requesting reset lines.
Signed-off-by: Lee Jones
---
drivers/gpu/drm/sti/sti_compositor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_compositor.c
b/drivers/gpu/drm/sti/sti_compositor.c
index 3d2fa3a..c2ace02 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -234,12 +234,12 @@ static int sti_compositor_probe(struct platform_device
*pdev)
}
/* Get reset resources */
- compo->rst_main = devm_reset_control_get(dev, "compo-main");
+ compo->rst_main = devm_reset_control_get_shared(dev, "compo-main");
/* Take compo main out of reset */
if (!IS_ERR(compo->rst_main))
reset_control_deassert(compo->rst_main);
- compo->rst_aux = devm_reset_control_get(dev, "compo-aux");
+ compo->rst_aux = devm_reset_control_get_shared(dev, "compo-aux");
/* Take compo aux out of reset */
if (!IS_ERR(compo->rst_aux))
reset_control_deassert(compo->rst_aux);
--
2.9.0
Re: [PATCH 28/32] i2c: bcm2835: Set up the rising/falling edge delays.
On Wed, Jun 01, 2016 at 11:43:37PM +0200, Gerd Hoffmann wrote: > From: Eric Anholt > > We were leaving them in the power on state (or the state the firmware > had set up for some client, if we were taking over from them). The > boot state was 30 core clocks, when we actually want to sample some > time after (to make sure that the new input bit has actually arrived). > > Signed-off-by: Eric Anholt Gerd, your Signed-off is missing here. signature.asc Description: PGP signature
Re: [PATCH 24/32] i2c: bcm2835: Don't complain on -EPROBE_DEFER from getting our clock
On Wed, Jun 01, 2016 at 11:43:33PM +0200, Gerd Hoffmann wrote: > From: Eric Anholt > > Fixes dmesg spam when we just need to wait a moment for the clock > driver to probe. > > Signed-off-by: Eric Anholt I applied Eric's original patch now. signature.asc Description: PGP signature
Re: [PATCH v4 00/12] allow BFLT executables on systems with a MMU
On 22/07/16 00:48, Nicolas Pitre wrote: > On Thu, 21 Jul 2016, Greg Ungerer wrote: >> Hi Nicolas, >> >> On 21/07/16 05:22, Nicolas Pitre wrote: >>> This series provides the necessary changes to allow "flat" executable >>> binaries meant for no-MMU systems to actually run on systems with a MMU. >>> Also thrown in are various cleanups to binfmt_flat.c. >> >> I got to the bottom of why I couldn't run m68k flat binaries on >> an MMU enabled m68k system. I had to fix the regs setup, with the >> patch below. With this I can now run flat binaries on my ColdFire >> MMU enabled system. > > Excellent! > >> This change is completely independent of your patch series so I'll >> push this separately via the linux-m68k list and my m68knommu git >> tree. > > OK. > > Who should merge my patch series at this point? If no-one else wants to carry it I can take it in the m68knommu git tree. But I would want to be sure everyone is good with it first. Alan: are you happy with where this is at? rmk: ok with the arm flat.h change going via another tree? Al/David: any comments on this? (Link to v4 patches here https://lkml.org/lkml/2016/7/20/508 ) Regards Greg
Re: [PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.
On Sun, Jul 03, 2016 at 06:02:32PM -0700, Eric Anholt wrote: > Wolfram Sang writes: > > >> + /* > >> + * SMBUS says "Devices participating in a transfer will > >> + * timeout when any clock low exceeds the value of > >> + * T_TIMEOUT,MIN of 25 ms." > >> + */ > > > > SMBus has that timeout, but I2C doesn't. How about disabling the timeout > > simply? Or using the max value if you want to keep the timeout > > detection? > > Disabling the timeout seems fine to me. We still have a 1-second > timeout around the entire transfer. I'll be back on my DSI branch this > week and test it out then. Did it work? signature.asc Description: PGP signature
Re: [PATCH] i2c: bcm2835: Don't complain on -EPROBE_DEFER from getting our clock
On Thu, Feb 18, 2016 at 05:12:55PM -0800, Eric Anholt wrote: > Fixes dmesg spam when we just need to wait a moment for the clock > driver to probe. > > Signed-off-by: Eric Anholt Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH v2] 2c: mv64xxx: Use clk_enable_prepare and clk_disable_unprepare
there is an i missing in the Subject.
On Wed, Jul 20, 2016 at 10:44:18AM +0530, Amitoj Kaur Chawla wrote:
> Replace clk_enable and clk_prepare with clk_enable_prepare and
> clk_disable and clk_unprepare with clk_disable_unprepare.
>
> The Coccinelle semantic patch used to make this change is as follows:
> @@
> expression e;
> @@
>
> - clk_prepare(e);
> - clk_enable(e);
> + clk_prepare_enable(e);
>
> @@
> expression e;
> @@
>
> - clk_disable(e);
> - clk_unprepare(e);
> + clk_disable_unprepare(e);
>
> Signed-off-by: Amitoj Kaur Chawla
> ---
> Changes in v2:
> -Rebased patch
>
> drivers/i2c/busses/i2c-mv64xxx.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
> b/drivers/i2c/busses/i2c-mv64xxx.c
> index 43207f5..79bae48 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -910,10 +910,8 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> #if defined(CONFIG_HAVE_CLK)
> /* Not all platforms have a clk */
> drv_data->clk = devm_clk_get(&pd->dev, NULL);
> - if (!IS_ERR(drv_data->clk)) {
> - clk_prepare(drv_data->clk);
> - clk_enable(drv_data->clk);
> - }
> + if (!IS_ERR(drv_data->clk))
> + clk_prepare_enable(drv_data->clk);
When you touch this, better add error checking. I wonder why these
functions are not marked __must_check.
Also using IS_ERR(drv_data->clk) is wrong here, becauce devm_clk_get
might return -EPROBE_DEFER.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
RE: [PATCH v3 1/3] arm64: mm: add __clean_dcache_area()
Hi Will, > -Original Message- > From: Will Deacon [mailto:will.dea...@arm.com] > Sent: Friday, July 22, 2016 1:12 AM > To: 이광우(LEE KWANGWOO) MS SW > Cc: linux-arm-ker...@lists.infradead.org; linux-nvd...@lists.01.org; Catalin > Marinas; Mark Rutland; > Ross Zwisler; Dan Williams; Vishal Verma; 정우석(CHUNG WOO SUK) MS SW; 김현철(KIM > HYUNCHUL) MS SW; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH v3 1/3] arm64: mm: add __clean_dcache_area() > > On Fri, Jul 15, 2016 at 11:46:20AM +0900, Kwangwoo Lee wrote: > > Ensure D-cache lines are cleaned to the PoC(Point of Coherency). > > > > This function is called by arch_wb_cache_pmem() to clean the cache lines > > and remain the data in cache for the next access. > > > > Signed-off-by: Kwangwoo Lee > > --- > > arch/arm64/include/asm/cacheflush.h | 1 + > > arch/arm64/mm/cache.S | 18 ++ > > 2 files changed, 19 insertions(+) > > > > diff --git a/arch/arm64/include/asm/cacheflush.h > > b/arch/arm64/include/asm/cacheflush.h > > index c64268d..903a94f 100644 > > --- a/arch/arm64/include/asm/cacheflush.h > > +++ b/arch/arm64/include/asm/cacheflush.h > > @@ -68,6 +68,7 @@ > > extern void flush_cache_range(struct vm_area_struct *vma, unsigned long > > start, unsigned long end); > > extern void flush_icache_range(unsigned long start, unsigned long end); > > extern void __flush_dcache_area(void *addr, size_t len); > > +extern void __clean_dcache_area(void *addr, size_t len); > > extern void __clean_dcache_area_pou(void *addr, size_t len); > > extern long __flush_cache_user_range(unsigned long start, unsigned long > > end); > > > > diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S > > index 6df0706..5a350e4 100644 > > --- a/arch/arm64/mm/cache.S > > +++ b/arch/arm64/mm/cache.S > > @@ -93,6 +93,24 @@ ENTRY(__flush_dcache_area) > > ENDPIPROC(__flush_dcache_area) > > > > /* > > + * __clean_dcache_area(kaddr, size) > > + * > > + * Ensure that any D-cache lines for the interval [kaddr, > > kaddr+size) > > + * are cleaned to the PoC. > > + * > > + * - kaddr - kernel address > > + * - size- size in question > > + */ > > +ENTRY(__clean_dcache_area) > > +alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE > > + dcache_by_line_op cvac, sy, x0, x1, x2, x3 > > +alternative_else > > + dcache_by_line_op civac, sy, x0, x1, x2, x3 > > +alternative_endif > > + ret > > +ENDPROC(__clean_dcache_area) > > This looks functionally equivalent to __dma_clean_range. How about we: > > 1. Convert the __dma_* routines to use dcache_by_line > 2. Introduce __clean_dcache_area_poc as a fallthrough to __dma_clean_range > 3. Use __clean_dcache_area_poc for the pmem stuff (with some parameter > marshalling in the macro). OK. I'll revise the patch following your comment in the next round. Thanks for the comment! > Will Best Regards, Kwangwoo Lee
Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()
Hello,
On Thu, 21 Jul 2016, Chunhui He wrote:
> If neigh entry was CONNECTED and address is not changed, and if new state is
> STALE, entry state will not change. Because DELAY is not in CONNECTED, it's
> possible to change state from DELAY to STALE.
>
> That is bad. Consider a host in IPv4 nerwork, a neigh entry in STALE state
> is referenced to send packets, so goes to DELAY state. If the entry is not
> confirmed by upper layer, it goes to PROBE state, and sends ARP request.
> The neigh host sends ARP reply, then the entry goes to REACHABLE state.
> But the entry state may be reseted to STALE by broadcast ARP packets, before
> the entry goes to PROBE state. So it's possible that the entry will never go
> to REACHABLE state, without external confirmation.
>
> In my case, the gateway refuses to send unicast packets to me, before it sees
> my ARP request. So it's critical to enter REACHABLE state by sending ARP
> request, but not by external confirmation.
>
> This fixes neigh_update() not to change to STALE if old state is CONNECTED or
> DELAY.
>
> Signed-off-by: Chunhui He
> ---
> net/core/neighbour.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 510cd62..29429eb 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -1152,7 +1152,7 @@ int neigh_update(struct neighbour *neigh, const u8
> *lladdr, u8 new,
> } else {
> if (lladdr == neigh->ha && new == NUD_STALE &&
> ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
> - (old & NUD_CONNECTED))
> + (old & (NUD_CONNECTED | NUD_DELAY)))
> )
> new = old;
> }
You change looks correct to me. But this place
has more problems. There is no good reason to set NUD_STALE
for any state that is NUD_VALID if address is not changed.
This matches perfectly the comment above this code:
NUD_STALE should change a NUD_VALID state only when
address changes. It also means that IPv6 does not need
to provide NEIGH_UPDATE_F_WEAK_OVERRIDE anymore when
NEIGH_UPDATE_F_OVERRIDE is also present.
By this way the state machine can continue with
the resolving: NUD_STALE -> NUD_DELAY (traffic) ->
NUD_PROBE (retries) -> NUD_REACHABLE (unicast reply)
while the address is not changed. Your change covers only
NUD_DELAY, not NUD_PROBE, so it is better to allow more
retries to send. We should not give up until success (NUD_REACHABLE).
Second problem: NEIGH_UPDATE_F_WEAK_OVERRIDE has no
priority over NEIGH_UPDATE_F_ADMIN. For example, now I can not
change from NUD_PERMANENT to NUD_STALE:
# ip neigh add 192.168.168.111 lladdr 00:11:22:33:44:55 nud perm dev wlan0
# ip neigh show to 192.168.168.111
192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT
# ip neigh change 192.168.168.111 lladdr 00:11:22:33:44:55 nud stale dev wlan0
# ip neigh show to 192.168.168.111
192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT
IMHO, here is how this place should look:
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 5cdc62a..2b1cb91 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1151,10 +1151,8 @@ int neigh_update(struct neighbour *neigh, const u8
*lladdr, u8 new,
goto out;
} else {
if (lladdr == neigh->ha && new == NUD_STALE &&
- ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
-(old & NUD_CONNECTED))
- )
- new = old;
+ !(flags & NEIGH_UPDATE_F_ADMIN))
+ goto out;
}
}
Any thoughts?
Regards
--
Julian Anastasov
Re: [PATCH] perf symbols: Fix reading build id
On Thu, Jul 21, 2016 at 09:53:02AM +0200, Jiri Olsa wrote:
> On Thu, Jul 21, 2016 at 09:21:55AM +0200, Marc Kleine-Budde wrote:
> > On 07/21/2016 09:09 AM, Uwe Kleine-König wrote:
> > > From: Uwe Kleine-König
> > >
> > > When is_regular_file(name) is called name points to a freshly allocated
> > > and uninitialized chunk of memory, so is_regular_file(name) is usually
> > > false and reading build id is skipped which makes it impossible to
> > > find debug infos when a build id based system is in use.
> > >
> > > Fixes: 403567217d3f ("perf symbols: Do not read symbols/data from device
> > > files")
> > > Signed-off-by: Uwe Kleine-König
> >
> > See https://patchwork.kernel.org/patch/9196777/
>
> Arnaldo, could you please pull this one in?
It is in next as ed7b630b310775f3b6c0b360ede7a12cd8dff6fe. Does "pull
in" mean "send it to Linus for 4.7"? (That's what I'd consider
approriate.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: staging: ks7010: Return directly after a failed kmalloc()
>> I guess that further clarification might be needed for affected >> implementation details. > > That's OK, too. > > Acked-by: Wolfram Sang Does this acknowledgement include also the acceptance for the suggested change around calls of the functions "sdio_claim_host" and "sdio_release_host" within the implementation of the function "ks7010_upload_firmware"? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/staging/ks7010/ks7010_sdio.c?id=13123042d0dbf7635f052efc2ae69fd9af624f1d#n771 Regards, Markus
Re: staging: ks7010: Return directly after a failed kmalloc()
On Fri, Jul 22, 2016 at 09:36:53AM +0200, SF Markus Elfring wrote: > >> I guess that further clarification might be needed for affected > >> implementation details. > > > > That's OK, too. > > > > Acked-by: Wolfram Sang > > Does this acknowledgement include also the acceptance for > the suggested change around calls of the functions "sdio_claim_host" > and "sdio_release_host" within the implementation of the > function "ks7010_upload_firmware"? Likely. Send a patch and we will see. signature.asc Description: PGP signature
Re: [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources
On Thu, Jul 21, 2016 at 06:08:05PM +0800, Bob Liu wrote:
>
> On 07/21/2016 04:57 PM, Roger Pau Monné wrote:
> > On Fri, Jul 15, 2016 at 05:31:49PM +0800, Bob Liu wrote:
> >> The current VBD layer reserves buffer space for each attached device based
> >> on
> >> three statically configured settings which are read at boot time.
> >> * max_indirect_segs: Maximum amount of segments.
> >> * max_ring_page_order: Maximum order of pages to be used for the shared
> >> ring.
> >> * max_queues: Maximum of queues(rings) to be used.
> >>
> >> But the storage backend, workload, and guest memory result in very
> >> different
> >> tuning requirements. It's impossible to centrally predict application
> >> characteristics so it's best to leave allow the settings can be dynamiclly
> >> adjusted based on workload inside the Guest.
> >>
> >> Usage:
> >> Show current values:
> >> cat /sys/devices/vbd-xxx/max_indirect_segs
> >> cat /sys/devices/vbd-xxx/max_ring_page_order
> >> cat /sys/devices/vbd-xxx/max_queues
> >>
> >> Write new values:
> >> echo > /sys/devices/vbd-xxx/max_indirect_segs
> >> echo > /sys/devices/vbd-xxx/max_ring_page_order
> >> echo > /sys/devices/vbd-xxx/max_queues
> >>
> >> Signed-off-by: Bob Liu
> >> --
> >> v2: Add device lock and other comments from Konrad.
> >> ---
> >> drivers/block/xen-blkfront.c | 285
> >> ++-
> >> 1 file changed, 283 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >> index 10f46a8..9a5ed22 100644
> >> --- a/drivers/block/xen-blkfront.c
> >> +++ b/drivers/block/xen-blkfront.c
> >> @@ -46,6 +46,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include
> >> #include
> >> @@ -212,6 +213,11 @@ struct blkfront_info
> >>/* Save uncomplete reqs and bios for migration. */
> >>struct list_head requests;
> >>struct bio_list bio_list;
> >> + /* For dynamic configuration. */
> >> + unsigned int reconfiguring:1;
> >> + int new_max_indirect_segments;
> >> + int new_max_ring_page_order;
> >> + int new_max_queues;
> >> };
> >>
> >> static unsigned int nr_minors;
> >> @@ -1350,6 +1356,31 @@ static void blkif_free(struct blkfront_info *info,
> >> int suspend)
> >>for (i = 0; i < info->nr_rings; i++)
> >>blkif_free_ring(&info->rinfo[i]);
> >>
> >> + /* Remove old xenstore nodes. */
> >> + if (info->nr_ring_pages > 1)
> >> + xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-page-order");
> >> +
> >> + if (info->nr_rings == 1) {
> >> + if (info->nr_ring_pages == 1) {
> >> + xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-ref");
> >> + } else {
> >> + for (i = 0; i < info->nr_ring_pages; i++) {
> >> + char ring_ref_name[RINGREF_NAME_LEN];
> >> +
> >> + snprintf(ring_ref_name, RINGREF_NAME_LEN,
> >> "ring-ref%u", i);
> >> + xenbus_rm(XBT_NIL, info->xbdev->nodename,
> >> ring_ref_name);
> >> + }
> >> + }
> >> + } else {
> >> + xenbus_rm(XBT_NIL, info->xbdev->nodename,
> >> "multi-queue-num-queues");
> >> +
> >> + for (i = 0; i < info->nr_rings; i++) {
> >> + char queuename[QUEUE_NAME_LEN];
> >> +
> >> + snprintf(queuename, QUEUE_NAME_LEN, "queue-%u", i);
> >> + xenbus_rm(XBT_NIL, info->xbdev->nodename, queuename);
> >> + }
> >> + }
> >>kfree(info->rinfo);
> >>info->rinfo = NULL;
> >>info->nr_rings = 0;
> >> @@ -1772,6 +1803,10 @@ static int talk_to_blkback(struct xenbus_device
> >> *dev,
> >>info->nr_ring_pages = 1;
> >>else {
> >>ring_page_order = min(xen_blkif_max_ring_order, max_page_order);
> >> + if (info->new_max_ring_page_order) {
> >
> > Instead of calling this "new_max_ring_page_order", could you just call it
> > max_ring_page_order, iniitalize it to xen_blkif_max_ring_order by default
>
>
> Sure, I can do that.
>
>
> > and use it everywhere instead of xen_blkif_max_ring_order?
>
>
> But "xen_blkif_max_ring_order" still have to be used here, this is the only
> place "xen_blkif_max_ring_order" is used(except checking the value of it in
> xlblk_init()).
>
>
> >
> >> + BUG_ON(info->new_max_ring_page_order > max_page_order);
> >> + ring_page_order = info->new_max_ring_page_order;
> >> + }
> >>info->nr_ring_pages = 1 << ring_page_order;
> >>}
> >>
> >> @@ -1895,6 +1930,10 @@ static int negotiate_mq(struct blkfront_info *info)
> >>backend_max_queues = 1;
> >>
> >>info->nr_rings = min(backend_max_queues, xen_blkif_max_queues);
> >> + if (info->new_max_queues) {
> >
> > Same here IMHO, this is going to make the code flow slightly easier to
> > understand.
> >
> >> + BUG_ON(info->new_max_queues > backend_max_queues);
> >
Re: [PATCH] powernv: Use __printf in pe_level_printk
Hi,
[auto build test WARNING on v4.7-rc7]
[also build test WARNING on next-20160721]
[cannot apply to powerpc/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Joe-Perches/powernv-Use-__printf-in-pe_level_printk/20160715-171449
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All warnings (new ones prefixed by >>):
In file included from arch/powerpc/platforms/powernv/pci-ioda.c:49:0:
arch/powerpc/platforms/powernv/pci-ioda.c: In function
'pnv_ioda_deconfigure_pe':
>> arch/powerpc/platforms/powernv/pci-ioda.c:784:15: warning: format '%ld'
>> expects argument of type 'long int', but argument 4 has type 'int64_t {aka
>> long long int}' [-Wformat=]
pe_warn(pe, "OPAL error %ld remove self from PELTV\n", rc);
^
arch/powerpc/platforms/powernv/pci.h:222:36: note: in definition of macro
'pe_warn'
pe_level_printk(pe, KERN_WARNING, fmt, ##__VA_ARGS__)
^
arch/powerpc/platforms/powernv/pci-ioda.c:788:14: warning: format '%ld'
expects argument of type 'long int', but argument 4 has type 'int64_t {aka long
long int}' [-Wformat=]
pe_err(pe, "OPAL error %ld trying to setup PELT table\n", rc);
^
arch/powerpc/platforms/powernv/pci.h:220:32: note: in definition of macro
'pe_err'
pe_level_printk(pe, KERN_ERR, fmt, ##__VA_ARGS__)
^
arch/powerpc/platforms/powernv/pci-ioda.c: In function
'pnv_ioda_setup_bus_PE':
>> arch/powerpc/platforms/powernv/pci-ioda.c:1067:15: warning: format '%d'
>> expects argument of type 'int', but argument 4 has type 'resource_size_t
>> {aka long long unsigned int}' [-Wformat=]
pe_info(pe, "Secondary bus %d..%d associated with PE#%d\n",
^
arch/powerpc/platforms/powernv/pci.h:224:33: note: in definition of macro
'pe_info'
pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
^
arch/powerpc/platforms/powernv/pci-ioda.c:1067:15: warning: format '%d'
expects argument of type 'int', but argument 5 has type 'resource_size_t {aka
long long unsigned int}' [-Wformat=]
pe_info(pe, "Secondary bus %d..%d associated with PE#%d\n",
^
arch/powerpc/platforms/powernv/pci.h:224:33: note: in definition of macro
'pe_info'
pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
^
arch/powerpc/platforms/powernv/pci-ioda.c:1070:15: warning: format '%d'
expects argument of type 'int', but argument 4 has type 'resource_size_t {aka
long long unsigned int}' [-Wformat=]
pe_info(pe, "Secondary bus %d associated with PE#%d\n",
^
arch/powerpc/platforms/powernv/pci.h:224:33: note: in definition of macro
'pe_info'
pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
^
arch/powerpc/platforms/powernv/pci-ioda.c: In function
'pnv_pci_ioda2_release_dma_pe':
arch/powerpc/platforms/powernv/pci-ioda.c:1358:15: warning: format '%ld'
expects argument of type 'long int', but argument 4 has type 'int64_t {aka long
long int}' [-Wformat=]
pe_warn(pe, "OPAL error %ld release DMA window\n", rc);
^
arch/powerpc/platforms/powernv/pci.h:222:36: note: in definition of macro
'pe_warn'
pe_level_printk(pe, KERN_WARNING, fmt, ##__VA_ARGS__)
^
arch/powerpc/platforms/powernv/pci-ioda.c: In function
'pnv_pci_ioda1_setup_dma_pe':
arch/powerpc/platforms/powernv/pci-ioda.c:2100:15: warning: format '%ld'
expects argument of type 'long int', but argument 4 has type 'int64_t {aka long
long int}' [-Wformat=]
pe_err(pe, " Failed to configure 32-bit TCE table,"
^
arch/powerpc/platforms/powernv/pci.h:220:32: note: in definition of macro
'pe_err'
pe_level_printk(pe, KERN_ERR, fmt, ##__VA_ARGS__)
^
arch/powerpc/platforms/powernv/pci-ioda.c: In function
'pnv_pci_ioda2_set_window':
>> arch/powerpc/platforms/powernv/pci-ioda.c:2160:14: warning: format '%x'
>> expects argument of type 'unsigned int', but argument 7 has type 'long
>> unsigned int' [-Wformat=]
pe_info(pe, "Setting up window#%d %llx..%llx pg=%x\n", num,
^
arch/powerpc/platforms/powernv/pci.h:224:33: note: in definition of macro
'pe_info'
pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
^
arch/powerpc/platforms/powernv/pci-ioda.c:2176:14: warning: format '%ld'
expects argument of type 'long int', b
Re: [PATCH] update sc->nr_reclaimed after each shrink_slab
On Fri 22-07-16 11:43:30, Zhou Chengming wrote:
> In !global_reclaim(sc) case, we should update sc->nr_reclaimed after each
> shrink_slab in the loop. Because we need the correct sc->nr_reclaimed
> value to see if we can break out.
Does this actually change anything? Maybe I am missing something but
try_to_free_mem_cgroup_pages which is the main entry for the memcg
reclaim doesn't set reclaim_state. I don't remember why... Vladimir?
Have you observed any issues and this patch fixes it or this is just
motivated by the code inspection?
> Signed-off-by: Zhou Chengming
> ---
> mm/vmscan.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c4a2f45..47133c3 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2405,6 +2405,11 @@ static bool shrink_zone(struct zone *zone, struct
> scan_control *sc,
> memcg, sc->nr_scanned - scanned,
> lru_pages);
>
> + if (!global_reclaim(sc) && reclaim_state) {
> + sc->nr_reclaimed +=
> reclaim_state->reclaimed_slab;
> + reclaim_state->reclaimed_slab = 0;
> + }
> +
> /* Record the group's reclaim efficiency */
> vmpressure(sc->gfp_mask, memcg, false,
> sc->nr_scanned - scanned,
> --
> 1.7.7
>
--
Michal Hocko
SUSE Labs
Re: [PATCH 00/18] ARM: mvebu: misc Armada 38x/39x DT and v7 defconfig improvements
Hi Andrew, 2016-07-21 15:43 GMT+02:00 Andrew Lunn : > On Thu, Jul 21, 2016 at 02:43:56PM +0200, Grzegorz Jaszczyk wrote: > > Hi Grzegorz > > Some of these patches are missing a commit log entry. Please add at > least one line. > Ok, I will add it in next version of this patch-set, which I am planning to resubmit next week. Maybe I will get more feedback till then. Thank you, Grzegorz
Linux 3.12.62
I'm announcing the release of the 3.12.62 kernel. All users of the 3.12 kernel series must upgrade. The updated 3.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.12.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary A diff can be found at: https://git.kernel.org/stable/linux-stable/d/v3.12.61/v3.12.62 Aaro Koskinen (1): drivers: macintosh: rack-meter: limit idle ticks to total ticks Al Viro (2): fix d_walk()/non-delayed __d_free() race make nfs_atomic_open() call d_drop() on all ->open_context() errors. Alan Stern (1): USB: EHCI: declare hostpc register as zero-length array Andrew Goodbody (2): usb: musb: Stop bulk endpoint while queue is rotated usb: musb: Ensure rx reinit occurs for shared_fifo endpoints Andrey Ryabinin (1): perf/x86: Fix undefined shift on 32-bit kernels Babu Moger (1): sparc/PCI: Fix for panic while enabling SR-IOV Bernhard Thaler (1): Revert "netfilter: ensure number of counters is >0 in do_replace()" Bjørn Mork (1): cdc_ncm: workaround for EM7455 "silent" data interface Bob Copeland (1): mac80211: mesh: flush mesh paths unconditionally Borislav Petkov (1): x86/amd_nb: Fix boot crash on non-AMD systems Brian King (1): SCSI: Increase REPORT_LUNS timeout Christoph Hellwig (1): scsi: remove scsi_end_request Dan Carpenter (2): KEYS: potential uninitialized variable ALSA: compress: fix an integer overflow check Dave Jones (1): netfilter: ensure number of counters is >0 in do_replace() David S. Miller (5): sparc64: Fix bootup regressions on some Kconfig combinations. sparc64: Fix sparc64_set_context stack handling. sparc64: Take ctx_alloc_lock properly in hugetlb_setup(). sparc: Harden signal return frame checks. sparc64: Fix return from trap window fill crashes. Feng Tang (1): net: alx: Work around the DMA RX overflow issue Florian Westphal (15): netfilter: x_tables: don't move to non-existent next rule netfilter: x_tables: add and use xt_check_entry_offsets netfilter: x_tables: kill check_entry helper netfilter: x_tables: assert minimum target size netfilter: x_tables: add compat version of xt_check_entry_offsets netfilter: x_tables: check standard target size too netfilter: x_tables: check for bogus target offset netfilter: x_tables: validate all offsets and sizes in a rule netfilter: x_tables: don't reject valid target size on some architectures netfilter: arp_tables: simplify translate_compat_table args netfilter: ip_tables: simplify translate_compat_table args netfilter: ip6_tables: simplify translate_compat_table args netfilter: x_tables: xt_compat_match_from_user doesn't need a retval netfilter: x_tables: do compat validation via translate_table netfilter: x_tables: introduce and use xt_copy_counters_from_user Gavin Shan (2): powerpc/pseries: Fix PCI config address for DDW net/qlge: Avoids recursive EEH error Guilherme G. Piccoli (1): powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism H. Peter Anvin (1): x86, build: copy ldlinux.c32 to image.iso Hannes Frederic Sowa (1): udp: prevent skbs lingering in tunnel socket queues Hans de Goede (1): usb: quirks: Add no-lpm quirk for Acer C120 LED Projector Helge Deller (1): parisc: Fix pagefault crash in unaligned __get_user() call Herbert Xu (1): netlink: Fix dump skb leak/double free Jakub Sitnicki (1): ipv6: Skip XFRM lookup if dst_entry in socket cache is valid James Bottomley (1): scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands James Hogan (1): MIPS: KVM: Fix modular KVM under QEMU Jason Gunthorpe (1): IB/mlx4: Properly initialize GRH TClass and FlowLabel in AHs Javier Martinez Canillas (1): macintosh/therm_windtunnel: Export I2C module alias information Jeff Mahoney (1): ecryptfs: don't allow mmap when the lower fs doesn't support it Jiri Slaby (3): ktime: export ktime_divns base: make module_create_drivers_dir race-free Linux 3.12.62 Kangjie Lu (5): USB: usbfs: fix potential infoleak in devio ALSA: timer: Fix leak in SNDRV_TIMER_IOCTL_PARAMS ALSA: timer: Fix leak in events via snd_timer_user_ccallback ALSA: timer: Fix leak in events via snd_timer_user_tinterrupt rds: fix an infoleak in rds_inc_info_copy Kirill A. Shutemov (1): UBIFS: Implement ->migratepage() Linus Walleij (1): crypto: ux500 - memmove the right size Lukasz Odzioba (1): mm/swap.c: flush lru pvecs on compound page arrival Marcelo Tosatti (1): KVM: x86: expose invariant tsc cpuid bit (v2) Mart
[PATCH 3/3] x86/apic: Improved the setting of interrupt mode for bsp
If we specify the 'notsc' parameter for the dump-capture kernel,
and then trigger a crash(panic) by using "ALT-SysRq-c" or
"echo c > /proc/sysrq-trigger", the dump-capture kernel will
hang in calibrate_delay_converge() and wait for jiffies changes.
serial log as follows:
tsc: Fast TSC calibration using PIT
tsc: Detected 2099.947 MHz processor
Calibrating delay loop...
The reason for jiffies not changes is there's no timer interrupt
passed to dump-capture kernel.
In fact, once kernel panic occurs, the local APIC is disabled
by lapic_shutdown() in reboot path.
generly speaking, local APIC state can be initialized by BIOS
after Power-Up or Reset, which doesn't apply to kdump case.
so the kernel has to be responsible for initialize the interrupt
mode properly according the latest status of APIC in bootup path.
An MP operating system is booted under either PIC mode or
virtual wire mode. Later, the operating system switches to
symmetric I/O mode as it enters multiprocessor mode.
Two kinds of virtual wire mode are defined in Intel MP spec:
virtual wire mode via local APIC or via I/O APIC.
Now we determine the mode of APIC only through a SMP BIOS(MP table).
That's not enough.
It's better to do further check if APIC works with effective mode,
and do some porper setting.
Signed-off-by: Cao jin
Signed-off-by: Wei Jiangang
---
arch/x86/include/asm/io_apic.h | 5
arch/x86/kernel/apic/apic.c| 55 +-
arch/x86/kernel/apic/io_apic.c | 28 +
3 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 6cbf2cfb3f8a..6550bd43fa39 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -190,6 +190,7 @@ static inline unsigned int io_apic_read(unsigned int apic,
unsigned int reg)
}
extern void setup_IO_APIC(void);
+extern bool virtual_wire_via_ioapic(void);
extern void enable_IO_APIC(void);
extern void disable_IO_APIC(void);
extern void setup_ioapic_dest(void);
@@ -231,6 +232,10 @@ static inline void io_apic_init_mappings(void) { }
#define native_disable_io_apic NULL
static inline void setup_IO_APIC(void) { }
+static inline bool virtual_wire_via_ioapic(void)
+{
+ return true;
+}
static inline void enable_IO_APIC(void) { }
static inline void setup_ioapic_dest(void) { }
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 8e25b9b2d351..04358e0cf1e2 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1124,6 +1124,53 @@ void __init sync_Arb_IDs(void)
}
/*
+ * Return false means the virtual wire mode through-local-apic is inactive
+ */
+static bool virtual_wire_via_lapic(void)
+{
+ unsigned int value;
+
+ /* Check the APIC global enable/disable flag firstly */
+ if (boot_cpu_data.x86 >= 6) {
+ u32 h, l;
+
+ rdmsr(MSR_IA32_APICBASE, l, h);
+ /*
+* If local APIC is disabled by BIOS
+* do nothing, but return true
+*/
+ if (!(l & MSR_IA32_APICBASE_ENABLE))
+ return true;
+ }
+
+ /* Check the software enable/disable flag */
+ value = apic_read(APIC_SPIV);
+ if (!(value & APIC_SPIV_APIC_ENABLED))
+ return false;
+
+ /*
+* Virtual wire mode via local APIC requests
+* APIC to enable the LINT0 for edge-trggered ExtINT delivery mode
+* and LINT1 for level-triggered NMI delivery mode
+*/
+ value = apic_read(APIC_LVT0);
+ if (GET_APIC_DELIVERY_MODE(value) != APIC_MODE_EXTINT)
+ return false;
+
+ value = apic_read(APIC_LVT1);
+ if (GET_APIC_DELIVERY_MODE(value) != APIC_MODE_NMI)
+ return false;
+
+ return true;
+}
+
+static bool check_virtual_wire_mode(void)
+{
+ /* Neither of virtual wire mode is active, return false */
+ return virtual_wire_via_lapic() || virtual_wire_via_ioapic();
+}
+
+/*
* An initial setup of the virtual wire mode.
*/
void __init init_bsp_APIC(void)
@@ -1133,8 +1180,14 @@ void __init init_bsp_APIC(void)
/*
* Don't do the setup now if we have a SMP BIOS as the
* through-I/O-APIC virtual wire mode might be active.
+*
+* It's better to do further check if either through-I/O-APIC
+* or through-local-APIC is active.
+* the worst case is that both of them are inactive,
+* If so, We need to enable the virtual wire mode via through-local-APIC
*/
- if (smp_found_config || !boot_cpu_has(X86_FEATURE_APIC))
+ if ((smp_found_config && check_virtual_wire_mode()) ||
+ !boot_cpu_has(X86_FEATURE_APIC))
return;
/*
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 446702ed99dc..5a32c26938ac 100644
--- a/arch/x86/kernel/apic/i
[PATCH 2/3] x86/apic: Update comment about disabling processor focus
Fix references to discarded end_level_ioapic_irq(). Signed-off-by: Cao jin Signed-off-by: Wei Jiangang --- arch/x86/kernel/apic/apic.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index 0273b652c689..8e25b9b2d351 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1346,7 +1346,6 @@ void setup_local_APIC(void) * Actually disabling the focus CPU check just makes the hang less * frequent as it makes the interrupt distributon model be more * like LRU than MRU (the short-term load is more even across CPUs). -* See also the comment in end_level_ioapic_irq(). --macro */ /* -- 1.9.3
[PATCH 1/3] x86/apic: Remove "focus disabled" for 64bit case
Disable processor focus for 64bit causes a crash,
Call Trace as following:
[] dump_stack+0x63/0x84
[] __warn+0xd1/0xf0
[] warn_slowpath_fmt+0x5f/0x80
[] ex_handler_wrmsr_unsafe+0x62/0x70
[] fixup_exception+0x39/0x50
[] do_general_protection+0x80/0x160
[] general_protection+0x28/0x30
[] ? native_write_msr+0x4/0x30
[] ? native_apic_msr_write+0x32/0x40
[] init_bsp_APIC+0x5f/0x118
[] init_ISA_irqs+0x19/0x4c
[] native_init_IRQ+0xd/0x377
[] init_IRQ+0x42/0x49
[] start_kernel+0x2ce/0x4c8
[] ? set_init_arg+0x55/0x55
[] ? early_idt_handler_array+0x120/0x120
[] x86_64_start_reservations+0x2f/0x31
[] x86_64_start_kernel+0x14c/0x16f
Keep a consistent implementation with the setup_local_APIC(),
always use processor focus for 64bit.
more details refer to commit 89c38c2867eb ("x86: apic - unify
setup_local_APIC")
Signed-off-by: Cao jin
Signed-off-by: Wei Jiangang
---
arch/x86/kernel/apic/apic.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 60078a67d7e3..0273b652c689 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1154,9 +1154,7 @@ void __init init_bsp_APIC(void)
if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) &&
(boot_cpu_data.x86 == 15))
value &= ~APIC_SPIV_FOCUS_DISABLED;
- else
#endif
- value |= APIC_SPIV_FOCUS_DISABLED;
value |= SPURIOUS_APIC_VECTOR;
apic_write(APIC_SPIV, value);
--
1.9.3
Re: [PATCH] update sc->nr_reclaimed after each shrink_slab
On Fri 22-07-16 11:12:59, Vladimir Davydov wrote: > On Fri, Jul 22, 2016 at 09:49:13AM +0200, Michal Hocko wrote: > > On Fri 22-07-16 11:43:30, Zhou Chengming wrote: > > > In !global_reclaim(sc) case, we should update sc->nr_reclaimed after each > > > shrink_slab in the loop. Because we need the correct sc->nr_reclaimed > > > value to see if we can break out. > > > > Does this actually change anything? Maybe I am missing something but > > try_to_free_mem_cgroup_pages which is the main entry for the memcg > > reclaim doesn't set reclaim_state. I don't remember why... Vladimir? > > We don't set reclaim_state on memcg reclaim, because there might be a > lot of unrelated slab objects freed from the interrupt context (e.g. > RCU freed) while we're doing memcg reclaim. Obviously, we don't want > them to contribute to nr_reclaimed. > > Link to the thread with the problem discussion: > > http://marc.info/?l=linux-kernel&m=142132698209680&w=2 Ohh, now I rememeber again. Thanks for the refresh ;) So the patch doesn't make any difference in the end. -- Michal Hocko SUSE Labs
Re: [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources
On 07/22/2016 03:45 PM, Roger Pau Monné wrote:
> On Thu, Jul 21, 2016 at 06:08:05PM +0800, Bob Liu wrote:
>>
>> On 07/21/2016 04:57 PM, Roger Pau Monné wrote:
..[snip]..
+
+static ssize_t dynamic_reconfig_device(struct blkfront_info *info,
ssize_t count)
+{
+ unsigned int i;
+ int err = -EBUSY;
+
+ /*
+ * Make sure no migration in parallel, device lock is actually a
+ * mutex.
+ */
+ if (!device_trylock(&info->xbdev->dev)) {
+ pr_err("Fail to acquire dev:%s lock, may be in migration.\n",
+ dev_name(&info->xbdev->dev));
+ return err;
+ }
+
+ /*
+ * Prevent new requests and guarantee no uncompleted reqs.
+ */
+ blk_mq_freeze_queue(info->rq);
+ if (part_in_flight(&info->gd->part0))
+ goto out;
+
+ /*
+ * FrontBackend
+ * Switch to XenbusStateClosed
+ * frontend_changed():
+ * case XenbusStateClosed:
+ * xen_blkif_disconnect()
+ * Switch to
XenbusStateClosed
+ * blkfront_resume():
+ * frontend_changed():
+ * reconnect
+ * Wait until XenbusStateConnected
+ */
+ info->reconfiguring = true;
+ xenbus_switch_state(info->xbdev, XenbusStateClosed);
+
+ /* Poll every 100ms, 1 minute timeout. */
+ for (i = 0; i < 600; i++) {
+ /*
+ * Wait backend enter XenbusStateClosed, blkback_changed()
+ * will clear reconfiguring.
+ */
+ if (!info->reconfiguring)
+ goto resume;
+ schedule_timeout_interruptible(msecs_to_jiffies(100));
+ }
>>>
>>> Instead of having this wait, could you just set info->reconfiguring = 1,
>>> set
>>> the frontend state to XenbusStateClosed and mimic exactly what a resume
>>> from
>>> suspension does? blkback_changed would have to set the frontend state to
>>> InitWait when it detects that the backend has switched to Closed, and call
>>> blkfront_resume.
>>
>>
>> I think that won't work.
>> In the real "resume" case, the power management system will trigger all
>> ->resume() path.
>> But there is no place for dynamic configuration.
>
> Hello,
>
> I think it should be possible to set info->reconfiguring and wait for the
> backend to switch to state Closed, at that point we should call blkif_resume
> (from blkback_changed) and the backend will follow the reconection.
>
Okay, I get your point. Yes, that's an option.
But this will make 'dynamic configuration' to be async, I'm worry about the
end-user will get panic.
E.g
A end-user "echo > /sys/devices/vbd-xxx/max_indirect_segs",
but then the device will be Closed and disappeared, the user have to wait for a
random time so that the device can resume.
--
Regards,
-Bob
Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants
It's about the debris left behind if the admin (or someone with delegated authority) moves the task to a wholly different cgroup. Now we have a cgroup directory in the old cgroup, which the current task has been removed from, for which the current user has permissions and could then move the task back to. Is that the essence of the problem? That'd be one side. The other side is the one moving. Let's say the system admin thing wants to move all processe from A proper to B. It would do that by draining processes from A's procs file into B's and even that is multistep and can race. Once freezer is ported, wouldn't that allow you to stop the processes so you can drain them? I understand your concern with draining, but surely the same races occur if you fork? How many times would you need to scan cgroup.procs to make sure that you didn't miss anything (and if there's enough processes then cgroup.procs reads aren't atomic either). -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
[PATCH] usb: remove redundant dependency on USB_SUPPORT
The whole Kconfig entries of the USB subsystem are surrounded with "if USB_SUPPORT" ... "endif", so CONFIG_USB_SUPPORT=y is surely met when these two Kconfig options are visible. Signed-off-by: Masahiro Yamada --- drivers/usb/core/Kconfig | 1 - drivers/usb/dwc3/Kconfig | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index dd28010..253aac7 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -85,7 +85,6 @@ config USB_OTG_FSM config USB_ULPI_BUS tristate "USB ULPI PHY interface support" - depends on USB_SUPPORT help UTMI+ Low Pin Interface (ULPI) is specification for a commonly used USB 2.0 PHY interface. The ULPI specification defines a standard set diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 11864e4..3c6213c 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -1,7 +1,7 @@ config USB_DWC3 tristate "DesignWare USB3 DRD Core Support" depends on (USB || USB_GADGET) && HAS_DMA - select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD + select USB_XHCI_PLATFORM if USB_XHCI_HCD help Say Y or M here if your system has a Dual Role SuperSpeed USB controller based on the DesignWare USB3 IP Core. -- 1.9.1
Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants
So if I as the cgroup ns owner am moving a task from A to A_subdir, the admin scanning tasks in all of A may miss this task in motion because all the tasks files can't be scanned atomically? So, the admin just wants to move processes from A and only A to B. It doesn't wanna interfere with processes in the subdirs or on-going ns operations, but if the race occurs, both A -> B migration and ns subdir operation would succeed and the end result would be something neither expects. Just to be clear, the "ns subdir operation" is a cgroup namespaced process moving A -> A_subdir which is racing against some administrative process moving everything from A -> B (but not wanting to move A -> A_subdir)? So should there be policy within the kernel to not permit a process outside a cgroup namespace to move processes inside the namespace? Or would you be concerned about people escaping the administrator's attempts to reorganise the hierarchy? What if we extended rename(2) so that it /does/ allow for reorganisation of the hierarchy? So an administrator could use rename to change the point at which a cgroupns root is rooted at, but not be able to move the actual processes within the cgroup namespace around? The administrator could also join the cgroupns (without needing to join the userns) and then just move things around that way? Do any of those suggestions seem reasonable? -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
Re: [PATCH 07/19] x86/dumpstack: add IRQ_USABLE_STACK_SIZE define
* Josh Poimboeuf wrote: > > > irq_stack_end = (unsigned long *)(per_cpu(irq_stack_ptr, cpu)); > > > - irq_stack = (unsigned long *)(per_cpu(irq_stack_ptr, cpu) - > > > IRQ_STACK_SIZE); > > > + irq_stack = (unsigned long *)(per_cpu(irq_stack_ptr, cpu) - > > > + IRQ_USABLE_STACK_SIZE); > > > > This is different. > > If nobody knows the reason for it, I may just remove it. It doesn't > seem to blow anything up on my system. I tried digging through the git > history but it's been there since the beginning of git time. Please do any behavioral changes in separate patches - ordered after all the 'does not change behavior' low-risk patches. I.e. try to order the patches by risk: (near-)zero-risk ones first, followed by lower risk ones, closed by higher risk ones. This makes both review, application of the patches and any bisection/fixing work later on easier. If you ever see a good chance to split a patch that changes behavior into a zero-risk and a low-risk component, do so - we'd rather err on the side of being too finegrained in a series than having to scratch heads when bisecting to overly large patches. Thanks, Ingo
Re: [PATCH 2/2] ARM: DRA7: select PCI_DOMAINS config
Hi, On Friday 22 July 2016 12:46 PM, Tony Lindgren wrote: > * Arnd Bergmann [160721 05:08]: >> On Thursday, July 21, 2016 5:27:56 PM CEST Kishon Vijay Abraham I wrote: >>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig >>> index 1a648e9..8e6e2c0 100644 >>> --- a/arch/arm/mach-omap2/Kconfig >>> +++ b/arch/arm/mach-omap2/Kconfig >>> @@ -86,6 +86,7 @@ config SOC_DRA7XX >>> select OMAP_INTERCONNECT_BARRIER >>> select PM_OPP if PM >>> select ZONE_DMA if ARM_LPAE >>> + select PCI_DOMAINS if PCI >>> >>> config ARCH_OMAP2PLUS >>> bool >>> >> >> Should we just set this unconditionally for ARCH_MULTIPLATFORM maybe? > > Makes sense to me if many SoCs need this. since it doesn't harm even if a platform has a single PCIe port, it should be okay to set PCI_DOMAINS. I'll resend the following as a separate patch if it's okay. diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 90542db..0cccb50 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -338,6 +338,7 @@ config ARCH_MULTIPLATFORM select MULTI_IRQ_HANDLER select SPARSE_IRQ select USE_OF + select PCI_DOMAINS if PCI config ARM_SINGLE_ARMV7M bool "ARMv7-M based platforms (Cortex-M0/M3/M4)" Thanks Kishon
[PATCH v2 0/4] Add MT8173 MDP Driver
Changes in v2: - Add section to describe blocks function in dts-bindings - Remove the assignment of device_caps in querycap() - Remove format's name assignment - Copy colorspace-related parameters from OUTPUT to CAPTURE - Use m2m helper functions - Fix DMA allocation failure - Initialize lazily vpu instance in streamon() == Introduction == The purpose of this series is to add the driver for Media Data Path HW embedded in the Mediatek's MT8173 SoC. MDP is used for scaling and color space conversion. It could convert V4L2_PIX_FMT_MT21 to V4L2_PIX_FMT_NV12M or V4L2_PIX_FMT_YUV420M. NV12M/YUV420M/MT21 -> MDP -> NV12M/YUV420M This patch series rely on MTK VPU driver in patch series "Add MT8173 Video Encoder Driver and VPU Driver"[1] and "Add MT8173 Video Decoder Driver"[2]. MDP driver rely on VPU driver to load, communicate with VPU. Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both have been merged in v4.6-rc1. [1]https://patchwork.kernel.org/patch/9002171/ [2]https://patchwork.kernel.org/patch/9141245/ == Device interface == In principle the driver bases on v4l2 memory-to-memory framework: it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers) and CAPTURE (for destination buffers). OUTPUT and CAPTURE buffer could be MMAP or DMABUF memory type. v4l2-compliance test output: Need the patch "[for,4.7] v4l2-ioctl: fix stupid mistake in cropcap condition"[3] to pass test item Cropping. [3]https://patchwork.linuxtv.org/patch/34374/ # v4l2-compliance -d /dev/image-proc0 v4l2-compliance SHA : 42e5b23fcb64fd0012688b537446df565507b2d7 Driver Info: Driver name : mtk-mdp Card type : 14001000.rdma Bus info : platform:mt8173 Driver version: 4.7.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Compliance test for device /dev/image-proc0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 5 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK test Composing: OK test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 0: Total: 43, Succeeded: 43, Failed: 0, Warnings: 0 Minghsiu Tsai (4): VPU: mediat
[PATCH v2 1/4] VPU: mediatek: Add mdp support
VPU driver add mdp support
Signed-off-by: Minghsiu Tsai
---
drivers/media/platform/mtk-vpu/mtk_vpu.h |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.h
b/drivers/media/platform/mtk-vpu/mtk_vpu.h
index f457479..291ae46 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.h
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.h
@@ -53,6 +53,8 @@ typedef void (*ipi_handler_t) (void *data,
handle H264 video encoder job, and vice versa.
* @IPI_VENC_VP8: The interrupt fro vpu is to notify kernel to
handle VP8 video encoder job,, and vice versa.
+ * @IPI_MDP:The interrupt from vpu is to notify kernel to
+handle MDP (Media Data Path) job, and vice versa.
* @IPI_MAX:The maximum IPI number
*/
@@ -63,6 +65,7 @@ enum ipi_id {
IPI_VDEC_VP9,
IPI_VENC_H264,
IPI_VENC_VP8,
+ IPI_MDP,
IPI_MAX,
};
@@ -71,11 +74,13 @@ enum ipi_id {
*
* @VPU_RST_ENC: encoder reset id
* @VPU_RST_DEC: decoder reset id
+ * @VPU_RST_MDP: MDP (Media Data Path) reset id
* @VPU_RST_MAX: maximum reset id
*/
enum rst_id {
VPU_RST_ENC,
VPU_RST_DEC,
+ VPU_RST_MDP,
VPU_RST_MAX,
};
--
1.7.9.5
[PATCH v2 4/4] arm64: dts: mediatek: Add MDP for MT8173
Add MDP node for MT8173
Signed-off-by: Minghsiu Tsai
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 80 ++
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index a44cfb7..cabbd85 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -26,6 +26,16 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ mdp_rdma0 = &mdp_rdma0;
+ mdp_rdma1 = &mdp_rdma1;
+ mdp_rsz0 = &mdp_rsz0;
+ mdp_rsz1 = &mdp_rsz1;
+ mdp_rsz2 = &mdp_rsz2;
+ mdp_wdma0 = &mdp_wdma0;
+ mdp_wrot0 = &mdp_wrot0;
+ mdp_wrot1 = &mdp_wrot1;
+ };
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -678,6 +688,76 @@
#clock-cells = <1>;
};
+ mdp_rdma0: rdma@14001000 {
+ compatible = "mediatek,mt8173-mdp-rdma",
+"mediatek,mt8173-mdp";
+ reg = <0 0x14001000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+<&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA0>;
+ mediatek,larb = <&larb0>;
+ mediatek,vpu = <&vpu>;
+ };
+
+ mdp_rdma1: rdma@14002000 {
+ compatible = "mediatek,mt8173-mdp-rdma";
+ reg = <0 0x14002000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA1>,
+<&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA1>;
+ mediatek,larb = <&larb4>;
+ };
+
+ mdp_rsz0: rsz@14003000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14003000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ0>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
+
+ mdp_rsz1: rsz@14004000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14004000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ1>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
+
+ mdp_rsz2: rsz@14005000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14005000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ2>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
+
+ mdp_wdma0: wdma@14006000 {
+ compatible = "mediatek,mt8173-mdp-wdma";
+ reg = <0 0x14006000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WDMA>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WDMA>;
+ mediatek,larb = <&larb0>;
+ };
+
+ mdp_wrot0: wrot@14007000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14007000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT0>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT0>;
+ mediatek,larb = <&larb0>;
+ };
+
+ mdp_wrot1: wrot@14008000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14008000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT1>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT1>;
+ mediatek,larb = <&larb4>;
+ };
+
pwm0: pwm@1401e000 {
compatible = "mediatek,mt8173-disp-pwm",
"mediatek,mt6595-disp-pwm";
--
1.7.9.5
[PATCH v2 3/4] media: Add Mediatek MDP Driver
Add MDP driver for MT8173
Signed-off-by: Minghsiu Tsai
---
drivers/media/platform/Kconfig| 16 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/mtk-mdp/Makefile |9 +
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 159
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 72 ++
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 294 ++
drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 240 +
drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h | 126 +++
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 1263 +
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h | 22 +
drivers/media/platform/mtk-mdp/mtk_mdp_regs.c | 153 +++
drivers/media/platform/mtk-mdp/mtk_mdp_regs.h | 31 +
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 145 +++
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h | 41 +
14 files changed, 2573 insertions(+)
create mode 100644 drivers/media/platform/mtk-mdp/Makefile
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.c
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.h
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.c
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.h
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f25344b..4bb874b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -166,6 +166,22 @@ config VIDEO_MEDIATEK_VPU
To compile this driver as a module, choose M here: the
module will be called mtk-vpu.
+config VIDEO_MEDIATEK_MDP
+ tristate "Mediatek MDP driver"
+ depends on MTK_IOMMU || COMPILE_TEST
+ depends on VIDEO_DEV && VIDEO_V4L2
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ select VIDEO_MEDIATEK_VPU
+ default n
+ ---help---
+ It is a v4l2 driver and present in Mediatek MT8173 SoCs.
+ The driver supports for scaling and color space conversion.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-mdp.
+
config VIDEO_MEDIATEK_VCODEC
tristate "Mediatek Video Codec driver"
depends on MTK_IOMMU || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 21771c1..221aace 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -63,3 +63,5 @@ ccflags-y += -I$(srctree)/drivers/media/i2c
obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/
obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/
diff --git a/drivers/media/platform/mtk-mdp/Makefile
b/drivers/media/platform/mtk-mdp/Makefile
new file mode 100644
index 000..f802569
--- /dev/null
+++ b/drivers/media/platform/mtk-mdp/Makefile
@@ -0,0 +1,9 @@
+mtk-mdp-y += mtk_mdp_core.o
+mtk-mdp-y += mtk_mdp_comp.o
+mtk-mdp-y += mtk_mdp_m2m.o
+mtk-mdp-y += mtk_mdp_regs.o
+mtk-mdp-y += mtk_mdp_vpu.o
+
+obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp.o
+
+ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
new file mode 100644
index 000..aa8f9fd
--- /dev/null
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ming Hsiu Tsai
+ *
+ * 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 "mtk_mdp_comp.h"
+
+
+static const char * const mtk_mdp_comp_stem[MTK_MDP_COMP_TYPE_MAX] = {
+ "mdp_rdma",
+ "mdp_rsz",
+ "mdp_wdma",
+ "mdp_wrot",
+};
+
+struct mtk_mdp_comp_match {
+ enum mtk_mdp_comp_type type;
+ int alias_id;
+};
+
+static const struct mtk_mdp_comp_match mtk_mdp_matches[MTK_MDP_COMP_ID_MAX] = {
+ { MTK_MDP_RDMA, 0 },
+ { MTK_MDP_RDMA, 1 },
+ { MTK_MDP_RSZ, 0 },
+ { MTK_MDP_RSZ, 1 },
+ { MTK_MDP_RSZ, 2 },
+ { MTK_MDP_
[PATCH v2 2/4] dt-bindings: Add a binding for Mediatek MDP
Add a DT binding documentation of MDP for the MT8173 SoC
from Mediatek
Signed-off-by: Minghsiu Tsai
---
.../devicetree/bindings/media/mediatek-mdp.txt | 96
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
new file mode 100644
index 000..2dad031
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -0,0 +1,96 @@
+* Mediatek Media Data Path
+
+Media Data Path is used for scaling and color space conversion.
+
+Required properties (all function blocks):
+- compatible: "mediatek,-mdp"
+"mediatek,-mdp-", one of
+"mediatek,-mdp-rdma" - read DMA
+"mediatek,-mdp-rsz" - resizer
+"mediatek,-mdp-wdma" - write DMA
+"mediatek,-mdp-wrot" - write DMA with rotation
+- reg: Physical base address and length of the function block register space
+- clocks: device clocks
+- power-domains: a phandle to the power domain.
+- mediatek,vpu: the node of video processor unit
+
+Required properties (DMA function blocks):
+- compatible: Should be one of
+"mediatek,-mdp-rdma"
+"mediatek,-mdp-wdma"
+"mediatek,-mdp-wrot"
+- iommus: should point to the respective IOMMU block with master port as
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ for details.
+- mediatek,larb: must contain the local arbiters in the current Socs.
+
+Example:
+ mdp_rdma0: rdma@14001000 {
+ compatible = "mediatek,mt8173-mdp-rdma",
+"mediatek,mt8173-mdp";
+ reg = <0 0x14001000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+<&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA0>;
+ mediatek,larb = <&larb0>;
+ mediatek,vpu = <&vpu>;
+ };
+
+ mdp_rdma1: rdma@14002000 {
+ compatible = "mediatek,mt8173-mdp-rdma";
+ reg = <0 0x14002000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA1>,
+<&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA1>;
+ mediatek,larb = <&larb4>;
+ };
+
+ mdp_rsz0: rsz@14003000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14003000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ0>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
+
+ mdp_rsz1: rsz@14004000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14004000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ1>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
+
+ mdp_rsz2: rsz@14005000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14005000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ2>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
+
+ mdp_wdma0: wdma@14006000 {
+ compatible = "mediatek,mt8173-mdp-wdma";
+ reg = <0 0x14006000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WDMA>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WDMA>;
+ mediatek,larb = <&larb0>;
+ };
+
+ mdp_wrot0: wrot@14007000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14007000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT0>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT0>;
+ mediatek,larb = <&larb0>;
+ };
+
+ mdp_wrot1: wrot@14008000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14008000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT1>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT1>;
+ mediatek,larb = <&larb4>;
+ };
--
1.7.9.5
Re: [PATCH] mmc: sdhci-msm: Add set_uhs_signaling() implementation
On 07/20/2016 01:15 PM, Adrian Hunter wrote:
> On 19/07/16 17:52, Georgi Djakov wrote:
>> From: Ritesh Harjani
>>
>> To allow UHS mode to work properly, we need to implement a Qualcomm
>> specific set_uhs_signaling() callback function. This function differs
>> from the sdhci_set_uhs_signaling() in that we need check the clock
>> rate and enable UHS timing only if the frequency is above 100MHz.
>>
>> Signed-off-by: Ritesh Harjani
>> Signed-off-by: Georgi Djakov
>> ---
>>
>> This patch resolves the mmc_select_hs200 timeouts noticed after merging
>> commit a5c1f3e55c99 ("mmc: mmc: do not use CMD13 to get status after
>> speed mode switch")
>>
>> mmc0: mmc_select_hs200 failed, error -110
>> mmc0: error -110 whilst initialising MMC card
>> mmc0: Reset 0x1 never completed.
>> sdhci: === REGISTER DUMP (mmc0)===
>> sdhci: Sys addr: 0x | Version: 0x2e02
>> sdhci: Blk size: 0x4000 | Blk cnt: 0x
>> sdhci: Argument: 0x | Trn mode: 0x
>> sdhci: Present: 0x01f8 | Host ctl: 0x
>> sdhci: Power: 0x | Blk gap: 0x
>> sdhci: Wake-up: 0x | Clock: 0x0003
>> sdhci: Timeout: 0x | Int stat: 0x
>> sdhci: Int enab: 0x | Sig enab: 0x
>> sdhci: AC12 err: 0x | Slot int: 0x
>> sdhci: Caps: 0x322dc8b2 | Caps_1: 0x8007
>> sdhci: Cmd: 0x | Max curr: 0x
>> sdhci: Host ctl2: 0x
>> sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>> sdhci: ===
>
> This information needs to be in the commit message. I think you should add
> a fixes tag too. e.g.
>
> Fixes: a5c1f3e55c99 ("mmc: mmc: do not use CMD13 to get status after...")
>
> Otherwise:
>
> Acked-by: Adrian Hunter
Thanks Adrian!
Ulf, do you want me to resend?
BR,
Georgi
Re: [PATCH v2] HID: use IS_ENABLED() instead of checking for built-in or module
On Jul 21 2016 or thereabouts, Javier Martinez Canillas wrote:
> The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
> built-in or as a module, use that macro instead of open coding the same.
>
> Using the macro makes the code more readable by helping abstract away some
> of the Kconfig built-in and module enable details.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
Reviewed-by: Benjamin Tissoires
Cheers,
Benjamin
>
> Changes in v2:
> - Post correct patch since v1 got mangled by the MTA.
>
> drivers/hid/hid-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 08f53c7fd513..386f31481c06 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2480,7 +2480,7 @@ static const struct hid_device_id hid_ignore_list[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_PANJIT, 0x0004) },
> { HID_USB_DEVICE(USB_VENDOR_ID_PHILIPS,
> USB_DEVICE_ID_PHILIPS_IEEE802154_DONGLE) },
> { HID_USB_DEVICE(USB_VENDOR_ID_POWERCOM, USB_DEVICE_ID_POWERCOM_UPS) },
> -#if defined(CONFIG_MOUSE_SYNAPTICS_USB) ||
> defined(CONFIG_MOUSE_SYNAPTICS_USB_MODULE)
> +#if IS_ENABLED(CONFIG_MOUSE_SYNAPTICS_USB)
> { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_TP) },
> { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS,
> USB_DEVICE_ID_SYNAPTICS_INT_TP) },
> { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_CPAD)
> },
> --
> 2.5.5
>
RE: [PATCH v4 2/2] ACPI / button: Add document for ACPI control method lid device restrictions
Hi, Dmitry
Thanks for the review.
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> Hi Lv,
>
> On Fri, Jul 22, 2016 at 12:24:50AM +, Zheng, Lv wrote:
> > Hi, Dmitry
> >
> >
> > Thanks for the review.
> >
> > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > > Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI
> control
> > > method lid device restrictions
> > >
> > > On Tue, Jul 19, 2016 at 04:11:21PM +0800, Lv Zheng wrote:
> > > > This patch adds documentation for the usage model of the control
> > > method lid
> > > > device.
> > > >
> > > > Signed-off-by: Lv Zheng
> > > > Cc: Dmitry Torokhov
> > > > Cc: Benjamin Tissoires
> > > > Cc: Bastien Nocera:
> > > > Cc: linux-in...@vger.kernel.org
> > > > ---
> > > > Documentation/acpi/acpi-lid.txt | 89
> > > +++
> > > > 1 file changed, 89 insertions(+)
> > > > create mode 100644 Documentation/acpi/acpi-lid.txt
> > > >
> > > > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-
> > > lid.txt
> > > > new file mode 100644
> > > > index 000..2addedc
> > > > --- /dev/null
> > > > +++ b/Documentation/acpi/acpi-lid.txt
> > > > @@ -0,0 +1,89 @@
> > > > +Usage Model of the ACPI Control Method Lid Device
> > > > +
> > > > +Copyright (C) 2016, Intel Corporation
> > > > +Author: Lv Zheng
> > > > +
> > > > +
> > > > +Abstract:
> > > > +
> > > > +Platforms containing lids convey lid state (open/close) to OSPMs
> using
> > > a
> > > > +control method lid device. To implement this, the AML tables issue
> > > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state
> has
> > > > +changed. The _LID control method for the lid device must be
> > > implemented to
> > > > +report the "current" state of the lid as either "opened" or "closed".
> > > > +
> > > > +This document describes the restrictions and the expections of the
> > > Linux
> > > > +ACPI lid device driver.
> > > > +
> > > > +
> > > > +1. Restrictions of the returning value of the _LID control method
> > > > +
> > > > +The _LID control method is described to return the "current" lid
> state.
> > > > +However the word of "current" has ambiguity, many AML tables
> return
> > > the lid
> > >
> > > Can this be fixed in the next ACPI revision?
> > [Lv Zheng]
> > Even this is fixed in the ACPI specification, there are platforms already
> doing this.
> > Especially platforms from Microsoft.
> > So the de-facto standard OS won't care about the change.
> > And we can still see such platforms.
> >
> > Here is an example from Surface 3:
> >
> > DefinitionBlock ("dsdt.aml", "DSDT", 2, "ALASKA", "A M I ", 0x01072009)
> > {
> > Scope (_SB)
> > {
> > Device (PCI0)
> > {
> > Name (_HID, EisaId ("PNP0A08")) // _HID: Hardware ID
> > Name (_CID, EisaId ("PNP0A03")) // _CID: Compatible ID
> > Device (SPI1)
> > {
> > Name (_HID, "8086228E") // _HID: Hardware ID
> > Device (NTRG)
> > {
> > Name (_HID, "MSHW0037") // _HID: Hardware ID
> > }
> > }
> > }
> >
> > Device (LID)
> > {
> > Name (_HID, EisaId ("PNP0C0D"))
> > Name (LIDB, Zero)
>
> Start with lid closed? In any case might be wrong.
[Lv Zheng]
And we validated with qemu that during boot, Windows7 evaluates _LID once but
doesn't get suspended because of this value.
So we think Windows only suspends against "notification" not _LID evaluation
result.
>
> > Method (_LID, 0, NotSerialized)
> > {
> > Return (LIDB)
>
> So "_LID" returns the last state read by "_EC4". "_EC4" is
> edge-triggered and will be evaluated every time gpio changes state.
[Lv Zheng]
Right.
>
> > }
> > }
> >
> > Device (GPO0)
> > {
> > Name (_HID, "INT33FF") // _HID: Hardware ID
> > OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
> > Field (GPOR, ByteAcc, NoLock, Preserve)
> > {
> > Connection (
> > GpioIo (Shared, PullNone, 0x, 0x,
> > IoRestrictionNone,
> > "\\_SB.GPO0", 0x00, ResourceConsumer, ,
> > )
> > { // Pin list
> > 0x004C
> > }
> > ),
> > HELD, 1
>
> Is it possible to read state of this GPIO from userspace on startup to
> correct the initial state?
[Lv Zheng]
I think Benjamin has a proposal of fixing this in GPIO driver.
>
> > }
> > Method (_E4C, 0, Serialized)
> > {
> > If (LEqual(HELD, One))
> > {
> > Store(One, ^^LID.LIDB)
>
[RFC PATCH v1 1/2] Documentation: arm64: Add Hisilicon HiP05/06/07 Sysctrl and Djtag dts bindings
First, add Hisilicon HiP05/06/07 CPU and ALGSUB system controller dts
bindings. Then, add Hisilicon Djtag dts binding.
Signed-off-by: Tan Xiaojun
---
.../bindings/arm/hisilicon/hisilicon.txt | 98
1 file changed, 98 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 83fe816..82a22ed 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -249,3 +249,101 @@ Required Properties:
[1]: bootwrapper size
[2]: relocation physical address
[3]: relocation size
+
+---
+Hisilicon HiP05 CPU system controller
+Required properties:
+- compatible : "hisilicon,hip05-sysctrl", "syscon", "simple-mfd";
+- reg : Register address and size
+- djtag :
+ - compatible : "hisilicon,hip05-cpu-djtag-v1"
+ - syscon : which sysctrl node
+
+Hisilicon HiP06 CPU system controller
+Required properties:
+- compatible : "hisilicon,hip06-sysctrl", "syscon", "simple-mfd";
+- reg : Register address and size
+- djtag :
+ - compatible : "hisilicon,hip06-cpu-djtag-v1"
+ - syscon : which sysctrl node
+
+Hisilicon HiP07 CPU system controller
+Required properties:
+- compatible : "hisilicon,hip07-sysctrl", "syscon", "simple-mfd";
+- reg : Register address and size
+- djtag :
+ - compatible : "hisilicon,hip07-cpu-djtag-v2"
+ - syscon : which sysctrl node
+
+The Hisilicon HiP05/06/07 CPU system controller is in CPU die of SoC. It is
+used to control system operation mode, control system operating status and
+manage some important modules (such as clock, reset, soft reset, secure
+debugger, etc.). We can also configure some functions of the peripheral
+devices and query their status by it.
+
+The Hisilicon Djtag in CPU die is an independent module which connects with
+some modules in the SoC by Debug Bus. This module can be configured to access
+the registers of connecting modules (like L3 cache) during real time debugging
+by sysctrl.
+
+Example:
+ /* for Hisilicon HiP05 sysctrl */
+ hip05-sysctrl: hip05-sysctrl@8001 {
+ compatible = "hisilicon,hip05-sysctrl", "syscon", "simple-mfd";
+ reg = <0x8001 0x1>;
+
+ djtag0: djtag@0 {
+ compatible = "hisilicon,hip05-cpu-djtag-v1";
+ syscon = <&hip05-sysctrl>;
+ };
+ };
+
+ /* for Hisilicon HiP05 l3 cache maybe set like below */
+ llc0: llc@0 {
+ compatible = "hisilicon,hip05-llc";
+ djtag = <&djtag0>;
+ };
+
+---
+Hisilicon HiP05 ALGSUB system controller
+Required properties:
+- compatible : "hisilicon,hip05-alg-sysctrl", "syscon", "simple-mfd";
+- reg : Register address and size
+- djtag :
+ - compatible : "hisilicon,hip05-io-djtag-v1"
+ - syscon : which sysctrl node
+
+Hisilicon HiP06 ALGSUB system controller
+Required properties:
+- compatible : "hisilicon,hip06-alg-sysctrl", "syscon", "simple-mfd";
+- reg : Register address and size
+- djtag :
+ - compatible : "hisilicon,hip06-io-djtag-v2"
+ - syscon : which sysctrl node
+
+Hisilicon HiP07 ALGSUB system controller
+Required properties:
+- compatible : "hisilicon,hip07-alg-sysctrl", "syscon", "simple-mfd";
+- reg : Register address and size
+- djtag :
+ - compatible : "hisilicon,hip07-io-djtag-v2"
+ - syscon : which sysctrl node
+
+The Hisilicon HiP05/06/07 ALGSUB system controller is in IO die of SoC. It
+has a similar function as the Hisilicon HiP05/06/07 CPU system controller
+in CPU die and it manage default modules, like RSA, etc.
+
+The Hisilicon Djtag in IO die has a similar function as the one in CPU die.
+
+Example:
+ /* for Hisilicon HiP05 alg subctrl */
+ hip05-alg-sysctrl: hip05-alg-sysctrl@d000 {
+ compatible = "hisilicon,hip05-alg-sysctrl", "syscon",
"simple-mfd";
+ reg = <0xd000 0x1>;
+
+ djtag0: djtag@0 {
+ compatible = "hisilicon,hip05-io-djtag-v1";
+ syscon = <&hip05-alg-sysctrl>;
+ };
+ };
+
--
1.7.9.5
[RFC PATCH v1 2/2] drivers: soc: Add support for Hisilicon Djtag driver
The Hisilicon Djtag is an independent module which connects with some modules
in the SoC by Debug Bus. This module can be configured to access the registers
of connecting modules (like L3 cache) during real time debugging.
This patch add the driver of Hisilicon Djtag.
Signed-off-by: Tan Xiaojun
---
drivers/soc/Kconfig |1 +
drivers/soc/Makefile|1 +
drivers/soc/hisilicon/Kconfig | 12 ++
drivers/soc/hisilicon/Makefile |1 +
drivers/soc/hisilicon/djtag.c | 373 +++
include/linux/soc/hisilicon/djtag.h | 18 ++
6 files changed, 406 insertions(+)
create mode 100644 drivers/soc/hisilicon/Kconfig
create mode 100644 drivers/soc/hisilicon/Makefile
create mode 100644 drivers/soc/hisilicon/djtag.c
create mode 100644 include/linux/soc/hisilicon/djtag.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..f5982ec 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -3,6 +3,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/hisilicon/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 380230f..373449d 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_SOC_BRCMSTB) += brcmstb/
obj-$(CONFIG_ARCH_DOVE)+= dove/
obj-$(CONFIG_MACH_DOVE)+= dove/
obj-y += fsl/
+obj-$(CONFIG_ARCH_HISI)+= hisilicon/
obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
obj-$(CONFIG_ARCH_QCOM)+= qcom/
obj-$(CONFIG_ARCH_RENESAS) += renesas/
diff --git a/drivers/soc/hisilicon/Kconfig b/drivers/soc/hisilicon/Kconfig
new file mode 100644
index 000..3644aab
--- /dev/null
+++ b/drivers/soc/hisilicon/Kconfig
@@ -0,0 +1,12 @@
+#
+# Hisilicon SoC drivers
+#
+config HISI_DJTAG
+ bool "Hisilicon Djtag Support"
+ depends on ARCH_HISI || COMPILE_TEST
+ help
+ Say y here to enable the Hisilicon Djtag support. It is an
+ independent module which connects with some modules in the
+ SoC by Debug Bus. This module can be configured to access
+ the registers of connecting modules during real time
+ debugging.
diff --git a/drivers/soc/hisilicon/Makefile b/drivers/soc/hisilicon/Makefile
new file mode 100644
index 000..35a7b4b
--- /dev/null
+++ b/drivers/soc/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_HISI_DJTAG) += djtag.o
diff --git a/drivers/soc/hisilicon/djtag.c b/drivers/soc/hisilicon/djtag.c
new file mode 100644
index 000..41e11ed
--- /dev/null
+++ b/drivers/soc/hisilicon/djtag.c
@@ -0,0 +1,373 @@
+/*
+ * Driver for Hisilicon Djtag r/w via System Controller.
+ *
+ * Copyright (C) 2016 Hisilicon Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define SC_DJTAG_TIMEOUT 10 /* 100ms */
+
+/* for djtag v1 */
+#define SC_DJTAG_MSTR_EN 0x6800
+#define DJTAG_NOR_CFG BIT(1) /* accelerate R,W */
+#define DJTAG_MSTR_EN BIT(0)
+#define SC_DJTAG_MSTR_START_EN 0x6804
+#define DJTAG_MSTR_START_EN0x1
+#define SC_DJTAG_DEBUG_MODULE_SEL 0x680c
+#define SC_DJTAG_MSTR_WR 0x6810
+#define DJTAG_MSTR_W 0x1
+#define DJTAG_MSTR_R 0x0
+#define SC_DJTAG_CHAIN_UNIT_CFG_EN 0x6814
+#define CHAIN_UNIT_CFG_EN 0x
+#define SC_DJTAG_MSTR_ADDR 0x6818
+#define SC_DJTAG_MSTR_DATA 0x681c
+#define SC_DJTAG_RD_DATA_BASE 0xe800
+
+/* for djtag v2 */
+#define SC_DJTAG_SEC_ACC_EN_EX 0xd800
+#define DJTAG_SEC_ACC_EN_EX0x1
+#define SC_DJTAG_MSTR_CFG_EX 0xd818
+#define DJTAG_MSTR_RW_SHIFT_EX 29
+#define DJTAG_MSTR_RD_EX (0x0 << DJTAG_MSTR_RW_SHIFT_EX)
+#define DJTAG_MSTR_WR_EX (0x1 << DJTAG_MSTR_RW_SHIFT_EX)
+#define DEBUG_MODULE_SEL_SHIFT_EX 16
+#define CHAIN_UNIT_CFG_EN_EX 0x
+#define SC_DJTAG_MSTR_ADDR_EX 0xd810
+#define SC_DJTAG_MSTR_DATA_EX 0xd814
+#define SC_DJTAG_MSTR_START_EN_EX 0xd81c
+#define DJTAG_MSTR_START_EN_EX 0x1
+#define SC_DJTAG_RD_DATA_BASE_EX 0xe800
+#define SC_DJTAG_OP_ST_EX 0xe828
+#define DJTAG_OP_DONE_EX BIT(8)
+
+static LIST_HEAD(djtag_list);
+
+struct djtag_data {
+ spinlock_t lock;
+ struct list_head list;
+ struct regm
[RFC PATCH v1 0/2] Add Hisilicon Djtag driver
Tan Xiaojun (2): Documentation: arm64: Add Hisilicon HiP05/06/07 Sysctrl and Djtag dts bindings drivers: soc: Add support for Hisilicon Djtag driver .../bindings/arm/hisilicon/hisilicon.txt | 98 + drivers/soc/Kconfig|1 + drivers/soc/Makefile |1 + drivers/soc/hisilicon/Kconfig | 12 + drivers/soc/hisilicon/Makefile |1 + drivers/soc/hisilicon/djtag.c | 373 include/linux/soc/hisilicon/djtag.h| 18 + 7 files changed, 504 insertions(+) create mode 100644 drivers/soc/hisilicon/Kconfig create mode 100644 drivers/soc/hisilicon/Makefile create mode 100644 drivers/soc/hisilicon/djtag.c create mode 100644 include/linux/soc/hisilicon/djtag.h -- 1.7.9.5
Re: [PATCH 4/4] nvmx: check for shadow vmcs check on entry
> Paolo Bonzini writes: > > > On 21/07/2016 00:25, Bandan Das wrote: > >> vmentry should check whether the vmcs provided by > >> the guest hypervisor is a shadow vmcs and fail. > > > > How can this happen, since vmptrld checks the revision_id as you said > > below? > > This is more of a change that adheres to the spec > (26.1 Basic VM-Entry Checks); the failure path > is slightly different compared to vmptrld though. > It's small and harmless but I am ok if you prefer dropping it. Do you mean that this could happen if the VMCS is modified by L1 after VMPTRLD? That makes sense, but with David Matlack's change to cache the VMCS it wouldn't be possible to trigger it anymore. Paolo
[PATCH] GPU-DRM-GMA500: Delete unnecessary checks before two function calls
From: Markus Elfring
Date: Fri, 22 Jul 2016 10:30:30 +0200
The functions pci_dev_put() and psb_intel_i2c_destroy() test whether
their argument is NULL and then return immediately.
Thus the tests around their calls are not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +--
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 +++--
drivers/gpu/drm/gma500/psb_drv.c| 6 ++
drivers/gpu/drm/gma500/psb_intel_lvds.c | 9 +++--
4 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index 28f9d90..563f193 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -246,8 +246,7 @@ static void cdv_hdmi_destroy(struct drm_connector
*connector)
{
struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
- if (gma_encoder->i2c_bus)
- psb_intel_i2c_destroy(gma_encoder->i2c_bus);
+ psb_intel_i2c_destroy(gma_encoder->i2c_bus);
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
kfree(connector);
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 813ef23..38dc890 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -444,8 +444,7 @@ static void cdv_intel_lvds_destroy(struct drm_connector
*connector)
{
struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
- if (gma_encoder->i2c_bus)
- psb_intel_i2c_destroy(gma_encoder->i2c_bus);
+ psb_intel_i2c_destroy(gma_encoder->i2c_bus);
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
kfree(connector);
@@ -780,12 +779,10 @@ out:
failed_find:
mutex_unlock(&dev->mode_config.mutex);
printk(KERN_ERR "Failed find\n");
- if (gma_encoder->ddc_bus)
- psb_intel_i2c_destroy(gma_encoder->ddc_bus);
+ psb_intel_i2c_destroy(gma_encoder->ddc_bus);
failed_ddc:
printk(KERN_ERR "Failed DDC\n");
- if (gma_encoder->i2c_bus)
- psb_intel_i2c_destroy(gma_encoder->i2c_bus);
+ psb_intel_i2c_destroy(gma_encoder->i2c_bus);
failed_blc_i2c:
printk(KERN_ERR "Failed BLC\n");
drm_encoder_cleanup(encoder);
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 82b8ce4..50eb944f 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -210,10 +210,8 @@ static int psb_driver_unload(struct drm_device *dev)
iounmap(dev_priv->aux_reg);
dev_priv->aux_reg = NULL;
}
- if (dev_priv->aux_pdev)
- pci_dev_put(dev_priv->aux_pdev);
- if (dev_priv->lpc_pdev)
- pci_dev_put(dev_priv->lpc_pdev);
+ pci_dev_put(dev_priv->aux_pdev);
+ pci_dev_put(dev_priv->lpc_pdev);
/* Destroy VBT data */
psb_intel_destroy_bios(dev);
diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index b1b9331..e55733c 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ -561,8 +561,7 @@ void psb_intel_lvds_destroy(struct drm_connector *connector)
struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
struct psb_intel_lvds_priv *lvds_priv = gma_encoder->dev_priv;
- if (lvds_priv->ddc_bus)
- psb_intel_i2c_destroy(lvds_priv->ddc_bus);
+ psb_intel_i2c_destroy(lvds_priv->ddc_bus);
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
kfree(connector);
@@ -835,11 +834,9 @@ out:
failed_find:
mutex_unlock(&dev->mode_config.mutex);
- if (lvds_priv->ddc_bus)
- psb_intel_i2c_destroy(lvds_priv->ddc_bus);
+ psb_intel_i2c_destroy(lvds_priv->ddc_bus);
failed_ddc:
- if (lvds_priv->i2c_bus)
- psb_intel_i2c_destroy(lvds_priv->i2c_bus);
+ psb_intel_i2c_destroy(lvds_priv->i2c_bus);
failed_blc_i2c:
drm_encoder_cleanup(encoder);
drm_connector_cleanup(connector);
--
2.9.2
Re: [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks
On Mon, Jul 18 2016, Michal Hocko wrote: > From: Michal Hocko > > Mikulas has reported that a swap backed by dm-crypt doesn't work > properly because the swapout cannot make a sufficient forward progress > as the writeout path depends on dm_crypt worker which has to allocate > memory to perform the encryption. In order to guarantee a forward > progress it relies on the mempool allocator. mempool_alloc(), however, > prefers to use the underlying (usually page) allocator before it grabs > objects from the pool. Such an allocation can dive into the memory > reclaim and consequently to throttle_vm_writeout. That's just broken. I used to think mempool should always use the pre-allocated reserves first. That is surely the most logical course of action. Otherwise that memory is just sitting there doing nothing useful. I spoke to Nick Piggin about this some years ago and he pointed out that the kmalloc allocation paths are much better optimized for low overhead when there is plenty of memory. They can just pluck a free block of a per-CPU list without taking any locks. By contrast, accessing the preallocated pool always requires a spinlock. So it makes lots of sense to prefer the underlying allocator if it can provide a quick response. If it cannot, the sensible thing is to use the pool, or wait for the pool to be replenished. So the allocator should never wait at all, never enter reclaim, never throttle. Looking at the current code, __GFP_DIRECT_RECLAIM is disabled the first time through, but if the pool is empty, direct-reclaim is allowed on the next attempt. Presumably this is where the throttling comes in ?? I suspect that it really shouldn't do that. It should leave kswapd to do reclaim (so __GFP_KSWAPD_RECLAIM is appropriate) and only wait in mempool_alloc where pool->wait can wake it up. If I'm following the code properly, the stack trace below can only happen if the first pool->alloc() attempt, with direct-reclaim disabled, fails and the pool is empty, so mempool_alloc() calls prepare_to_wait() and io_schedule_timeout(). I suspect the timeout *doesn't* fire (5 seconds is along time) so it gets woken up when there is something in the pool. It then loops around and tries pool->alloc() again, even though there is something in the pool. This might be justified if that ->alloc would never block, but obviously it does. I would very strongly recommend just changing mempool_alloc() to permanently mask out __GFP_DIRECT_RECLAIM. Quite separately I don't think PF_LESS_THROTTLE is at all appropriate. It is "LESS" throttle, not "NO" throttle, but you have made throttle_vm_writeout never throttle PF_LESS_THROTTLE threads. The purpose of that flag is to allow a thread to dirty a page-cache page as part of cleaning another page-cache page. So it makes sense for loop and sometimes for nfsd. It would make sense for dm-crypt if it was putting the encrypted version in the page cache. But if dm-crypt is just allocating a transient page (which I think it is), then a mempool should be sufficient (and we should make sure it is sufficient) and access to an extra 10% (or whatever) of the page cache isn't justified. Thanks, NeilBrown If there are too many > dirty or pages under writeback it will get throttled even though it is > in fact a flusher to clear pending pages. > > [ 345.352536] kworker/u4:0D 88003df7f438 10488 6 2 > 0x > [ 345.352536] Workqueue: kcryptd kcryptd_crypt [dm_crypt] > [ 345.352536] 88003df7f438 88003e5d0380 88003e5d0380 > 88003e5d8e80 > [ 345.352536] 88003dfb3240 88003df73240 88003df8 > 88003df7f470 > [ 345.352536] 88003e5d0380 88003e5d0380 88003df7f828 > 88003df7f450 > [ 345.352536] Call Trace: > [ 345.352536] [] schedule+0x3c/0x90 > [ 345.352536] [] schedule_timeout+0x1d8/0x360 > [ 345.352536] [] ? detach_if_pending+0x1c0/0x1c0 > [ 345.352536] [] ? ktime_get+0xb3/0x150 > [ 345.352536] [] ? __delayacct_blkio_start+0x1f/0x30 > [ 345.352536] [] io_schedule_timeout+0xa4/0x110 > [ 345.352536] [] congestion_wait+0x86/0x1f0 > [ 345.352536] [] ? prepare_to_wait_event+0xf0/0xf0 > [ 345.352536] [] throttle_vm_writeout+0x44/0xd0 > [ 345.352536] [] shrink_zone_memcg+0x613/0x720 > [ 345.352536] [] shrink_zone+0xe0/0x300 > [ 345.352536] [] do_try_to_free_pages+0x1ad/0x450 > [ 345.352536] [] try_to_free_pages+0xef/0x300 > [ 345.352536] [] __alloc_pages_nodemask+0x879/0x1210 > [ 345.352536] [] ? sched_clock_cpu+0x90/0xc0 > [ 345.352536] [] alloc_pages_current+0xa1/0x1f0 > [ 345.352536] [] ? new_slab+0x3f5/0x6a0 > [ 345.352536] [] new_slab+0x2d7/0x6a0 > [ 345.352536] [] ? sched_clock_local+0x17/0x80 > [ 345.352536] [] ___slab_alloc+0x3fb/0x5c0 > [ 345.352536] [] ? mempool_alloc_slab+0x1d/0x30 > [ 345.352536] [] ? sched_clock_local+0x17/0x80 > [ 345.352536] [] ? mempool_alloc_slab+0x1d/0x30 > [ 345.352536] [] __slab_alloc+0x51/0x90 > [ 345.352536] [] ? mempool_allo
RE: [PATCH v4 2/2] ACPI / button: Add document for ACPI control method lid device restrictions
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> On Fri, Jul 22, 2016 at 6:37 AM, Dmitry Torokhov
> wrote:
> > Hi Lv,
> >
> > On Fri, Jul 22, 2016 at 12:24:50AM +, Zheng, Lv wrote:
> >> Hi, Dmitry
> >>
> >>
> >> Thanks for the review.
> >>
> >> > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> >> > Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI
> control
> >> > method lid device restrictions
> >> >
> >> > On Tue, Jul 19, 2016 at 04:11:21PM +0800, Lv Zheng wrote:
> >> > > This patch adds documentation for the usage model of the control
> >> > method lid
> >> > > device.
> >> > >
> >> > > Signed-off-by: Lv Zheng
> >> > > Cc: Dmitry Torokhov
> >> > > Cc: Benjamin Tissoires
> >> > > Cc: Bastien Nocera:
> >> > > Cc: linux-in...@vger.kernel.org
> >> > > ---
> >> > > Documentation/acpi/acpi-lid.txt | 89
> >> > +++
> >> > > 1 file changed, 89 insertions(+)
> >> > > create mode 100644 Documentation/acpi/acpi-lid.txt
> >> > >
> >> > > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-
> >> > lid.txt
> >> > > new file mode 100644
> >> > > index 000..2addedc
> >> > > --- /dev/null
> >> > > +++ b/Documentation/acpi/acpi-lid.txt
> >> > > @@ -0,0 +1,89 @@
> >> > > +Usage Model of the ACPI Control Method Lid Device
> >> > > +
> >> > > +Copyright (C) 2016, Intel Corporation
> >> > > +Author: Lv Zheng
> >> > > +
> >> > > +
> >> > > +Abstract:
> >> > > +
> >> > > +Platforms containing lids convey lid state (open/close) to OSPMs
> using
> >> > a
> >> > > +control method lid device. To implement this, the AML tables issue
> >> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> state has
> >> > > +changed. The _LID control method for the lid device must be
> >> > implemented to
> >> > > +report the "current" state of the lid as either "opened" or "closed".
> >> > > +
> >> > > +This document describes the restrictions and the expections of the
> >> > Linux
> >> > > +ACPI lid device driver.
> >> > > +
> >> > > +
> >> > > +1. Restrictions of the returning value of the _LID control method
> >> > > +
> >> > > +The _LID control method is described to return the "current" lid
> state.
> >> > > +However the word of "current" has ambiguity, many AML tables
> return
> >> > the lid
> >> >
> >> > Can this be fixed in the next ACPI revision?
> >> [Lv Zheng]
> >> Even this is fixed in the ACPI specification, there are platforms already
> doing this.
> >> Especially platforms from Microsoft.
> >> So the de-facto standard OS won't care about the change.
> >> And we can still see such platforms.
> >>
> >> Here is an example from Surface 3:
> >>
> >> DefinitionBlock ("dsdt.aml", "DSDT", 2, "ALASKA", "A M I ", 0x01072009)
> >> {
> >> Scope (_SB)
> >> {
> >> Device (PCI0)
> >> {
> >> Name (_HID, EisaId ("PNP0A08")) // _HID: Hardware ID
> >> Name (_CID, EisaId ("PNP0A03")) // _CID: Compatible ID
> >> Device (SPI1)
> >> {
> >> Name (_HID, "8086228E") // _HID: Hardware ID
> >> Device (NTRG)
> >> {
> >> Name (_HID, "MSHW0037") // _HID: Hardware ID
> >> }
> >> }
> >> }
> >>
> >> Device (LID)
> >> {
> >> Name (_HID, EisaId ("PNP0C0D"))
> >> Name (LIDB, Zero)
> >
> > Start with lid closed? In any case might be wrong.
>
> Actually the initial value doesn't matter if the gpiochip triggers the
> _EC4 at boot, which it should
> (https://github.com/hadess/fedora-surface3-
> kernel/commit/13200f81662c1c0b58137947c3e6c000fe62a2ba,
> still unsubmitted)
>
> >
> >> Method (_LID, 0, NotSerialized)
> >> {
> >> Return (LIDB)
> >
> > So "_LID" returns the last state read by "_EC4". "_EC4" is
> > edge-triggered and will be evaluated every time gpio changes state.
>
> That's assuming the change happens while the system is on. If you go
> into suspend by closing the LID. Open it while on suspend and then hit
> the power button given that the system doesn't wake up when the lid is
> opened, the edge change was made while the system is asleep, and we
> are screwed (from an ACPI point of view). See my next comment for a
> solution.
>
[Lv Zheng]
I actually not sure if polling can fix all issues.
For example.
If a platform reporting "close" after resuming.
Then polling _LID will always return "close".
And the userspace can still get the "close" not "open".
So it seems polling is not working for such platforms (cached value, initial
close).
Surface 3 is not the only platform caching an initial close value.
There are 2 traditional platforms listed in the patch description.
> >
> >> }
> >> }
> >>
> >> Device (GPO0)
> >> {
> >>
Re: RFC: silencing kvm unimplemented msr spew.
> On Tue, Jul 19, 2016 at 04:24:31PM -0400, Bandan Das wrote:
>
> > Heh, actually after speaking about this to Paolo a while back, I had this
> > sleeping
> > in my local branch for a while. Same as what you suggested (without the
> > ratelimiting)
> >
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index def97b3..c6e6f64 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -4952,7 +4952,7 @@ void kvm_mmu_invalidate_mmio_sptes(struct kvm *kvm,
> > struct kvm_memslots *slots)
> > * zap all shadow pages.
> > */
> > if (unlikely((slots->generation & MMIO_GEN_MASK) == 0)) {
> > - printk_ratelimited(KERN_DEBUG "kvm: zapping shadow pages
> > for mmio generation wraparound\n");
> > + kvm_debug("zapping shadow pages for mmio generation
> > wraparound\n");
> > kvm_mmu_invalidate_zap_all_pages(kvm);
> > }
> > }
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 7da5dd2..02d09f9 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -2229,7 +2229,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
> > msr_data *msr_info)
> > if (kvm_pmu_is_valid_msr(vcpu, msr))
> > return kvm_pmu_set_msr(vcpu, msr_info);
> > if (!ignore_msrs) {
> > - vcpu_unimpl(vcpu, "unhandled wrmsr: 0x%x data
> > %llx\n",
> > + vcpu_debug(vcpu, "unhandled wrmsr: 0x%x data
> > %llx\n",
> > msr, data);
> > return 1;
> > } else {
> > @@ -2441,7 +2441,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct
> > msr_data *msr_info)
> > if (kvm_pmu_is_valid_msr(vcpu, msr_info->index))
> > return kvm_pmu_get_msr(vcpu, msr_info->index,
> > &msr_info->data);
> > if (!ignore_msrs) {
> > - vcpu_unimpl(vcpu, "unhandled rdmsr: 0x%x\n",
> msr_info->index);
> > + vcpu_debug(vcpu, "unhandled rdmsr: 0x%x\n",
> msr_info->index);
> > return 1;
> > } else {
> > vcpu_unimpl(vcpu, "ignored rdmsr: 0x%x\n",
> > msr_info->index);
> >
> > I had the same reasoning regarding dynamic debugging which I think is
> > enabled by default on most builds anyway.
>
> Yeah, that's close. Though I would have done the same for the other side of
> the if's too.
> (Still evaluating which mode is actually more useful for us).
For Linux guests, there should be no reason to use ignore_msrs. Linux
is pretty resilient to "missing" MSRs (especially because they are already
ignored if the kernel is compiled with CONFIG_PARAVIRT=y!). The option is
really more for Windows, because it doesn't have anything like CONFIG_PARAVIRT
and because drivers are sometimes less vetted (and sometimes do RDMSR
themselves for whatever reason). In general we try to look at beta versions
of Windows and add any required MSRs well before the final release date,
but if you're using old kernels you might be stuck with ignore_msrs.
IOW, if there was a really common reason to use ignore_msrs it would be
the default. ;)
> Paolo, would you prefer this, or the other approach you already ack'd ?
I think I prefer the other, because vcpu_debug is not ratelimited.
If the guest can trigger a printk it should always be ratelimited.
Paolo
[lkp] [writeback] 9340837195: INFO: suspicious RCU usage. ]
FYI, we noticed the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
wb-buf-throttle
commit 93408371951a8c076c58a532e3e7e14969e5e015 ("writeback: throttle buffered
writeback")
in testcase: boot
on test machine: 1 threads qemu-system-x86_64 -enable-kvm -cpu SandyBridge with
320M memory
caused below changes:
+---+++
| | fd9e8f2822 | 9340837195 |
+---+++
| boot_successes| 6 | 4 |
| boot_failures | 0 | 30 |
| INFO:suspicious_RCU_usage | 0 | 30 |
| backtrace:do_mount| 0 | 28 |
| backtrace:SyS_mount | 0 | 28 |
| timestamp.last| 0 | 3676.860562003 |
| backtrace:do_sys_open | 0 | 2 |
| backtrace:SyS_open| 0 | 2 |
+---+++
[ 19.168560] input: ImExPS/2 BYD TouchPad as
/devices/platform/i8042/serio1/input/input3
[ 21.175977]
[ 21.177141] ===
[ 21.178757] [ INFO: suspicious RCU usage. ]
[ 21.180364] 4.7.0-rc7-8-g9340837 #246 Not tainted
[ 21.182098] ---
[ 21.183728] include/linux/cgroup.h:434 suspicious rcu_dereference_check()
usage!
[ 21.186972]
[ 21.186972] other info that might help us debug this:
[ 21.186972]
[ 21.190687]
[ 21.190687] rcu_scheduler_active = 1, debug_locks = 0
[ 21.193455] 4 locks held by mount/2419:
[ 21.195030] #0: (&bdev->bd_mutex){+.+.+.}, at: []
__blkdev_get+0x96/0x3d0
[ 21.198794] #1: (floppy_mutex){+.+.+.}, at: []
floppy_open+0x38/0x303
[ 21.202444] #2: (open_lock){+.+.+.}, at: []
floppy_open+0x46/0x303
[ 21.205831] #3: (floppy_lock){..}, at: []
cfq_set_request+0x5c/0x32c
[ 21.209547]
[ 21.209547] stack backtrace:
[ 21.211888] CPU: 0 PID: 2419 Comm: mount Not tainted
4.7.0-rc7-8-g9340837 #246
[ 21.214848] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[ 21.218069] 88000c7cb778 8155bee7
88000b038040
[ 21.221473] 0001 88000c7cb7a8 810e8aff
88000b88c008
[ 21.224926] 88000b038040 0003 88000d0a8008
88000c7cb868
[ 21.228228] Call Trace:
[ 21.229486] [] dump_stack+0x86/0xc0
[ 21.231276] [] lockdep_rcu_suspicious+0xf7/0x100
[ 21.233302] [] check_blkcg_changed+0x202/0x402
[ 21.235246] [] ? lock_acquire+0x188/0x223
[ 21.237097] [] ? cfq_set_request+0x5c/0x32c
[ 21.238987] [] cfq_set_request+0xcf/0x32c
[ 21.240916] [] ? _raw_spin_unlock_irq+0x2c/0x3d
[ 21.242879] [] ? trace_hardirqs_on_caller+0x17e/0x19a
[ 21.244951] [] ? trace_hardirqs_on+0xd/0xf
[ 21.246855] [] ? _raw_spin_unlock_irq+0x2c/0x3d
[ 21.248886] [] ? ioc_create_icq+0x15b/0x172
[ 21.250814] [] elv_set_request+0x1c/0x21
[ 21.252668] [] get_request+0x54d/0xa5d
[ 21.254488] [] ? wake_up_bit+0x2a/0x2a
[ 21.256319] [] blk_queue_bio+0x1ba/0x4dc
[ 21.258096] [] generic_make_request+0xbd/0x15b
[ 21.260066] [] submit_bio+0x108/0x113
[ 21.261895] [] __floppy_read_block_0+0xcb/0x116
[ 21.263905] [] ? mark_held_locks+0x5e/0x74
[ 21.265831] [] ? _raw_spin_unlock_irqrestore+0x48/0x5e
[ 21.267931] [] ? trace_hardirqs_on_caller+0x17e/0x19a
[ 21.270019] [] ? floppy_resume+0x3f/0x3f
[ 21.271937] [] floppy_revalidate+0x1a9/0x1bc
[ 21.273925] [] check_disk_change+0x52/0x5e
[ 21.275815] [] floppy_open+0x27b/0x303
[ 21.277644] [] __blkdev_get+0x108/0x3d0
[ 21.279503] [] ? blkdev_get+0x2da/0x2fe
[ 21.284992] [] blkdev_get+0x1c7/0x2fe
[ 21.286812] [] ? mntput_no_expire+0xdd/0x350
[ 21.288780] [] ? mntput+0x2d/0x2f
[ 21.290542] [] ? path_put+0x1e/0x21
[ 21.292319] [] blkdev_get_by_path+0x33/0x69
[ 21.294226] [] mount_bdev+0x48/0x197
[ 21.296766] [] ? ext4_calculate_overhead+0x2bd/0x2bd
[ 21.298783] [] ext4_mount+0x15/0x17
[ 21.300537] [] mount_fs+0x14/0x8d
[ 21.302228] [] vfs_kern_mount+0x6b/0x133
[ 21.304137] [] do_mount+0xa4d/0xb53
[ 21.305915] [] ? strndup_user+0x3f/0x6b
[ 21.307738] [] SyS_mount+0x77/0x9f
[ 21.309470] [] entry_SYSCALL_64_fastpath+0x1f/0xbd
[ 21.376317] blk_update_request: I/O error, dev fd0, sector 0
FYI, raw QEMU command line is:
qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel
/pkg/linux/x86_64-nfsroot/gcc-6/93408371951a8c076c58a532e3e7e14969e5e015/vmlinuz-4.7.0-rc7-8-g9340837
-append 'root=/dev/ram0 user=lkp
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-32/rand_boot-1-yocto-minimal-x86_64.cgz-93408371951a8c076c58a532e3e7e14969e5e015-20160722-42999-h2wrj2-0.yaml
ARCH=x86_64 kconfig=x86_64-nfsroot branch=block/w
[PATCH] perf probe: fix kconfig symbol names for kprobes and uprobes
These symbols both don't have a trailing 'S'.
Signed-off-by: Uwe Kleine-König
---
tools/perf/util/probe-file.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 9aed9c332da6..351268ffdd94 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -38,9 +38,9 @@ static void print_open_warning(int err, bool uprobe)
const char *config;
if (uprobe)
- config = "CONFIG_UPROBE_EVENTS";
+ config = "CONFIG_UPROBE_EVENT";
else
- config = "CONFIG_KPROBE_EVENTS";
+ config = "CONFIG_KPROBE_EVENT";
pr_warning("%cprobe_events file does not exist"
" - please rebuild kernel with %s.\n",
@@ -59,8 +59,8 @@ static void print_both_open_warning(int kerr, int uerr)
if (kerr == -ENOTSUP && uerr == -ENOTSUP)
pr_warning("Tracefs or debugfs is not mounted.\n");
else if (kerr == -ENOENT && uerr == -ENOENT)
- pr_warning("Please rebuild kernel with CONFIG_KPROBE_EVENTS "
- "or/and CONFIG_UPROBE_EVENTS.\n");
+ pr_warning("Please rebuild kernel with CONFIG_KPROBE_EVENT "
+ "or/and CONFIG_UPROBE_EVENT.\n");
else {
char sbuf[STRERR_BUFSIZE];
pr_warning("Failed to open kprobe events: %s.\n",
--
2.8.1
mm/compact: why use low watermark to determine whether compact is finished instead of use high watermark?
Hi, I find all the watermarks in mm/compaction.c are low_wmark_pages(), so why not use high watermark to determine whether compact is finished? e.g. __alloc_pages_nodemask() get_page_from_freelist() this is fast path, use use low_wmark_pages() in __zone_watermark_ok() __alloc_pages_slowpath() this is slow path, usually use min_wmark_pages() kswapd balance_pgdat() use high_wmark_pages() to determine whether zone is balanced Thanks, Xishi Qiu
Re: [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks
On Fri, Jul 22 2016, NeilBrown wrote: > > Looking at the current code, __GFP_DIRECT_RECLAIM is disabled the first > time through, but if the pool is empty, direct-reclaim is allowed on the > next attempt. Presumably this is where the throttling comes in ?? I > suspect that it really shouldn't do that. It should leave kswapd to do > reclaim (so __GFP_KSWAPD_RECLAIM is appropriate) and only wait in > mempool_alloc where pool->wait can wake it up. Actually, thinking about the kswapd connection, it might make sense for mempool_alloc() to wait in the relevant pgdata->pfmemalloc_wait as well as waiting on pool->wait. What way it should be able to proceed as soon as any memory is available. I don't know what the correct 'pgdata' is though. Just a thought, NeilBrown signature.asc Description: PGP signature
Re: mm/compact: why use low watermark to determine whether compact is finished instead of use high watermark?
On 07/22/2016 10:56 AM, Xishi Qiu wrote: Hi, I find all the watermarks in mm/compaction.c are low_wmark_pages(), so why not use high watermark to determine whether compact is finished? Why would you use high watermark? Quite the opposite, I want to move towards min watermark (precisely, the one in alloc_flags which is usually min) in this series: https://lkml.org/lkml/2016/6/24/222 especially: https://lkml.org/lkml/2016/6/24/214 e.g. __alloc_pages_nodemask() get_page_from_freelist() this is fast path, use use low_wmark_pages() in __zone_watermark_ok() __alloc_pages_slowpath() this is slow path, usually use min_wmark_pages() Yes, and compaction should be finished when allocation can succeed, so match __alloc_pages_slowpath(). kswapd balance_pgdat() use high_wmark_pages() to determine whether zone is balanced Thanks, Xishi Qiu
[PATCH RFC] coccinelle: tests: if and else branch should probably not be identical
Issue a warning if the if and else branch are identical - this can deliver
false positives as such constructs are sometime legitimate. In such cases
they should be documented so detecting false positives should be trivial
and if not it is a doc bug.
Signed-off-by: Nicholas Mc Guire
---
condition_with_no_effect.cocci was tested with
spatch version 1.0.5 compiled with OCaml version 4.01.0
Flags passed to the configure script: [none]
Python scripting support: yes
Syntax of regular expressions: PCRE
Some details:
In the kernel there are a number of cases where the if branch and the else
branch are identical code. Looking through the roughly 100 cases some do
seem legitimate (documented cases) but most seem to be bugs - code-bugs or
doc bugs. Below are some as examples followed by the full list.
So the question is - should this case be mentioned in CodingStyle or maybe
in SubmittingPatches (for the case of not-yet-implemented cases) ? That it
should be avoided if possible, I guess, is clear but given that its not that
uncommon it might need explicit treatment.
Properly documented cases:
./arch/sh/kernel/traps_64.c:59positional side effect in use
./fs/kernfs/file.c:668not yet implemented behavior
./drivers/media/platform/arv.c:221clearly marked as intended default
./drivers/net/wireless/ray_cs.c:2126 ...or at least has a TBD description
Some of the undocumented cases are probably simply intended "defaults"
which may well be reasonable but simply lack the documentation like
drivers/video/fbdev/sis/init301.c:7968
if(resindex == 0x04) {
SiS_SetCH70xxANDOR(SiS_Pr,0x20,0x00,0xEF); /* loop filter off */
SiS_SetCH70xxANDOR(SiS_Pr,0x21,0x01,0xFE); /* ACIV on */
} else {
SiS_SetCH70xxANDOR(SiS_Pr,0x20,0x00,0xEF); /* loop filter off */
SiS_SetCH70xxANDOR(SiS_Pr,0x21,0x01,0xFE); /* ACIV on */
}
And some do carry some sort of documentation but of really very limited help...
drivers/net/wireless/broadcom/b43/xmit.c:187
if (phy->type == B43_PHYTYPE_LP)
bw = B43_TXH_PHY1_BW_20;
else /* FIXME */
bw = B43_TXH_PHY1_BW_20;
Where documentation indicates a difference but code does not this is IMHO a bug
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2972
if (BTC_WIFI_BW_LEGACY == wifi_bw) {
/* for HID at 11b/g mode */
halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
0x5a5a5a5a, 0x, 0x3);
} else {
/* for HID quality & wifi performance balance at 11n mode */
halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
0x5a5a5a5a, 0x, 0x3);
}
Where there is no documentation but it also does not make sense as a default
it also is to qualified as a bug
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:694
case IEEE80211_STYPE_PROBE_REQ:
if (check_fwstate(pmlmepriv, WIFI_AP_STATE))
_mgt_dispatcher23a(padapter, ptable, precv_frame);
else
_mgt_dispatcher23a(padapter, ptable, precv_frame);
break;
The most impressive case of identical nested if-else is to be enjoyed in
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c starting
at line 2982.
finally the list of possible bugs / documentation omissions is as of -next
4.7-rc7:
./drivers/video/fbdev/sis/init301.c:9660
./drivers/video/fbdev/sis/init301.c:7968
./drivers/video/fbdev/sis/init301.c:6851
./drivers/net/wireless/realtek/rtlwifi/base.c:822
./drivers/net/wireless/realtek/rtlwifi/base.c:834
./drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c:886
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:2184
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:2206
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:2230
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:2252
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2105
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2127
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2151
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2173
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:1838
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:2213
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2972
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2972
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2972
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2972
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2984
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
[PATCH v3 0/7] rk3399 support ddr frequency scaling
rk3399 platform have dfi controller can monitor ddr load, and dcf controller to handle ddr register so we can get the right ddr frequency and make ddr controller happy work(which will implement in bl31). So we do ddr frequency scaling with following flow: kernelbl31 monitor ddr load | | get_target_rate | | pass rate to bl31 clk_set_rate(ddr) ->run dcf flow | | | | wait dcf interrupt<---trigger dcf interrupt | | return Lin Huang (6): clk: rockchip: add new clock-type for the ddrclk clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc clk: rockchip: rk3399: add ddrc clock support PM / devfreq: event: support rockchip dfi controller PM / devfreq: rockchip: add devfreq driver for rk3399 dmc drm/rockchip: Add dmc notifier in vop driver Shengfei xu (1): firmware: rockchip: sip: Add rockchip SIP runtime service drivers/clk/rockchip/Makefile | 1 + drivers/clk/rockchip/clk-ddr.c | 139 drivers/clk/rockchip/clk-rk3399.c | 19 ++ drivers/clk/rockchip/clk.c | 9 + drivers/clk/rockchip/clk.h | 27 ++ drivers/devfreq/Kconfig | 1 + drivers/devfreq/Makefile| 1 + drivers/devfreq/event/Kconfig | 7 + drivers/devfreq/event/Makefile | 1 + drivers/devfreq/event/rockchip-dfi.c| 253 +++ drivers/devfreq/rockchip/Kconfig| 15 + drivers/devfreq/rockchip/Makefile | 2 + drivers/devfreq/rockchip/rk3399_dmc.c | 482 drivers/devfreq/rockchip/rockchip_dmc.c | 143 + drivers/firmware/Kconfig| 7 + drivers/firmware/Makefile | 1 + drivers/firmware/rockchip_sip.c | 64 drivers/firmware/rockchip_sip.h | 59 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 75 - include/dt-bindings/clock/rk3399-cru.h | 1 + include/soc/rockchip/rockchip_dmc.h | 45 +++ 21 files changed, 1346 insertions(+), 6 deletions(-) create mode 100644 drivers/clk/rockchip/clk-ddr.c create mode 100644 drivers/devfreq/event/rockchip-dfi.c create mode 100644 drivers/devfreq/rockchip/Kconfig create mode 100644 drivers/devfreq/rockchip/Makefile create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c create mode 100644 drivers/devfreq/rockchip/rockchip_dmc.c create mode 100644 drivers/firmware/rockchip_sip.c create mode 100644 drivers/firmware/rockchip_sip.h create mode 100644 include/soc/rockchip/rockchip_dmc.h -- 2.6.6
[PATCH v3 7/7] drm/rockchip: Add dmc notifier in vop driver
when in ddr frequency scaling process, vop can not do
enable or disable operate, since dcf will base on vop vblank
time to do frequency scaling and need to get vop irq if there
have vop enabled. So need register to dmc notifier, and we can
get the dmc status.
Signed-off-by: Lin Huang
---
Changes in v3:
- when do vop eanble/disable, dmc will wait until it finish
Changes in v2:
- None
Changes in v1:
- use wait_event instead usleep
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 75 ++---
1 file changed, 69 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 6255e5b..4220629 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -31,6 +31,8 @@
#include
#include
+#include
+
#include "rockchip_drm_drv.h"
#include "rockchip_drm_gem.h"
#include "rockchip_drm_fb.h"
@@ -120,6 +122,11 @@ struct vop {
const struct vop_data *data;
+ struct notifier_block dmc_nb;
+ int dmc_in_process;
+ int vop_switch_status;
+ wait_queue_head_t wait_dmc_queue;
+ wait_queue_head_t wait_vop_switch_queue;
uint32_t *regsbak;
void __iomem *regs;
@@ -430,21 +437,56 @@ static void vop_dsp_hold_valid_irq_disable(struct vop
*vop)
spin_unlock_irqrestore(&vop->irq_lock, flags);
}
+static int dmc_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct vop *vop = container_of(nb, struct vop, dmc_nb);
+
+ if (event == DMCFREQ_ADJUST) {
+
+ /*
+* check if vop in enable or disable process,
+* if yes, wait until it finish, use 200ms as
+* timeout.
+*/
+ wait_event_timeout(vop->wait_vop_switch_queue,
+ !vop->vop_switch_status, HZ / 5);
+ vop->dmc_in_process = 1;
+ } else if (event == DMCFREQ_FINISH) {
+ vop->dmc_in_process = 0;
+ wake_up(&vop->wait_dmc_queue);
+ }
+
+ return NOTIFY_OK;
+}
+
static void vop_enable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
int ret;
+ if (vop->is_enabled)
+ return;
+
+ /*
+* if in dmc scaling frequency process, wait until it finish
+* use 100ms as timeout time.
+*/
+ wait_event_timeout(vop->wait_dmc_queue,
+ !vop->dmc_in_process, HZ / 5);
+
+ vop->vop_switch_status = 1;
+
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
- return;
+ goto err;
}
ret = clk_enable(vop->hclk);
if (ret < 0) {
dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
- return;
+ goto err;
}
ret = clk_enable(vop->dclk);
@@ -458,7 +500,6 @@ static void vop_enable(struct drm_crtc *crtc)
dev_err(vop->dev, "failed to enable aclk - %d\n", ret);
goto err_disable_dclk;
}
-
/*
* Slave iommu shares power, irq and clock with vop. It was associated
* automatically with this master device via common driver code.
@@ -486,7 +527,9 @@ static void vop_enable(struct drm_crtc *crtc)
enable_irq(vop->irq);
drm_crtc_vblank_on(crtc);
-
+ vop->vop_switch_status = 0;
+ wake_up(&vop->wait_vop_switch_queue);
+ rockchip_dmc_get(&vop->dmc_nb);
return;
err_disable_aclk:
@@ -495,6 +538,10 @@ err_disable_dclk:
clk_disable(vop->dclk);
err_disable_hclk:
clk_disable(vop->hclk);
+err:
+ vop->vop_switch_status = 0;
+ wake_up(&vop->wait_vop_switch_queue);
+ return;
}
static void vop_crtc_disable(struct drm_crtc *crtc)
@@ -505,6 +552,15 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
WARN_ON(vop->event);
/*
+* if in dmc scaling frequency process, wait until it finish
+* use 100ms as timeout time.
+*/
+ wait_event_timeout(vop->wait_dmc_queue,
+ !vop->dmc_in_process, HZ / 5);
+
+ vop->vop_switch_status = 1;
+
+ /*
* We need to make sure that all windows are disabled before we
* disable that crtc. Otherwise we might try to scan from a destroyed
* buffer later.
@@ -517,7 +573,6 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
VOP_WIN_SET(vop, win, enable, 0);
spin_unlock(&vop->reg_lock);
}
-
drm_crtc_vblank_off(crtc);
/*
@@ -548,7 +603,6 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
* vop standby complete, so iommu detach is safe.
*/
rockchip_drm_dma_detach_device(vop->drm_dev, vop->dev);
-
clk_disable(
[PATCH v3 4/7] clk: rockchip: rk3399: add ddrc clock support
add ddrc clock setting, so we can do ddr frequency
scaling on rk3399 platform in future.
Signed-off-by: Lin Huang
---
Changes in v3:
- None
Changes in v2:
- remove clk_ddrc_dpll_src from critical clock list
Changes in v1:
- remove ddrc source CLK_IGNORE_UNUSED flag
- move clk_ddrc and clk_ddrc_dpll_src to critical
drivers/clk/rockchip/clk-rk3399.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
index c109d80..7ef9d82 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -118,6 +118,10 @@ PNAME(mux_armclkb_p) = {
"clk_core_b_lpll_src",
"clk_core_b_bpll_src",
"clk_core_b_dpll_src",
"clk_core_b_gpll_src" };
+PNAME(mux_ddrclk_p)= { "clk_ddrc_lpll_src",
+ "clk_ddrc_bpll_src",
+ "clk_ddrc_dpll_src",
+ "clk_ddrc_gpll_src" };
PNAME(mux_aclk_cci_p) = { "cpll_aclk_cci_src",
"gpll_aclk_cci_src",
"npll_aclk_cci_src",
@@ -1377,6 +1381,18 @@ static struct rockchip_clk_branch rk3399_clk_branches[]
__initdata = {
COMPOSITE_NOMUX(0, "clk_test", "clk_test_pre", CLK_IGNORE_UNUSED,
RK3368_CLKSEL_CON(58), 0, 5, DFLAGS,
RK3368_CLKGATE_CON(13), 11, GFLAGS),
+
+ /* ddrc */
+ GATE(0, "clk_ddrc_lpll_src", "lpll", 0, RK3399_CLKGATE_CON(3),
+0, GFLAGS),
+ GATE(0, "clk_ddrc_bpll_src", "bpll", 0, RK3399_CLKGATE_CON(3),
+1, GFLAGS),
+ GATE(0, "clk_ddrc_dpll_src", "dpll", 0, RK3399_CLKGATE_CON(3),
+2, GFLAGS),
+ GATE(0, "clk_ddrc_gpll_src", "gpll", 0, RK3399_CLKGATE_CON(3),
+3, GFLAGS),
+ COMPOSITE_DDRC(SCLK_DDRCLK, "clk_ddrc", mux_ddrclk_p, 0,
+ RK3399_CLKSEL_CON(6), 4, 2, MFLAGS, 0, 3, DFLAGS),
};
static struct rockchip_clk_branch rk3399_clk_pmu_branches[] __initdata = {
@@ -1487,6 +1503,9 @@ static const char *const rk3399_cru_critical_clocks[]
__initconst = {
"gpll_hclk_perilp1_src",
"gpll_aclk_perilp0_src",
"gpll_aclk_perihp_src",
+
+ /* ddrc */
+ "clk_ddrc"
};
static const char *const rk3399_pmucru_critical_clocks[] __initconst = {
--
2.6.6
[PATCH v3 2/7] clk: rockchip: add new clock-type for the ddrclk
On new rockchip platform(rk3399 etc), there have dcf controller to
do ddr frequency scaling, and this controller will implement in
arm-trust-firmware. We add a special clock-type to handle that.
Signed-off-by: Lin Huang
---
Changes in v3:
- use sip call to set/read ddr rate
Changes in v2:
- use GENMASK instead val_mask
- use divider_recalc_rate() instead DIV_ROUND_UP_ULL
- cleanup code
Changes in v1:
- None
drivers/clk/rockchip/Makefile | 1 +
drivers/clk/rockchip/clk-ddr.c | 139 +
drivers/clk/rockchip/clk.c | 9 +++
drivers/clk/rockchip/clk.h | 27
4 files changed, 176 insertions(+)
create mode 100644 drivers/clk/rockchip/clk-ddr.c
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index f47a2fa..b5f2c8e 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -8,6 +8,7 @@ obj-y += clk-pll.o
obj-y += clk-cpu.o
obj-y += clk-inverter.o
obj-y += clk-mmc-phase.o
+obj-y += clk-ddr.o
obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
obj-y += clk-rk3036.o
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
new file mode 100644
index 000..6f5f05e
--- /dev/null
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Lin Huang
+ *
+ * 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 "../../firmware/rockchip_sip.h"
+#include "clk.h"
+
+struct rockchip_ddrclk {
+ struct clk_hw hw;
+ void __iomem*reg_base;
+ int mux_offset;
+ int mux_shift;
+ int mux_width;
+ int mux_flag;
+ int div_shift;
+ int div_width;
+ int div_flag;
+ spinlock_t *lock;
+};
+
+#define to_rockchip_ddrclk_hw(hw) container_of(hw, struct rockchip_ddrclk, hw)
+
+static int rockchip_ddrclk_set_rate(struct clk_hw *hw, unsigned long drate,
+ unsigned long prate)
+{
+ u64 value;
+ struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+ unsigned long flags;
+
+ spin_lock_irqsave(ddrclk->lock, flags);
+ value = sip_smc_set_ddr_rate(drate);
+ spin_unlock_irqrestore(ddrclk->lock, flags);
+
+ return 0;
+}
+
+static unsigned long
+rockchip_ddrclk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ return sip_smc_get_ddr_rate();
+}
+
+static long clk_ddrclk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ return rate;
+}
+
+static u8 rockchip_ddrclk_get_parent(struct clk_hw *hw)
+{
+ struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+ int num_parents = clk_hw_get_num_parents(hw);
+ u32 val;
+
+ val = clk_readl(ddrclk->reg_base +
+ ddrclk->mux_offset) >> ddrclk->mux_shift;
+ val &= GENMASK(ddrclk->mux_width - 1, 0);
+
+ if (val >= num_parents)
+ return -EINVAL;
+
+ return val;
+}
+
+static const struct clk_ops rockchip_ddrclk_ops = {
+ .recalc_rate = rockchip_ddrclk_recalc_rate,
+ .set_rate = rockchip_ddrclk_set_rate,
+ .round_rate = clk_ddrclk_round_rate,
+ .get_parent = rockchip_ddrclk_get_parent,
+};
+
+struct clk *rockchip_clk_register_ddrclk(const char *name, int flags,
+const char *const *parent_names,
+u8 num_parents, int mux_offset,
+int mux_shift, int mux_width,
+int mux_flag, int div_shift,
+int div_width, int div_flag,
+void __iomem *reg_base,
+spinlock_t *lock)
+{
+ struct rockchip_ddrclk *ddrclk;
+ struct clk_init_data init;
+ struct clk *clk;
+
+ ddrclk = kzalloc(sizeof(*ddrclk), GFP_KERNEL);
+ if (!ddrclk)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.parent_names = parent_names;
+ init.num_parents = num_parents;
+ init.ops = &rockchip_ddrclk_ops;
+
+ init.flags = flags;
+ init.flags |= CLK_SET_RATE_NO_REPARENT;
+ init.flags |= CLK_GET_RATE_NOCACHE;
+
+ ddrclk->reg_base = reg_b
Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control method lid device restrictions
On Fri, Jul 22, 2016 at 10:47 AM, Zheng, Lv wrote:
> Hi,
>
>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
>> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
>> method lid device restrictions
>>
>> On Fri, Jul 22, 2016 at 6:37 AM, Dmitry Torokhov
>> wrote:
>> > Hi Lv,
>> >
>> > On Fri, Jul 22, 2016 at 12:24:50AM +, Zheng, Lv wrote:
>> >> Hi, Dmitry
>> >>
>> >>
>> >> Thanks for the review.
>> >>
>> >> > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
>> >> > Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI
>> control
>> >> > method lid device restrictions
>> >> >
>> >> > On Tue, Jul 19, 2016 at 04:11:21PM +0800, Lv Zheng wrote:
>> >> > > This patch adds documentation for the usage model of the control
>> >> > method lid
>> >> > > device.
>> >> > >
>> >> > > Signed-off-by: Lv Zheng
>> >> > > Cc: Dmitry Torokhov
>> >> > > Cc: Benjamin Tissoires
>> >> > > Cc: Bastien Nocera:
>> >> > > Cc: linux-in...@vger.kernel.org
>> >> > > ---
>> >> > > Documentation/acpi/acpi-lid.txt | 89
>> >> > +++
>> >> > > 1 file changed, 89 insertions(+)
>> >> > > create mode 100644 Documentation/acpi/acpi-lid.txt
>> >> > >
>> >> > > diff --git a/Documentation/acpi/acpi-lid.txt
>> b/Documentation/acpi/acpi-
>> >> > lid.txt
>> >> > > new file mode 100644
>> >> > > index 000..2addedc
>> >> > > --- /dev/null
>> >> > > +++ b/Documentation/acpi/acpi-lid.txt
>> >> > > @@ -0,0 +1,89 @@
>> >> > > +Usage Model of the ACPI Control Method Lid Device
>> >> > > +
>> >> > > +Copyright (C) 2016, Intel Corporation
>> >> > > +Author: Lv Zheng
>> >> > > +
>> >> > > +
>> >> > > +Abstract:
>> >> > > +
>> >> > > +Platforms containing lids convey lid state (open/close) to OSPMs
>> using
>> >> > a
>> >> > > +control method lid device. To implement this, the AML tables issue
>> >> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
>> state has
>> >> > > +changed. The _LID control method for the lid device must be
>> >> > implemented to
>> >> > > +report the "current" state of the lid as either "opened" or "closed".
>> >> > > +
>> >> > > +This document describes the restrictions and the expections of the
>> >> > Linux
>> >> > > +ACPI lid device driver.
>> >> > > +
>> >> > > +
>> >> > > +1. Restrictions of the returning value of the _LID control method
>> >> > > +
>> >> > > +The _LID control method is described to return the "current" lid
>> state.
>> >> > > +However the word of "current" has ambiguity, many AML tables
>> return
>> >> > the lid
>> >> >
>> >> > Can this be fixed in the next ACPI revision?
>> >> [Lv Zheng]
>> >> Even this is fixed in the ACPI specification, there are platforms already
>> doing this.
>> >> Especially platforms from Microsoft.
>> >> So the de-facto standard OS won't care about the change.
>> >> And we can still see such platforms.
>> >>
>> >> Here is an example from Surface 3:
>> >>
>> >> DefinitionBlock ("dsdt.aml", "DSDT", 2, "ALASKA", "A M I ", 0x01072009)
>> >> {
>> >> Scope (_SB)
>> >> {
>> >> Device (PCI0)
>> >> {
>> >> Name (_HID, EisaId ("PNP0A08")) // _HID: Hardware ID
>> >> Name (_CID, EisaId ("PNP0A03")) // _CID: Compatible ID
>> >> Device (SPI1)
>> >> {
>> >> Name (_HID, "8086228E") // _HID: Hardware ID
>> >> Device (NTRG)
>> >> {
>> >> Name (_HID, "MSHW0037") // _HID: Hardware ID
>> >> }
>> >> }
>> >> }
>> >>
>> >> Device (LID)
>> >> {
>> >> Name (_HID, EisaId ("PNP0C0D"))
>> >> Name (LIDB, Zero)
>> >
>> > Start with lid closed? In any case might be wrong.
>>
>> Actually the initial value doesn't matter if the gpiochip triggers the
>> _EC4 at boot, which it should
>> (https://github.com/hadess/fedora-surface3-
>> kernel/commit/13200f81662c1c0b58137947c3e6c000fe62a2ba,
>> still unsubmitted)
>>
>> >
>> >> Method (_LID, 0, NotSerialized)
>> >> {
>> >> Return (LIDB)
>> >
>> > So "_LID" returns the last state read by "_EC4". "_EC4" is
>> > edge-triggered and will be evaluated every time gpio changes state.
>>
>> That's assuming the change happens while the system is on. If you go
>> into suspend by closing the LID. Open it while on suspend and then hit
>> the power button given that the system doesn't wake up when the lid is
>> opened, the edge change was made while the system is asleep, and we
>> are screwed (from an ACPI point of view). See my next comment for a
>> solution.
>>
> [Lv Zheng]
> I actually not sure if polling can fix all issues.
> For example.
> If a platform reporting "close" after resuming.
> Then polling _LID will always return "close".
> And the userspace can still get the "close" not "open".
> So it seems polling is not working for such platforms (cached value, initial
> close).
> Surface 3 is not the only pl
[PATCH v3 5/7] PM / devfreq: event: support rockchip dfi controller
on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.
Signed-off-by: Lin Huang
Acked-by: Chanwoo Choi
---
Changes in v3:
- None
Changes in v2:
- use clk_disable_unprepare and clk_enable_prepare
- remove clk_enable_prepare in probe
- remove rockchip_dfi_remove function
Changes in v1:
- None
drivers/devfreq/event/Kconfig| 7 +
drivers/devfreq/event/Makefile | 1 +
drivers/devfreq/event/rockchip-dfi.c | 253 +++
3 files changed, 261 insertions(+)
create mode 100644 drivers/devfreq/event/rockchip-dfi.c
diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index eb6f74a..0d32d68 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -30,4 +30,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
(Platform Performance Monitoring Unit) counters to estimate the
utilization of each module.
+config DEVFREQ_EVENT_ROCKCHIP_DFI
+ bool "ROCKCHIP DFI DEVFREQ event Driver"
+ depends on ARCH_ROCKCHIP
+ help
+ This add the devfreq-event driver for Rockchip SoC. It provides DFI
+ (DDR Monitor Module) driver to count ddr load.
+
endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index 3d6afd3..dda7090 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP) += exynos-nocp.o
obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
+obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
diff --git a/drivers/devfreq/event/rockchip-dfi.c
b/drivers/devfreq/event/rockchip-dfi.c
new file mode 100644
index 000..96a0307
--- /dev/null
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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
+
+#define RK3399_DMC_NUM_CH 2
+
+/* DDRMON_CTRL */
+#define DDRMON_CTRL0x04
+#define CLR_DDRMON_CTRL(0x1f << 0)
+#define LPDDR4_EN (0x10001 << 4)
+#define HARDWARE_EN(0x10001 << 3)
+#define LPDDR3_EN (0x10001 << 2)
+#define SOFTWARE_EN(0x10001 << 1)
+#define TIME_CNT_EN(0x10001 << 0)
+
+#define DDRMON_CH0_COUNT_NUM 0x28
+#define DDRMON_CH0_DFI_ACCESS_NUM 0x2c
+#define DDRMON_CH1_COUNT_NUM 0x3c
+#define DDRMON_CH1_DFI_ACCESS_NUM 0x40
+
+/* pmu grf */
+#define PMUGRF_OS_REG2 0x308
+#define DDRTYPE_SHIFT 13
+#define DDRTYPE_MASK 7
+
+enum {
+ DDR3 = 3,
+ LPDDR3 = 6,
+ LPDDR4 = 7,
+ UNUSED = 0xFF
+};
+
+struct dmc_usage {
+ u32 access;
+ u32 total;
+};
+
+struct rockchip_dfi {
+ struct devfreq_event_dev *edev;
+ struct devfreq_event_desc *desc;
+ struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
+ struct device *dev;
+ void __iomem *regs;
+ struct regmap *regmap_pmu;
+ struct clk *clk;
+};
+
+static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
+{
+ struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+ void __iomem *dfi_regs = info->regs;
+ u32 val;
+ u32 ddr_type;
+
+ /* get ddr type */
+ regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, &val);
+ ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+
+ /* clear DDRMON_CTRL setting */
+ writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
+
+ /* set ddr type to dfi */
+ if (ddr_type == LPDDR3)
+ writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
+ else if (ddr_type == LPDDR4)
+ writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
+
+ /* enable count, use software mode */
+ writel_relaxed(SOFTWARE_EN, dfi_regs + DDRMON_CTRL);
+}
+
+static void rockchip_dfi_stop_hardware_counter(struct devfreq_event_dev *edev)
+{
+ struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+ void __iomem *dfi_regs = info->regs;
+ u32 val;
+
+ val = readl_relaxed(dfi_regs + DDRMON_CTRL);
+ val &= ~SOFTWARE_EN;
+ writel_relaxed(val, dfi_regs + DDRMON_CTRL);
+}
+
+static int rockchip_dfi_get_busier_ch(struct devfreq_event_dev *edev)
+{
+ struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+ u32 tmp, max = 0;
+ u32 i, busier_ch = 0;
+
[PATCH v3 6/7] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.
Signed-off-by: Lin Huang
---
Changes in v3:
- operate dram setting through sip call
- imporve set rate flow
Changes in v2:
- None
Changes in v1:
- move dfi controller to event
- fix set voltage sequence when set rate fail
- change Kconfig type from tristate to bool
- move unuse EXPORT_SYMBOL_GPL()
drivers/devfreq/Kconfig | 1 +
drivers/devfreq/Makefile| 1 +
drivers/devfreq/rockchip/Kconfig| 15 +
drivers/devfreq/rockchip/Makefile | 2 +
drivers/devfreq/rockchip/rk3399_dmc.c | 482
drivers/devfreq/rockchip/rockchip_dmc.c | 143 ++
include/soc/rockchip/rockchip_dmc.h | 45 +++
7 files changed, 689 insertions(+)
create mode 100644 drivers/devfreq/rockchip/Kconfig
create mode 100644 drivers/devfreq/rockchip/Makefile
create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c
create mode 100644 drivers/devfreq/rockchip/rockchip_dmc.c
create mode 100644 include/soc/rockchip/rockchip_dmc.h
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index a5be56e..cb67246 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -101,5 +101,6 @@ config ARM_TEGRA_DEVFREQ
operating frequencies and voltages with OPP support.
source "drivers/devfreq/event/Kconfig"
+source "drivers/devfreq/rockchip/Kconfig"
endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 09f11d9..48e2ae6 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
# DEVFREQ Drivers
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
+obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
# DEVFREQ Event Drivers
obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
diff --git a/drivers/devfreq/rockchip/Kconfig b/drivers/devfreq/rockchip/Kconfig
new file mode 100644
index 000..7fb1cff
--- /dev/null
+++ b/drivers/devfreq/rockchip/Kconfig
@@ -0,0 +1,15 @@
+config ARM_ROCKCHIP_DMC_DEVFREQ
+ bool "ARM ROCKCHIP DMC DEVFREQ Driver"
+ depends on ARCH_ROCKCHIP
+ help
+ This adds the DEVFREQ driver framework for the rockchip dmc.
+
+config ARM_RK3399_DMC_DEVFREQ
+ bool "ARM RK3399 DMC DEVFREQ Driver"
+ depends on ARM_ROCKCHIP_DMC_DEVFREQ
+ select PM_OPP
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ help
+ This adds the DEVFREQ driver for the RK3399 dmc. It sets the
frequency
+ for the memory controller and reads the usage counts from hardware.
+
diff --git a/drivers/devfreq/rockchip/Makefile
b/drivers/devfreq/rockchip/Makefile
new file mode 100644
index 000..caca525
--- /dev/null
+++ b/drivers/devfreq/rockchip/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_ARM_ROCKCHIP_DMC_DEVFREQ) += rockchip_dmc.o
+obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
diff --git a/drivers/devfreq/rockchip/rk3399_dmc.c
b/drivers/devfreq/rockchip/rk3399_dmc.c
new file mode 100644
index 000..f1d6120
--- /dev/null
+++ b/drivers/devfreq/rockchip/rk3399_dmc.c
@@ -0,0 +1,482 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 "../../firmware/rockchip_sip.h"
+
+struct dram_timing {
+ unsigned int ddr3_speed_bin;
+ unsigned int pd_idle;
+ unsigned int sr_idle;
+ unsigned int sr_mc_gate_idle;
+ unsigned int srpd_lite_idle;
+ unsigned int standby_idle;
+ unsigned int dram_dll_dis_freq;
+ unsigned int phy_dll_dis_freq;
+ unsigned int ddr3_odt_dis_freq;
+ unsigned int ddr3_drv;
+ unsigned int ddr3_odt;
+ unsigned int phy_ddr3_ca_drv;
+ unsigned int phy_ddr3_dq_drv;
+ unsigned int phy_ddr3_odt;
+ unsigned int lpddr3_odt_dis_freq;
+ unsigned int lpddr3_drv;
+ unsigned int lpddr3_odt;
+ unsigned int phy_lpddr3_ca_drv;
+ unsigned int phy_lpddr3_dq_drv;
+ unsigned int phy_lpddr3_odt;
+ unsigned int lpddr4_odt_dis_freq;
+ unsigned int lpddr4_drv;
+ unsigned int lpddr4_dq_odt;
+ unsigned int lpddr4_ca_odt;
+ unsigned int phy_lpddr4_ca_drv;
+ unsign
[PATCH v3 3/7] clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc
Signed-off-by: Lin Huang --- Changes in v3: -None Changes in v2: - None Changes in v1: - None include/dt-bindings/clock/rk3399-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h index 50a44cf..8a0f0442 100644 --- a/include/dt-bindings/clock/rk3399-cru.h +++ b/include/dt-bindings/clock/rk3399-cru.h @@ -131,6 +131,7 @@ #define SCLK_DPHY_RX0_CFG 165 #define SCLK_RMII_SRC 166 #define SCLK_PCIEPHY_REF100M 167 +#define SCLK_DDRCLK168 #define DCLK_VOP0 180 #define DCLK_VOP1 181 -- 2.6.6
[PATCH v3 1/7] firmware: rockchip: sip: Add rockchip SIP runtime service
From: Shengfei xu
This patch adds support for the SiP interface, we can pass dram
paramtert to bl31, and control ddr frequency scaling in bl31.
Signed-off-by: Shengfei xu
Signed-off-by: Lin Huang
---
Changes in v3:
- None
Changes in v2:
- None
Changes in v1:
- None
drivers/firmware/Kconfig| 7 +
drivers/firmware/Makefile | 1 +
drivers/firmware/rockchip_sip.c | 64 +
drivers/firmware/rockchip_sip.h | 59 +
4 files changed, 131 insertions(+)
create mode 100644 drivers/firmware/rockchip_sip.c
create mode 100644 drivers/firmware/rockchip_sip.h
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 0e22f24..6f585c5 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -206,6 +206,13 @@ config QCOM_SCM_64
config HAVE_ARM_SMCCC
bool
+config ROCKCHIP_SIP
+ bool "Rockchip SIP interface"
+ depends on ARM64 && ARM_PSCI_FW
+ help
+ Say Y here if you want to enable SIP callbacks for Rockchip platforms
+ This option enables support for communicating with the ATF.
+
source "drivers/firmware/broadcom/Kconfig"
source "drivers/firmware/google/Kconfig"
source "drivers/firmware/efi/Kconfig"
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 44a59dc..e9eab5b 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -25,3 +25,4 @@ obj-y += broadcom/
obj-$(CONFIG_GOOGLE_FIRMWARE) += google/
obj-$(CONFIG_EFI) += efi/
obj-$(CONFIG_UEFI_CPER)+= efi/
+obj-$(CONFIG_ROCKCHIP_SIP) += rockchip_sip.o
diff --git a/drivers/firmware/rockchip_sip.c b/drivers/firmware/rockchip_sip.c
new file mode 100644
index 000..7756af9
--- /dev/null
+++ b/drivers/firmware/rockchip_sip.c
@@ -0,0 +1,64 @@
+/*
+ * 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.
+ *
+ * Copyright (C) 2016 ARM Limited
+ */
+#include
+#include
+#include
+#include
+#include
+#include "rockchip_sip.h"
+
+typedef unsigned long (psci_fn)(unsigned long, unsigned long,
+ unsigned long, unsigned long);
+asmlinkage psci_fn __invoke_psci_fn_smc;
+
+#define CONFIG_DRAM_INIT 0x00
+#define CONFIG_DRAM_SET_RATE 0x01
+#define CONFIG_DRAM_ROUND_RATE 0x02
+#define CONFIG_DRAM_SET_AT_SR 0x03
+#define CONFIG_DRAM_GET_BW 0x04
+#define CONFIG_DRAM_GET_RATE 0x05
+#define CONFIG_DRAM_CLR_IRQ0x06
+#define CONFIG_DRAM_SET_PARAM 0x07
+
+uint64_t sip_smc_ddr_init(void)
+{
+ return __invoke_psci_fn_smc(SIP_DDR_FREQ, 0,
+ 0, CONFIG_DRAM_INIT);
+}
+
+uint64_t sip_smc_set_ddr_param(uint64_t param)
+{
+ return __invoke_psci_fn_smc(SIP_DDR_FREQ, param,
+ 0, CONFIG_DRAM_SET_PARAM);
+}
+
+uint64_t sip_smc_set_ddr_rate(uint64_t rate)
+{
+ return __invoke_psci_fn_smc(SIP_DDR_FREQ, rate, 0,
+ CONFIG_DRAM_SET_RATE);
+}
+
+uint64_t sip_smc_get_ddr_rate(void)
+{
+ return __invoke_psci_fn_smc(SIP_DDR_FREQ, 0, 0, CONFIG_DRAM_GET_RATE);
+}
+
+uint64_t sip_smc_clr_ddr_irq(void)
+{
+ return __invoke_psci_fn_smc(SIP_DDR_FREQ, 0, 0, CONFIG_DRAM_CLR_IRQ);
+}
+
+uint64_t sip_smc_get_call_count(void)
+{
+ return __invoke_psci_fn_smc(SIP_SVC_CALL_COUNT, 0, 0, 0);
+}
diff --git a/drivers/firmware/rockchip_sip.h b/drivers/firmware/rockchip_sip.h
new file mode 100644
index 000..6487734
--- /dev/null
+++ b/drivers/firmware/rockchip_sip.h
@@ -0,0 +1,59 @@
+/* Copyright (c) 2010-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+#ifndef __SIP_INT_H
+#define __SIP_INT_H
+
+/* SMC function IDs for SiP Service queries */
+#define SIP_SVC_CALL_COUNT 0x8200ff00
+#define SIP_SVC_UID0x8200ff01
+#define SIP_SVC_VERSION0x8200ff03
+#define SIP_DDR_FREQ 0xC208
+
+#if IS_ENABLED(CONFIG_ROCKCHIP_SIP)
+uint64_t sip_smc_set_ddr_rate(uint64_t rate);
+uint64_t sip_smc_get_ddr_rate(void);
+uint64_t sip_smc_clr_ddr_irq(void);
+uint64_t sip_smc_get_
Re: [PATCH 14/18] ARM: mvebu: add support for the Armada 395 SoC family
Hi Rob, 2016-07-22 0:16 GMT+02:00 Rob Herring : > On Thu, Jul 21, 2016 at 02:44:11PM +0200, Grzegorz Jaszczyk wrote: >> -compatible = "marvell,a398-db", "marvell,armada398", "marvell,armada390"; >> +compatible = "marvell,a398-db", "marvell,armada398", "marvell,armada395", >> "marvell,armada390"; > > If 395 came after 398, then it should come first in the order. This > implies that marvell,armada398 is a better match than marvell,armada395. > Or perhaps you shouldn't have both? > > Rob I am not sure if I get your point. The Armada-398 extends the Armada-395 about 2 additional SATA ports (as you can see in commit "[PATCH 15/18] ARM: mvebu: a398: update the dtsi about missing interfaces"). In this example the a398-db board contains the Armada398 SoC, so it is a better match and goes first. Quite the same is for existing armada-388-db.dts, in which compatible looks like this: compatible = "marvell,a385-db", "marvell,armada388", "marvell,armada385", "marvell,armada380"; In above, Armada-388 also extends the Armada-385 and the order of the compatible is similar to one from my example. Thank you, Grzegorz
Re: [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks
On Fri 22-07-16 18:46:57, Neil Brown wrote: > On Mon, Jul 18 2016, Michal Hocko wrote: > > > From: Michal Hocko > > > > Mikulas has reported that a swap backed by dm-crypt doesn't work > > properly because the swapout cannot make a sufficient forward progress > > as the writeout path depends on dm_crypt worker which has to allocate > > memory to perform the encryption. In order to guarantee a forward > > progress it relies on the mempool allocator. mempool_alloc(), however, > > prefers to use the underlying (usually page) allocator before it grabs > > objects from the pool. Such an allocation can dive into the memory > > reclaim and consequently to throttle_vm_writeout. > > That's just broken. > I used to think mempool should always use the pre-allocated reserves > first. That is surely the most logical course of action. Otherwise > that memory is just sitting there doing nothing useful. > > I spoke to Nick Piggin about this some years ago and he pointed out that > the kmalloc allocation paths are much better optimized for low overhead > when there is plenty of memory. They can just pluck a free block of a > per-CPU list without taking any locks. By contrast, accessing the > preallocated pool always requires a spinlock. > > So it makes lots of sense to prefer the underlying allocator if it can > provide a quick response. If it cannot, the sensible thing is to use > the pool, or wait for the pool to be replenished. > > So the allocator should never wait at all, never enter reclaim, never > throttle. > > Looking at the current code, __GFP_DIRECT_RECLAIM is disabled the first > time through, but if the pool is empty, direct-reclaim is allowed on the > next attempt. Presumably this is where the throttling comes in ?? Yes that is correct. > I suspect that it really shouldn't do that. It should leave kswapd to > do reclaim (so __GFP_KSWAPD_RECLAIM is appropriate) and only wait in > mempool_alloc where pool->wait can wake it up. Mikulas was already suggesting that and my concern was that this would give up prematurely even under mild page cache load when there are many clean page cache pages. If we just back off and rely on kswapd which might get stuck on the writeout then the IO throughput can be reduced I believe which would make the whole memory pressure just worse. So I am not sure this is a good idea in general. I completely agree with you that the mempool request shouldn't be throttled unless there is a strong reason for that. More on that below. > If I'm following the code properly, the stack trace below can only > happen if the first pool->alloc() attempt, with direct-reclaim disabled, > fails and the pool is empty, so mempool_alloc() calls prepare_to_wait() > and io_schedule_timeout(). mempool_alloc retries immediatelly without any sleep after the first no-reclaim attempt. > I suspect the timeout *doesn't* fire (5 seconds is along time) so it > gets woken up when there is something in the pool. It then loops around > and tries pool->alloc() again, even though there is something in the > pool. This might be justified if that ->alloc would never block, but > obviously it does. > > I would very strongly recommend just changing mempool_alloc() to > permanently mask out __GFP_DIRECT_RECLAIM. > > Quite separately I don't think PF_LESS_THROTTLE is at all appropriate. > It is "LESS" throttle, not "NO" throttle, but you have made > throttle_vm_writeout never throttle PF_LESS_THROTTLE threads. Yes that is correct. But it still allows to throttle on congestion: shrink_inactive_list: /* * Stall direct reclaim for IO completions if underlying BDIs or zone * is congested. Allow kswapd to continue until it starts encountering * unqueued dirty pages or cycling through the LRU too quickly. */ if (!sc->hibernation_mode && !current_is_kswapd() && current_may_throttle()) wait_iff_congested(pgdat, BLK_RW_ASYNC, HZ/10); My thinking was that throttle_vm_writeout is there to prevent from dirtying too many pages from the reclaim the context. PF_LESS_THROTTLE is part of the writeout so throttling it on too many dirty pages is questionable (well we get some bias but that is not really reliable). It still makes sense to throttle when the backing device is congested because the writeout path wouldn't make much progress anyway and we also do not want to cycle through LRU lists too quickly in that case. Or is this assumption wrong for nfsd_vfs_write? Can it cause unbounded dirtying of memory? > The purpose of that flag is to allow a thread to dirty a page-cache page > as part of cleaning another page-cache page. > So it makes sense for loop and sometimes for nfsd. It would make sense > for dm-crypt if it was putting the encrypted version in the page cache. > But if dm-crypt is just allocating a transient page (which I think it > is), then a mempool should be sufficient (and we should make sure it is > sufficient) and access to
Re: What to do on cdev_add failure
Hi Greg, On Thu, 14 Jul 2016 15:47:35 +0900, Greg KH wrote: > On Wed, Jul 13, 2016 at 03:46:14PM +0200, Jean Delvare wrote: > > Hi all, > > > > I am currently working on the i2c-dev driver, which has just been > > converted to the non-ancestral cdev API. As I am cleaning up the > > driver, I would like to switch from static cdev initialization > > (cdev_init) to dynamic allocation (cdev_alloc.) > > > > While I was looking at other drivers to figure out how to deal with > > error cases, I found that different drivers do different things if > > cdev_add fails after cdev_alloc was called successfully. I guess some > > of them are right, others are wrong, and I'd like to know which is > > which ;-) > > > > * char/virtio_console.c, s390/char/tape_class.c, s390/char/vmur.c, > > infiniband/.../qib_file_ops.c, fuse/cuse.c, scsi/sg.c and scsi/st.g > > are calling cdev_del(cdev). > > * v4l2-core/v4l2-dev.c is calling kfree(cdev). > > * s390/char/vmlogrdr.c, uio/uio.c, tty/ty_io.c and __register_chrdev() > > are calling kobject_put(&cdev->kobj). The former explicitly says "no > > cdev_del here!" in a comment. > > > > My gut feeling is that kobject_put(&cdev->kobj) is correct, even though > > it feels strange to have to use a low-level function to clean-up after > > a higher level API call. > > > > If cdev_del(cdev) is also correct (and as I read the code it could be, > > iff calling kobj_unmap() is a no-op if kobj_map() failed - is it the > > case?), then it should be clearly documented as such, as it is > > counter-intuitive (to me, at least.) > > > > Anyone wants to comment on this? > > > > On top of this, another thing looks strange to me. cdev_add() only gets > > the parent kobj on success. However the release methods > > (cdev_default_release and cdev_dynamic_release) will put the parent > > kobj unconditionally. So it looks to me that we are over-putting the > > parent whenever cdev_add() fails. OTOH I can't see where the parent is > > set. If it is NULL then all these get and put are no-ops to start with > > and it no longer matters. But why would we be doing that? > > > > Then again, what do I know about kobj black magic... > > It's worse than you think, the kobject in a cdev is not a "real" > kobject. Well, it's kind of real, but it's only there to be used for > the kmap logic. I have a 10+ year old TODO item here that says "remove > kobj from cdev" that I really should get to one of these days. I did figure that out actually. > Anyone that touches the kobj outside of the cdev core code is probably > wrong, it's "funny" that both uio and tty do that, the maintainer of > that code must be lazy... :) Or just as confused as myself. > Let me look into what the "correct" thing to do here is, I used to know > it, need some time to refresh my memory... Did you find? > And the cdev interface has what, 4 different ways it can be used? > Another of my TODO items is to fix it all up to only use it one way, or > maybe just 2 as it does have the ability to make driver code pretty > small if you use it in unique ways... -- Jean Delvare SUSE L3 Support
Re: [PATCH v2 3/4] drivers: reset: Add STM32 reset driver
Hi Paul
On 07/21/2016 09:48 PM, Paul Gortmaker wrote:
On Thu, Jul 21, 2016 at 5:19 AM, wrote:
From: Maxime Coquelin
The STM32 MCUs family IPs can be reset by accessing some registers
from the RCC block.
The list of available reset lines is documented in the DT bindings.
Signed-off-by: Maxime Coquelin
Signed-off-by: Gabriel Fernandez
---
drivers/reset/Makefile | 1 +
drivers/reset/reset-stm32.c | 113
2 files changed, 114 insertions(+)
create mode 100644 drivers/reset/reset-stm32.c
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 5d65a93..64ebb0c 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
obj-$(CONFIG_ARCH_MESON) += reset-meson.o
+obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
In my tree, this Kconfig ARCH_STM32 is a bool, so...
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
obj-$(CONFIG_ARCH_HISI) += hisilicon/
diff --git a/drivers/reset/reset-stm32.c b/drivers/reset/reset-stm32.c
new file mode 100644
index 000..993af2a
--- /dev/null
+++ b/drivers/reset/reset-stm32.c
@@ -0,0 +1,113 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin _
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * Heavily based on sunxi driver from Maxime Ripard.
+ */
+
+#include
+#include
+#include
...we probably don't need module.h here or any of the other
MODULE_ tags/macros either. Use the builtin for the
register and all should be good.
Thanks,
Paul.
--
Ok i will sent a v3
Thanks for reviewing !
BR
Gabriel
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct stm32_reset_data {
+ spinlock_t lock;
+ void __iomem*membase;
+ struct reset_controller_dev rcdev;
+};
+
+static int stm32_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct stm32_reset_data *data = container_of(rcdev,
+struct stm32_reset_data,
+rcdev);
+ int bank = id / BITS_PER_LONG;
+ int offset = id % BITS_PER_LONG;
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ reg = readl(data->membase + (bank * 4));
+ writel(reg | BIT(offset), data->membase + (bank * 4));
+
+ spin_unlock_irqrestore(&data->lock, flags);
+
+ return 0;
+}
+
+static int stm32_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct stm32_reset_data *data = container_of(rcdev,
+struct stm32_reset_data,
+rcdev);
+ int bank = id / BITS_PER_LONG;
+ int offset = id % BITS_PER_LONG;
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ reg = readl(data->membase + (bank * 4));
+ writel(reg & ~BIT(offset), data->membase + (bank * 4));
+
+ spin_unlock_irqrestore(&data->lock, flags);
+
+ return 0;
+}
+
+static const struct reset_control_ops stm32_reset_ops = {
+ .assert = stm32_reset_assert,
+ .deassert = stm32_reset_deassert,
+};
+
+static const struct of_device_id stm32_reset_dt_ids[] = {
+{ .compatible = "st,stm32-rcc", },
+{ /* sentinel */ },
+};
+
+static int stm32_reset_probe(struct platform_device *pdev)
+{
+ struct stm32_reset_data *data;
+ struct resource *res;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->membase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->membase))
+ return PTR_ERR(data->membase);
+
+ spin_lock_init(&data->lock);
+
+ data->rcdev.owner = THIS_MODULE;
+ data->rcdev.nr_resets = resource_size(res) * 8;
+ data->rcdev.ops = &stm32_reset_ops;
+ data->rcdev.of_node = pdev->dev.of_node;
+
+ return devm_reset_controller_register(&pdev->dev, &data->rcdev);
+}
+
+static struct platform_driver stm32_reset_driver = {
+ .probe = stm32_reset_probe,
+ .driver = {
+ .name = "stm32-rcc-reset",
+ .of_match_table = stm32_reset_dt_ids,
+ },
+};
+module_platform_driver(stm32_reset_driver);
+
+MODULE_AUTHOR("Maxime Coquelin ");
+MODULE_DESCRIPTION("STM32 MCUs Reset Controller Driver");
+MODULE_LICENSE("GPL");
--
1.9.1
Re: [PATCH 2/2] ARM: DRA7: select PCI_DOMAINS config
On Friday 22 July 2016 01:56 PM, Kishon Vijay Abraham I wrote: > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 90542db..0cccb50 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -338,6 +338,7 @@ config ARCH_MULTIPLATFORM > select MULTI_IRQ_HANDLER > select SPARSE_IRQ > select USE_OF > + select PCI_DOMAINS if PCI Keep the select list in sorted order. Regards, Sekhar
Why does BIOS assign memory to 16 byte BAR
Hi, I'm observing that on x86 BIOS successfully assigns memory if an End point requests BAR of size 16byte. But as per Spec: The minimum memory address range requested by a BAR is 128 bytes. Why BIOS is successfully allocating region to 16 byte BAR requests? Please let me know if my observation is wrong. Regards, Bharat This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Re: [v6 PATCH 1/6] extcon: Add Type-C and DP support
Hi Chris,
I'm sorry for late reply. I finished the first draft to support the extcon
property.
You can check the patches[1]. But, I need more time to test it. After tested it,
I'll send the patches.
[1]
https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-test
Chanwoo Choi (4):
extcon: Add the extcon_type to group each connector into five category
extcon: Add the support for extcon property according to type of connector
extcon: Rename the extcon_set/get_state() to maintain the function naming
pattern
extcon: Add the sync APIs to support the notification for extcon property
Chris Zhong (1):
extcon: Add EXTCON_DISP_DP and the property for USB Type-C
Regards,
Chanwoo Choi
On 2016년 07월 21일 22:13, Chris Zhong wrote:
> Add EXTCON_DISP_DP for the Display external connector. For Type-C
> connector the DisplayPort can work as an Alternate Mode(VESA DisplayPort
> Alt Mode on USB Type-C Standard). The Type-C support both normal and
> flipped orientation, so add a property to extcon.
>
> Signe-off-by: Chris Zhong
>
> Signed-off-by: Chris Zhong
> ---
>
> Changes in v6:
> - move the EXTCON_PROP_TYPEC_POLARITY to EXTCON_TYPE_USB in _supported
> Series-changes: 5
> - support get property
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> Changes in v1: None
>
> drivers/extcon/extcon.c | 26 ++
> include/linux/extcon.h | 13 +
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index a1117db..f79b510 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -157,6 +157,11 @@ struct __extcon_info {
> .id = EXTCON_DISP_VGA,
> .name = "VGA",
> },
> + [EXTCON_DISP_DP] = {
> + .type = EXTCON_TYPE_DISP | EXTCON_TYPE_USB,
> + .id = EXTCON_DISP_DP,
> + .name = "DP",
> + },
>
> /* Miscellaneous external connector */
> [EXTCON_DOCK] = {
> @@ -270,6 +275,7 @@ static bool is_extcon_property_supported(unsigned int id,
> switch (prop) {
> case EXTCON_PROP_USB_ID:
> case EXTCON_PROP_USB_VBUS:
> + case EXTCON_PROP_TYPEC_POLARITY:
> return true;
> default:
> break;
> @@ -547,6 +553,26 @@ int extcon_get_cable_property(struct extcon_dev *edev,
> unsigned int id,
> enum extcon_property prop,
> union extcon_property_value *val)
> {
> + struct extcon_cable *cable;
> + int index;
> +
> + if (!edev)
> + return -EINVAL;
> +
> + /* Check the property whether is supported or not */
> + if (!is_extcon_property_supported(id, prop))
> + return -EINVAL;
> +
> + /* Find the cable index of external connector by using id */
> + index = find_cable_index_by_id(edev, id);
> + if (index < 0)
> + return index;
> +
> + /* Store the property value */
> + cable = &edev->cables[index];
> +
> + val->intval = cable->propval[prop].intval;
> +
> return 0;
> }
>
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
> index f6f0a8d..50ef87f 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -77,6 +77,7 @@ enum extcon_type {
> #define EXTCON_DISP_MHL 41 /* Mobile High-Definition Link
> */
> #define EXTCON_DISP_DVI 42 /* Digital Visual Interface */
> #define EXTCON_DISP_VGA 43 /* Video Graphics Array */
> +#define EXTCON_DISP_DP 44 /* DisplayPort */
>
> /* Miscellaneous external connector */
> #define EXTCON_DOCK 60
> @@ -108,9 +109,13 @@ enum extcon_property {
>* - EXTCON_PROP_USB_USB
>* @type: integer (int value)
>* @value: 0 (low) or 1 (high)
> + * - EXTCON_PROP_TYPEC_POLARITY,
> + * @type: integer (int value)
> + * @value: 0 (normal) or 1 (flip)
>*/
> EXTCON_PROP_USB_ID = 0,
> EXTCON_PROP_USB_VBUS,
> + EXTCON_PROP_TYPEC_POLARITY,
>
> /* Properties of EXTCON_TYPE_CHG. */
> /* Properties of EXTCON_TYPE_JACK. */
> @@ -225,6 +230,14 @@ extern int extcon_get_cable_state_(struct extcon_dev
> *edev, unsigned int id);
> extern int extcon_set_cable_state_(struct extcon_dev *edev, unsigned int id,
> bool cable_state);
>
> +extern int extcon_get_cable_property(struct extcon_dev *edev, unsigned int
> id,
> + enum extcon_property prop,
> + union extcon_property_value *val);
> +
> +extern int extcon_set_cable_property(struct extcon_dev *edev, unsigned int
> id,
> + enum extcon_property prop,
> + union extcon_property_value val);
> +
> /*
> * Follo
Re: mm/compact: why use low watermark to determine whether compact is finished instead of use high watermark?
On 07/22/2016 11:21 AM, Xishi Qiu wrote: On 2016/7/22 17:04, Vlastimil Babka wrote: On 07/22/2016 10:56 AM, Xishi Qiu wrote: Hi, I find all the watermarks in mm/compaction.c are low_wmark_pages(), so why not use high watermark to determine whether compact is finished? Why would you use high watermark? Quite the opposite, I want to move towards min watermark (precisely, the one in alloc_flags which is usually min) in this series: https://lkml.org/lkml/2016/6/24/222 especially: https://lkml.org/lkml/2016/6/24/214 e.g. __alloc_pages_nodemask() get_page_from_freelist() this is fast path, use use low_wmark_pages() in __zone_watermark_ok() __alloc_pages_slowpath() this is slow path, usually use min_wmark_pages() Yes, and compaction should be finished when allocation can succeed, so match __alloc_pages_slowpath(). Sounds reasonable, but now we have kcompactd which called from kswapd, so still use low wmark? kswapd uses high watermark (order-0) to make a buffer of free pages for both direct allocators and kcompactd. kcompactd will use min watermark for now. There used to be difference between min/low/high watermarks when checking high-orders, but now watermark only affects the check if there's enough total base pages, and high-order check then succeeds if there's at least one high(er)-order page. Thanks, Xishi Qiu kswapd balance_pgdat() use high_wmark_pages() to determine whether zone is balanced Thanks, Xishi Qiu .
Re: [PATCH] GPU-DRM-GMA500: Delete unnecessary checks before two function calls
On Fri, Jul 22, 2016 at 10:45:30AM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 22 Jul 2016 10:30:30 +0200
>
> The functions pci_dev_put() and psb_intel_i2c_destroy() test whether
> their argument is NULL and then return immediately.
> Thus the tests around their calls are not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
Two more applied. And your threading still looks funny, all the patches
are in-reply to one I don't even have.
-Daniel
> ---
> drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +--
> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 +++--
> drivers/gpu/drm/gma500/psb_drv.c| 6 ++
> drivers/gpu/drm/gma500/psb_intel_lvds.c | 9 +++--
> 4 files changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> index 28f9d90..563f193 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> @@ -246,8 +246,7 @@ static void cdv_hdmi_destroy(struct drm_connector
> *connector)
> {
> struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
>
> - if (gma_encoder->i2c_bus)
> - psb_intel_i2c_destroy(gma_encoder->i2c_bus);
> + psb_intel_i2c_destroy(gma_encoder->i2c_bus);
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 813ef23..38dc890 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -444,8 +444,7 @@ static void cdv_intel_lvds_destroy(struct drm_connector
> *connector)
> {
> struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
>
> - if (gma_encoder->i2c_bus)
> - psb_intel_i2c_destroy(gma_encoder->i2c_bus);
> + psb_intel_i2c_destroy(gma_encoder->i2c_bus);
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> @@ -780,12 +779,10 @@ out:
> failed_find:
> mutex_unlock(&dev->mode_config.mutex);
> printk(KERN_ERR "Failed find\n");
> - if (gma_encoder->ddc_bus)
> - psb_intel_i2c_destroy(gma_encoder->ddc_bus);
> + psb_intel_i2c_destroy(gma_encoder->ddc_bus);
> failed_ddc:
> printk(KERN_ERR "Failed DDC\n");
> - if (gma_encoder->i2c_bus)
> - psb_intel_i2c_destroy(gma_encoder->i2c_bus);
> + psb_intel_i2c_destroy(gma_encoder->i2c_bus);
> failed_blc_i2c:
> printk(KERN_ERR "Failed BLC\n");
> drm_encoder_cleanup(encoder);
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c
> b/drivers/gpu/drm/gma500/psb_drv.c
> index 82b8ce4..50eb944f 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -210,10 +210,8 @@ static int psb_driver_unload(struct drm_device *dev)
> iounmap(dev_priv->aux_reg);
> dev_priv->aux_reg = NULL;
> }
> - if (dev_priv->aux_pdev)
> - pci_dev_put(dev_priv->aux_pdev);
> - if (dev_priv->lpc_pdev)
> - pci_dev_put(dev_priv->lpc_pdev);
> + pci_dev_put(dev_priv->aux_pdev);
> + pci_dev_put(dev_priv->lpc_pdev);
>
> /* Destroy VBT data */
> psb_intel_destroy_bios(dev);
> diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
> b/drivers/gpu/drm/gma500/psb_intel_lvds.c
> index b1b9331..e55733c 100644
> --- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
> @@ -561,8 +561,7 @@ void psb_intel_lvds_destroy(struct drm_connector
> *connector)
> struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
> struct psb_intel_lvds_priv *lvds_priv = gma_encoder->dev_priv;
>
> - if (lvds_priv->ddc_bus)
> - psb_intel_i2c_destroy(lvds_priv->ddc_bus);
> + psb_intel_i2c_destroy(lvds_priv->ddc_bus);
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> @@ -835,11 +834,9 @@ out:
>
> failed_find:
> mutex_unlock(&dev->mode_config.mutex);
> - if (lvds_priv->ddc_bus)
> - psb_intel_i2c_destroy(lvds_priv->ddc_bus);
> + psb_intel_i2c_destroy(lvds_priv->ddc_bus);
> failed_ddc:
> - if (lvds_priv->i2c_bus)
> - psb_intel_i2c_destroy(lvds_priv->i2c_bus);
> + psb_intel_i2c_destroy(lvds_priv->i2c_bus);
> failed_blc_i2c:
> drm_encoder_cleanup(encoder);
> drm_connector_cleanup(connector);
> --
> 2.9.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/mgag200: Delete an unnecessary check before drm_gem_object_unreference_unlocked()
From: Markus Elfring
Date: Fri, 22 Jul 2016 11:20:27 +0200
The drm_gem_object_unreference_unlocked() function tests whether
its argument is NULL and then returns immediately.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/mgag200/mgag200_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 615cbb0..13798b3 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -17,8 +17,8 @@
static void mga_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct mga_framebuffer *mga_fb = to_mga_framebuffer(fb);
- if (mga_fb->obj)
- drm_gem_object_unreference_unlocked(mga_fb->obj);
+
+ drm_gem_object_unreference_unlocked(mga_fb->obj);
drm_framebuffer_cleanup(fb);
kfree(fb);
}
--
2.9.2
Re: mm/compact: why use low watermark to determine whether compact is finished instead of use high watermark?
On 2016/7/22 17:04, Vlastimil Babka wrote: > On 07/22/2016 10:56 AM, Xishi Qiu wrote: >> Hi, >> >> I find all the watermarks in mm/compaction.c are low_wmark_pages(), >> so why not use high watermark to determine whether compact is finished? > > Why would you use high watermark? Quite the opposite, I want to move towards > min watermark (precisely, the one in alloc_flags which is usually min) in > this series: > > https://lkml.org/lkml/2016/6/24/222 > > especially: > > https://lkml.org/lkml/2016/6/24/214 > >> e.g. >> __alloc_pages_nodemask() >> get_page_from_freelist() >> this is fast path, use use low_wmark_pages() in __zone_watermark_ok() >> >> __alloc_pages_slowpath() >> this is slow path, usually use min_wmark_pages() > > Yes, and compaction should be finished when allocation can succeed, so match > __alloc_pages_slowpath(). > Sounds reasonable, but now we have kcompactd which called from kswapd, so still use low wmark? Thanks, Xishi Qiu >> >> kswapd >> balance_pgdat() >> use high_wmark_pages() to determine whether zone is balanced >> >> Thanks, >> Xishi Qiu >> > > > . >
Re: [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources
On Fri, Jul 22, 2016 at 04:17:48PM +0800, Bob Liu wrote:
>
> On 07/22/2016 03:45 PM, Roger Pau Monné wrote:
> > On Thu, Jul 21, 2016 at 06:08:05PM +0800, Bob Liu wrote:
> >>
> >> On 07/21/2016 04:57 PM, Roger Pau Monné wrote:
> ..[snip]..
> +
> +static ssize_t dynamic_reconfig_device(struct blkfront_info *info,
> ssize_t count)
> +{
> +unsigned int i;
> +int err = -EBUSY;
> +
> +/*
> + * Make sure no migration in parallel, device lock is actually a
> + * mutex.
> + */
> +if (!device_trylock(&info->xbdev->dev)) {
> +pr_err("Fail to acquire dev:%s lock, may be in
> migration.\n",
> +dev_name(&info->xbdev->dev));
> +return err;
> +}
> +
> +/*
> + * Prevent new requests and guarantee no uncompleted reqs.
> + */
> +blk_mq_freeze_queue(info->rq);
> +if (part_in_flight(&info->gd->part0))
> +goto out;
> +
> +/*
> + * FrontBackend
> + * Switch to XenbusStateClosed
> + * frontend_changed():
> + * case XenbusStateClosed:
> + *
> xen_blkif_disconnect()
> + * Switch to
> XenbusStateClosed
> + * blkfront_resume():
> + * frontend_changed():
> + * reconnect
> + * Wait until XenbusStateConnected
> + */
> +info->reconfiguring = true;
> +xenbus_switch_state(info->xbdev, XenbusStateClosed);
> +
> +/* Poll every 100ms, 1 minute timeout. */
> +for (i = 0; i < 600; i++) {
> +/*
> + * Wait backend enter XenbusStateClosed,
> blkback_changed()
> + * will clear reconfiguring.
> + */
> +if (!info->reconfiguring)
> +goto resume;
> +schedule_timeout_interruptible(msecs_to_jiffies(100));
> +}
> >>>
> >>> Instead of having this wait, could you just set info->reconfiguring = 1,
> >>> set
> >>> the frontend state to XenbusStateClosed and mimic exactly what a resume
> >>> from
> >>> suspension does? blkback_changed would have to set the frontend state to
> >>> InitWait when it detects that the backend has switched to Closed, and
> >>> call
> >>> blkfront_resume.
> >>
> >>
> >> I think that won't work.
> >> In the real "resume" case, the power management system will trigger all
> >> ->resume() path.
> >> But there is no place for dynamic configuration.
> >
> > Hello,
> >
> > I think it should be possible to set info->reconfiguring and wait for the
> > backend to switch to state Closed, at that point we should call
> > blkif_resume
> > (from blkback_changed) and the backend will follow the reconection.
> >
>
> Okay, I get your point. Yes, that's an option.
>
> But this will make 'dynamic configuration' to be async, I'm worry about the
> end-user will get panic.
> E.g
> A end-user "echo > /sys/devices/vbd-xxx/max_indirect_segs",
> but then the device will be Closed and disappeared, the user have to wait for
> a random time so that the device can resume.
That should not happen, AFAICT on migration the device never dissapears.
alloc_disk and friends should not be called on resume from migration (see
the switch in blkfront_connect, you should take the BLKIF_STATE_SUSPENDED
path for the reconfiguration).
Roger.
Re: [RFC] Avoid mutex starvation when optimistic spinning is disabled
On to, 2016-07-21 at 15:29 -0700, Jason Low wrote:
> On Wed, 2016-07-20 at 14:37 -0400, Waiman Long wrote:
> > On 07/20/2016 12:39 AM, Jason Low wrote:
> > > On Tue, 2016-07-19 at 16:04 -0700, Jason Low wrote:
> > > > Hi Imre,
> > > >
> > > > Here is a patch which prevents a thread from spending too much
> > > > "time"
> > > > waiting for a mutex in the !CONFIG_MUTEX_SPIN_ON_OWNER case.
> > > >
> > > > Would you like to try this out and see if this addresses the
> > > > mutex
> > > > starvation issue you are seeing in your workload when
> > > > optimistic
> > > > spinning is disabled?
> > > Although it looks like it didn't take care of the 'lock stealing'
> > > case
> > > in the slowpath. Here is the updated fixed version:
> > >
> > > ---
> > > Signed-off-by: Jason Low
> > > ---
> > > include/linux/mutex.h | 2 ++
> > > kernel/locking/mutex.c | 65
> > > --
> > > 2 files changed, 60 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> > > index 2cb7531..c1ca68d 100644
> > > --- a/include/linux/mutex.h
> > > +++ b/include/linux/mutex.h
> > > @@ -57,6 +57,8 @@ struct mutex {
> > > #endif
> > > #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> > > struct optimistic_spin_queue osq; /* Spinner MCS lock
> > > */
> > > +#else
> > > + bool yield_to_waiter; /* Prevent starvation when
> > > spinning disabled */
> > > #endif
> > > #ifdef CONFIG_DEBUG_MUTEXES
> > > void*magic;
> >
> > You don't need that on non-SMP system. So maybe you should put it
> > under
> > #ifdef CONFIG_SMP block.
>
> Right, maybe something like:
>
> #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> ...
> ...
> #elif !defined(CONFIG_SMP) /* If optimistic spinning disabled */
> bool yield_to_waiter;
> #endif
>
> > > @@ -556,7 +595,8 @@ __mutex_lock_common(struct mutex *lock, long
> > > state, unsigned int subclass,
> > > * other waiters. We only attempt the xchg if
> > > the count is
> > > * non-negative in order to avoid unnecessary
> > > xchg operations:
> > > */
> > > - if (atomic_read(&lock->count)>= 0&&
> > > + if ((!need_yield_to_waiter(lock) || loop> 1)&&
> > > + atomic_read(&lock->count)>= 0&&
> > > (atomic_xchg_acquire(&lock->count, -1) == 1))
> > >
> >
> > I think you need to reset the yield_to_waiter variable here when
> > loop >
> > 1 instead of at the end of the loop.
>
> So I think in the current state, only the top waiter would be able to
> both set and clear the yield_to_waiter variable anyway. However, I
> agree
> that this detail is not obvious and it would be better to reset the
> variable here when loop > 1 to make it more readable.
AFAICS an interruptible waiter behind the top waiter receiving a signal
and grabbing the lock could also reset yield_to_waiter incorrectly in
that way, increasing the top waiter's delay arbitrarily.
--Imre
>
> > > break;
> > >
> > > @@ -581,6 +621,7 @@ __mutex_lock_common(struct mutex *lock, long
> > > state, unsigned int subclass,
> > > spin_unlock_mutex(&lock->wait_lock, flags);
> > > schedule_preempt_disabled();
> > > spin_lock_mutex(&lock->wait_lock, flags);
> > > + do_yield_to_waiter(lock, loop);
> > > }
> > > __set_task_state(task, TASK_RUNNING);
> > >
> > > @@ -590,6 +631,10 @@ __mutex_lock_common(struct mutex *lock, long
> > > state, unsigned int subclass,
> > > atomic_set(&lock->count, 0);
> > > debug_mutex_free_waiter(&waiter);
> > >
> > > +#ifndef CONFIG_MUTEX_SPIN_ON_OWNER
> > > + lock->yield_to_waiter = false;
> > > +#endif
> > > +
> >
> > Maybe you should do the reset in an inline function instead.
>
> Yes, this should be abstracted into a function like we do with
> do_yield_to_waiter().
>
>
> Jason
>
Re: [PATCH] Staging: media: timblogiw: File cleanup.
This driver will be removed in 4.8, so I won't take this patch.
Regards,
Hans
On 07/20/2016 08:47 PM, Jeremiah Goerdt wrote:
> Cleaned up checkpatch.pl warnings and checks.
>
> Signed-off-by: Jeremiah Goerdt
> ---
> drivers/staging/media/timb/timblogiw.c | 134
> -
> 1 file changed, 67 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/staging/media/timb/timblogiw.c
> b/drivers/staging/media/timb/timblogiw.c
> index 113c9f3..66d2898 100644
> --- a/drivers/staging/media/timb/timblogiw.c
> +++ b/drivers/staging/media/timb/timblogiw.c
> @@ -10,10 +10,6 @@
> * 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.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> */
>
> /* Supports:
> @@ -43,7 +39,6 @@
>
> #define TIMBLOGIW_HAS_DECODER(lw)(lw->pdata.encoder.module_name)
>
> -
> struct timblogiw {
> struct video_device video_dev;
> struct v4l2_device v4l2_dev; /* mutual exclusion */
> @@ -98,7 +93,6 @@ static int timblogiw_bytes_per_line(const struct
> timblogiw_tvnorm *norm)
> return norm->width * 2;
> }
>
> -
> static int timblogiw_frame_size(const struct timblogiw_tvnorm *norm)
> {
> return norm->height * timblogiw_bytes_per_line(norm);
> @@ -107,6 +101,7 @@ static int timblogiw_frame_size(const struct
> timblogiw_tvnorm *norm)
> static const struct timblogiw_tvnorm *timblogiw_get_norm(const v4l2_std_id
> std)
> {
> int i;
> +
> for (i = 0; i < ARRAY_SIZE(timblogiw_tvnorms); i++)
> if (timblogiw_tvnorms[i].std & std)
> return timblogiw_tvnorms + i;
> @@ -138,8 +133,8 @@ static void timblogiw_dma_cb(void *data)
> }
>
> if (!list_empty(&fh->capture)) {
> - vb = list_entry(fh->capture.next, struct videobuf_buffer,
> - queue);
> + vb = list_entry(
> + fh->capture.next, struct videobuf_buffer, queue);
> vb->state = VIDEOBUF_ACTIVE;
> }
>
> @@ -153,8 +148,8 @@ static bool timblogiw_dma_filter_fn(struct dma_chan
> *chan, void *filter_param)
>
> /* IOCTL functions */
>
> -static int timblogiw_g_fmt(struct file *file, void *priv,
> - struct v4l2_format *format)
> +static int timblogiw_g_fmt(
> + struct file *file, void *priv, struct v4l2_format *format)
> {
> struct video_device *vdev = video_devdata(file);
> struct timblogiw *lw = video_get_drvdata(vdev);
> @@ -179,8 +174,8 @@ static int timblogiw_g_fmt(struct file *file, void *priv,
> return 0;
> }
>
> -static int timblogiw_try_fmt(struct file *file, void *priv,
> - struct v4l2_format *format)
> +static int timblogiw_try_fmt(
> + struct file *file, void *priv, struct v4l2_format *format)
> {
> struct video_device *vdev = video_devdata(file);
> struct v4l2_pix_format *pix = &format->fmt.pix;
> @@ -204,8 +199,8 @@ static int timblogiw_try_fmt(struct file *file, void
> *priv,
> return 0;
> }
>
> -static int timblogiw_s_fmt(struct file *file, void *priv,
> - struct v4l2_format *format)
> +static int timblogiw_s_fmt(
> + struct file *file, void *priv, struct v4l2_format *format)
> {
> struct video_device *vdev = video_devdata(file);
> struct timblogiw *lw = video_get_drvdata(vdev);
> @@ -233,15 +228,17 @@ out:
> return err;
> }
>
> -static int timblogiw_querycap(struct file *file, void *priv,
> - struct v4l2_capability *cap)
> +static int timblogiw_querycap(
> + struct file *file, void *priv, struct v4l2_capability *cap)
> {
> struct video_device *vdev = video_devdata(file);
>
> dev_dbg(&vdev->dev, "%s: Entry\n", __func__);
> - strncpy(cap->card, TIMBLOGIWIN_NAME, sizeof(cap->card)-1);
> + strncpy(cap->card, TIMBLOGIWIN_NAME, sizeof(cap->card) - 1);
> strncpy(cap->driver, DRIVER_NAME, sizeof(cap->driver) - 1);
> - snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
> vdev->name);
> + snprintf(
> + cap->bus_info, sizeof(cap->bus_info),
> + "platform:%s", vdev->name);
> cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
> V4L2_CAP_READWRITE;
> cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
> @@ -249,8 +246,8 @@ static int timblogiw_querycap(struct file *file, void
> *priv,
> return 0;
> }
>
> -static int timblogiw_enum_fmt(struct file *file, void *priv,
> - struct v4l2_fmtdesc *fmt)
> +static int timblogiw_enum_fmt(
> + struct file *file, void *priv, struct v4l2_fmtdesc *fmt)
> {
> struct video_device *vdev = video_devdata(file);
>
> @@ -261,15 +258,16 @@
[PATCH v3 0/4] Add STM32 Reset Driver
From: Gabriel Fernandez v3: - Use the builtin for the register v2: - switch to the non-relaxed variants - describe dt-binfings in one place The STM32 MCUs family IPs can be reset by accessing some registers from the RCC block. Gabriel Fernandez (1): ARM: dts: stm32f429: add missing #reset-cells of rcc Maxime Coquelin (3): dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include file dt-bindings: Document the STM32 reset bindings drivers: reset: Add STM32 reset driver .../devicetree/bindings/clock/st,stm32-rcc.txt | 42 ++-- .../devicetree/bindings/reset/st,stm32-rcc.txt | 6 ++ arch/arm/boot/dts/stm32f429.dtsi | 1 + drivers/reset/Makefile | 1 + drivers/reset/reset-stm32.c| 108 + include/dt-bindings/mfd/stm32f4-rcc.h | 98 +++ 6 files changed, 249 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt create mode 100644 drivers/reset/reset-stm32.c create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h -- 1.9.1
[PATCH v3 1/4] dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include file
From: Maxime Coquelin Ths patch lists STM32F4's RCC numeric constants. It will be used by clock and reset drivers, and DT bindings. Signed-off-by: Maxime Coquelin Signed-off-by: Gabriel Fernandez --- include/dt-bindings/mfd/stm32f4-rcc.h | 98 +++ 1 file changed, 98 insertions(+) create mode 100644 include/dt-bindings/mfd/stm32f4-rcc.h diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h new file mode 100644 index 000..e98942dc --- /dev/null +++ b/include/dt-bindings/mfd/stm32f4-rcc.h @@ -0,0 +1,98 @@ +/* + * This header provides constants for the STM32F4 RCC IP + */ + +#ifndef _DT_BINDINGS_MFD_STM32F4_RCC_H +#define _DT_BINDINGS_MFD_STM32F4_RCC_H + +/* AHB1 */ +#define STM32F4_RCC_AHB1_GPIOA 0 +#define STM32F4_RCC_AHB1_GPIOB 1 +#define STM32F4_RCC_AHB1_GPIOC 2 +#define STM32F4_RCC_AHB1_GPIOD 3 +#define STM32F4_RCC_AHB1_GPIOE 4 +#define STM32F4_RCC_AHB1_GPIOF 5 +#define STM32F4_RCC_AHB1_GPIOG 6 +#define STM32F4_RCC_AHB1_GPIOH 7 +#define STM32F4_RCC_AHB1_GPIOI 8 +#define STM32F4_RCC_AHB1_GPIOJ 9 +#define STM32F4_RCC_AHB1_GPIOK 10 +#define STM32F4_RCC_AHB1_CRC 12 +#define STM32F4_RCC_AHB1_DMA1 21 +#define STM32F4_RCC_AHB1_DMA2 22 +#define STM32F4_RCC_AHB1_DMA2D 23 +#define STM32F4_RCC_AHB1_ETHMAC25 +#define STM32F4_RCC_AHB1_OTGHS 29 + +#define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8)) +#define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit + (0x30 * 8)) + + +/* AHB2 */ +#define STM32F4_RCC_AHB2_DCMI 0 +#define STM32F4_RCC_AHB2_CRYP 4 +#define STM32F4_RCC_AHB2_HASH 5 +#define STM32F4_RCC_AHB2_RNG 6 +#define STM32F4_RCC_AHB2_OTGFS 7 + +#define STM32F4_AHB2_RESET(bit)(STM32F4_RCC_AHB2_##bit + (0x14 * 8)) +#define STM32F4_AHB2_CLOCK(bit)(STM32F4_RCC_AHB2_##bit + (0x34 * 8)) + +/* AHB3 */ +#define STM32F4_RCC_AHB3_FMC 0 + +#define STM32F4_AHB3_RESET(bit)(STM32F4_RCC_AHB3_##bit + (0x18 * 8)) +#define STM32F4_AHB3_CLOCK(bit)(STM32F4_RCC_AHB3_##bit + (0x38 * 8)) + +/* APB1 */ +#define STM32F4_RCC_APB1_TIM2 0 +#define STM32F4_RCC_APB1_TIM3 1 +#define STM32F4_RCC_APB1_TIM4 2 +#define STM32F4_RCC_APB1_TIM5 3 +#define STM32F4_RCC_APB1_TIM6 4 +#define STM32F4_RCC_APB1_TIM7 5 +#define STM32F4_RCC_APB1_TIM12 6 +#define STM32F4_RCC_APB1_TIM13 7 +#define STM32F4_RCC_APB1_TIM14 8 +#define STM32F4_RCC_APB1_WWDG 11 +#define STM32F4_RCC_APB1_SPI2 14 +#define STM32F4_RCC_APB1_SPI3 15 +#define STM32F4_RCC_APB1_UART2 17 +#define STM32F4_RCC_APB1_UART3 18 +#define STM32F4_RCC_APB1_UART4 19 +#define STM32F4_RCC_APB1_UART5 20 +#define STM32F4_RCC_APB1_I2C1 21 +#define STM32F4_RCC_APB1_I2C2 22 +#define STM32F4_RCC_APB1_I2C3 23 +#define STM32F4_RCC_APB1_CAN1 25 +#define STM32F4_RCC_APB1_CAN2 26 +#define STM32F4_RCC_APB1_PWR 28 +#define STM32F4_RCC_APB1_DAC 29 +#define STM32F4_RCC_APB1_UART7 30 +#define STM32F4_RCC_APB1_UART8 31 + +#define STM32F4_APB1_RESET(bit)(STM32F4_RCC_APB1_##bit + (0x20 * 8)) +#define STM32F4_APB1_CLOCK(bit)(STM32F4_RCC_APB1_##bit + (0x40 * 8)) + +/* APB2 */ +#define STM32F4_RCC_APB2_TIM1 0 +#define STM32F4_RCC_APB2_TIM8 1 +#define STM32F4_RCC_APB2_USART14 +#define STM32F4_RCC_APB2_USART65 +#define STM32F4_RCC_APB2_ADC 8 +#define STM32F4_RCC_APB2_SDIO 11 +#define STM32F4_RCC_APB2_SPI1 12 +#define STM32F4_RCC_APB2_SPI4 13 +#define STM32F4_RCC_APB2_SYSCFG14 +#define STM32F4_RCC_APB2_TIM9 16 +#define STM32F4_RCC_APB2_TIM10 17 +#define STM32F4_RCC_APB2_TIM11 18 +#define STM32F4_RCC_APB2_SPI5 20 +#define STM32F4_RCC_APB2_SPI6 21 +#define STM32F4_RCC_APB2_SAI1 22 +#define STM32F4_RCC_APB2_LTDC 26 + +#define STM32F4_APB2_RESET(bit)(STM32F4_RCC_APB2_##bit + (0x24 * 8)) +#define STM32F4_APB2_CLOCK(bit)(STM32F4_RCC_APB2_##bit + (0x44 * 8)) + +#endif /* _DT_BINDINGS_MFD_STM32F4_RCC_H */ -- 1.9.1
[PATCH v3 4/4] ARM: dts: stm32f429: add missing #reset-cells of rcc
From: Gabriel Fernandez
This patch adds #reset-cells property to rcc node.
Signed-off-by: Gabriel Fernandez
---
arch/arm/boot/dts/stm32f429.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 35df462..fe89236 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -326,6 +326,7 @@
};
rcc: rcc@40023810 {
+ #reset-cells = <1>;
#clock-cells = <2>;
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
reg = <0x40023800 0x400>;
--
1.9.1
Re: [v6 PATCH 1/6] extcon: Add Type-C and DP support
Hi Chanwoo Choi
Thanks for your help, I am going to post V7 next week base on these
latest extcon patch.
Regards
Chris Zhong
On 07/22/2016 05:29 PM, Chanwoo Choi wrote:
Hi Chris,
I'm sorry for late reply. I finished the first draft to support the extcon
property.
You can check the patches[1]. But, I need more time to test it. After tested it,
I'll send the patches.
[1]
https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-test
Chanwoo Choi (4):
extcon: Add the extcon_type to group each connector into five category
extcon: Add the support for extcon property according to type of connector
extcon: Rename the extcon_set/get_state() to maintain the function naming
pattern
extcon: Add the sync APIs to support the notification for extcon property
Chris Zhong (1):
extcon: Add EXTCON_DISP_DP and the property for USB Type-C
Regards,
Chanwoo Choi
On 2016년 07월 21일 22:13, Chris Zhong wrote:
Add EXTCON_DISP_DP for the Display external connector. For Type-C
connector the DisplayPort can work as an Alternate Mode(VESA DisplayPort
Alt Mode on USB Type-C Standard). The Type-C support both normal and
flipped orientation, so add a property to extcon.
Signe-off-by: Chris Zhong
Signed-off-by: Chris Zhong
---
Changes in v6:
- move the EXTCON_PROP_TYPEC_POLARITY to EXTCON_TYPE_USB in _supported
Series-changes: 5
- support get property
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None
drivers/extcon/extcon.c | 26 ++
include/linux/extcon.h | 13 +
2 files changed, 39 insertions(+)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index a1117db..f79b510 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -157,6 +157,11 @@ struct __extcon_info {
.id = EXTCON_DISP_VGA,
.name = "VGA",
},
+ [EXTCON_DISP_DP] = {
+ .type = EXTCON_TYPE_DISP | EXTCON_TYPE_USB,
+ .id = EXTCON_DISP_DP,
+ .name = "DP",
+ },
/* Miscellaneous external connector */
[EXTCON_DOCK] = {
@@ -270,6 +275,7 @@ static bool is_extcon_property_supported(unsigned int id,
switch (prop) {
case EXTCON_PROP_USB_ID:
case EXTCON_PROP_USB_VBUS:
+ case EXTCON_PROP_TYPEC_POLARITY:
return true;
default:
break;
@@ -547,6 +553,26 @@ int extcon_get_cable_property(struct extcon_dev *edev,
unsigned int id,
enum extcon_property prop,
union extcon_property_value *val)
{
+ struct extcon_cable *cable;
+ int index;
+
+ if (!edev)
+ return -EINVAL;
+
+ /* Check the property whether is supported or not */
+ if (!is_extcon_property_supported(id, prop))
+ return -EINVAL;
+
+ /* Find the cable index of external connector by using id */
+ index = find_cable_index_by_id(edev, id);
+ if (index < 0)
+ return index;
+
+ /* Store the property value */
+ cable = &edev->cables[index];
+
+ val->intval = cable->propval[prop].intval;
+
return 0;
}
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index f6f0a8d..50ef87f 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -77,6 +77,7 @@ enum extcon_type {
#define EXTCON_DISP_MHL 41 /* Mobile High-Definition Link
*/
#define EXTCON_DISP_DVI 42 /* Digital Visual Interface */
#define EXTCON_DISP_VGA 43 /* Video Graphics Array */
+#define EXTCON_DISP_DP 44 /* DisplayPort */
/* Miscellaneous external connector */
#define EXTCON_DOCK 60
@@ -108,9 +109,13 @@ enum extcon_property {
* - EXTCON_PROP_USB_USB
* @type: integer (int value)
* @value: 0 (low) or 1 (high)
+* - EXTCON_PROP_TYPEC_POLARITY,
+* @type: integer (int value)
+* @value: 0 (normal) or 1 (flip)
*/
EXTCON_PROP_USB_ID = 0,
EXTCON_PROP_USB_VBUS,
+ EXTCON_PROP_TYPEC_POLARITY,
/* Properties of EXTCON_TYPE_CHG. */
/* Properties of EXTCON_TYPE_JACK. */
@@ -225,6 +230,14 @@ extern int extcon_get_cable_state_(struct extcon_dev
*edev, unsigned int id);
extern int extcon_set_cable_state_(struct extcon_dev *edev, unsigned int id,
bool cable_state);
+extern int extcon_get_cable_property(struct extcon_dev *edev, unsigned int id,
+enum extcon_property prop,
+union extcon_property_value *val);
+
+extern int extcon_set_cable_property(struct extcon_dev *edev, unsigned int id,
+enum extcon_property prop,
+
RE: [PATCH v4 2/2] ACPI / button: Add document for ACPI control method lid device restrictions
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> On Fri, Jul 22, 2016 at 10:47 AM, Zheng, Lv wrote:
> > Hi,
> >
> >> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> >> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI
> control
> >> method lid device restrictions
> >>
> >> On Fri, Jul 22, 2016 at 6:37 AM, Dmitry Torokhov
> >> wrote:
> >> > Hi Lv,
> >> >
> >> > On Fri, Jul 22, 2016 at 12:24:50AM +, Zheng, Lv wrote:
> >> >> Hi, Dmitry
> >> >>
> >> >>
> >> >> Thanks for the review.
> >> >>
> >> >> > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> >> >> > Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI
> >> control
> >> >> > method lid device restrictions
> >> >> >
> >> >> > On Tue, Jul 19, 2016 at 04:11:21PM +0800, Lv Zheng wrote:
> >> >> > > This patch adds documentation for the usage model of the
> control
> >> >> > method lid
> >> >> > > device.
> >> >> > >
> >> >> > > Signed-off-by: Lv Zheng
> >> >> > > Cc: Dmitry Torokhov
> >> >> > > Cc: Benjamin Tissoires
> >> >> > > Cc: Bastien Nocera:
> >> >> > > Cc: linux-in...@vger.kernel.org
> >> >> > > ---
> >> >> > > Documentation/acpi/acpi-lid.txt | 89
> >> >> > +++
> >> >> > > 1 file changed, 89 insertions(+)
> >> >> > > create mode 100644 Documentation/acpi/acpi-lid.txt
> >> >> > >
> >> >> > > diff --git a/Documentation/acpi/acpi-lid.txt
> >> b/Documentation/acpi/acpi-
> >> >> > lid.txt
> >> >> > > new file mode 100644
> >> >> > > index 000..2addedc
> >> >> > > --- /dev/null
> >> >> > > +++ b/Documentation/acpi/acpi-lid.txt
> >> >> > > @@ -0,0 +1,89 @@
> >> >> > > +Usage Model of the ACPI Control Method Lid Device
> >> >> > > +
> >> >> > > +Copyright (C) 2016, Intel Corporation
> >> >> > > +Author: Lv Zheng
> >> >> > > +
> >> >> > > +
> >> >> > > +Abstract:
> >> >> > > +
> >> >> > > +Platforms containing lids convey lid state (open/close) to
> OSPMs
> >> using
> >> >> > a
> >> >> > > +control method lid device. To implement this, the AML tables
> issue
> >> >> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> >> state has
> >> >> > > +changed. The _LID control method for the lid device must be
> >> >> > implemented to
> >> >> > > +report the "current" state of the lid as either "opened" or
> "closed".
> >> >> > > +
> >> >> > > +This document describes the restrictions and the expections of
> the
> >> >> > Linux
> >> >> > > +ACPI lid device driver.
> >> >> > > +
> >> >> > > +
> >> >> > > +1. Restrictions of the returning value of the _LID control
> method
> >> >> > > +
> >> >> > > +The _LID control method is described to return the "current" lid
> >> state.
> >> >> > > +However the word of "current" has ambiguity, many AML
> tables
> >> return
> >> >> > the lid
> >> >> >
> >> >> > Can this be fixed in the next ACPI revision?
> >> >> [Lv Zheng]
> >> >> Even this is fixed in the ACPI specification, there are platforms
> already
> >> doing this.
> >> >> Especially platforms from Microsoft.
> >> >> So the de-facto standard OS won't care about the change.
> >> >> And we can still see such platforms.
> >> >>
> >> >> Here is an example from Surface 3:
> >> >>
> >> >> DefinitionBlock ("dsdt.aml", "DSDT", 2, "ALASKA", "A M I ",
> 0x01072009)
> >> >> {
> >> >> Scope (_SB)
> >> >> {
> >> >> Device (PCI0)
> >> >> {
> >> >> Name (_HID, EisaId ("PNP0A08")) // _HID: Hardware ID
> >> >> Name (_CID, EisaId ("PNP0A03")) // _CID: Compatible ID
> >> >> Device (SPI1)
> >> >> {
> >> >> Name (_HID, "8086228E") // _HID: Hardware ID
> >> >> Device (NTRG)
> >> >> {
> >> >> Name (_HID, "MSHW0037") // _HID: Hardware ID
> >> >> }
> >> >> }
> >> >> }
> >> >>
> >> >> Device (LID)
> >> >> {
> >> >> Name (_HID, EisaId ("PNP0C0D"))
> >> >> Name (LIDB, Zero)
> >> >
> >> > Start with lid closed? In any case might be wrong.
> >>
> >> Actually the initial value doesn't matter if the gpiochip triggers the
> >> _EC4 at boot, which it should
> >> (https://github.com/hadess/fedora-surface3-
> >> kernel/commit/13200f81662c1c0b58137947c3e6c000fe62a2ba,
> >> still unsubmitted)
> >>
> >> >
> >> >> Method (_LID, 0, NotSerialized)
> >> >> {
> >> >> Return (LIDB)
> >> >
> >> > So "_LID" returns the last state read by "_EC4". "_EC4" is
> >> > edge-triggered and will be evaluated every time gpio changes state.
> >>
> >> That's assuming the change happens while the system is on. If you go
> >> into suspend by closing the LID. Open it while on suspend and then hit
> >> the power button given that the system doesn't wake up when the lid
> is
> >> opened, the edge change was made while t
[PATCH v3 2/4] dt-bindings: Document the STM32 reset bindings
From: Maxime Coquelin
This adds documentation of device tree bindings for the
STM32 reset controller.
Signed-off-by: Maxime Coquelin
Signed-off-by: Gabriel Fernandez
Acked-by: Rob Herring
---
.../devicetree/bindings/clock/st,stm32-rcc.txt | 42 ++
.../devicetree/bindings/reset/st,stm32-rcc.txt | 6
2 files changed, 41 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
index fee3205..c209de6 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
+++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
@@ -1,16 +1,16 @@
STMicroelectronics STM32 Reset and Clock Controller
===
-The RCC IP is both a reset and a clock controller. This documentation only
-describes the clock part.
+The RCC IP is both a reset and a clock controller.
-Please also refer to clock-bindings.txt in this directory for common clock
-controller binding usage.
+Please refer to clock-bindings.txt for common clock controller binding usage.
+Please also refer to reset.txt for common reset controller binding usage.
Required properties:
- compatible: Should be "st,stm32f42xx-rcc"
- reg: should be register base and length as documented in the
datasheet
+- #reset-cells: 1, see below
- #clock-cells: 2, device nodes should specify the clock in their "clocks"
property, containing a phandle to the clock device node, an index selecting
between gated clocks and other clocks and an index specifying the clock to
@@ -19,6 +19,7 @@ Required properties:
Example:
rcc: rcc@40023800 {
+ #reset-cells = <1>;
#clock-cells = <2>
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
reg = <0x40023800 0x400>;
@@ -35,16 +36,23 @@ from the first RCC clock enable register (RCC_AHB1ENR,
address offset 0x30).
It is calculated as: index = register_offset / 4 * 32 + bit_offset.
Where bit_offset is the bit offset within the register (LSB is 0, MSB is 31).
+To simplify the usage and to share bit definition with the reset and clock
+drivers of the RCC IP, macros are available to generate the index in
+human-readble format.
+
+For STM32F4 series, the macro are available here:
+ - include/dt-bindings/mfd/stm32f4-rcc.h
+
Example:
/* Gated clock, AHB1 bit 0 (GPIOA) */
... {
- clocks = <&rcc 0 0>
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOA)>
};
/* Gated clock, AHB2 bit 4 (CRYP) */
... {
- clocks = <&rcc 0 36>
+ clocks = <&rcc 0 STM32F4_AHB2_CLOCK(CRYP)>
};
Specifying other clocks
@@ -61,5 +69,25 @@ Example:
/* Misc clock, FCLK */
... {
- clocks = <&rcc 1 1>
+ clocks = <&rcc 1 STM32F4_APB1_CLOCK(TIM2)>
+ };
+
+
+Specifying softreset control of devices
+===
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the reset device node and an index specifying
+which channel to use.
+The index is the bit number within the RCC registers bank, starting from RCC
+base address.
+It is calculated as: index = register_offset / 4 * 32 + bit_offset.
+Where bit_offset is the bit offset within the register.
+For example, for CRC reset:
+ crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
+
+example:
+
+ timer2 {
+ resets = <&rcc STM32F4_APB1_RESET(TIM2)>;
};
diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
new file mode 100644
index 000..01db343
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
@@ -0,0 +1,6 @@
+STMicroelectronics STM32 Peripheral Reset Controller
+
+
+The RCC IP is both a reset and a clock controller.
+
+Please see Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
--
1.9.1
[PATCH v3 3/4] drivers: reset: Add STM32 reset driver
From: Maxime Coquelin
The STM32 MCUs family IPs can be reset by accessing some registers
from the RCC block.
The list of available reset lines is documented in the DT bindings.
Signed-off-by: Maxime Coquelin
Signed-off-by: Gabriel Fernandez
---
drivers/reset/Makefile | 1 +
drivers/reset/reset-stm32.c | 108
2 files changed, 109 insertions(+)
create mode 100644 drivers/reset/reset-stm32.c
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 5d65a93..64ebb0c 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
obj-$(CONFIG_ARCH_MESON) += reset-meson.o
+obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
obj-$(CONFIG_ARCH_HISI) += hisilicon/
diff --git a/drivers/reset/reset-stm32.c b/drivers/reset/reset-stm32.c
new file mode 100644
index 000..3a7c8527
--- /dev/null
+++ b/drivers/reset/reset-stm32.c
@@ -0,0 +1,108 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * Heavily based on sunxi driver from Maxime Ripard.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct stm32_reset_data {
+ spinlock_t lock;
+ void __iomem*membase;
+ struct reset_controller_dev rcdev;
+};
+
+static int stm32_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct stm32_reset_data *data = container_of(rcdev,
+struct stm32_reset_data,
+rcdev);
+ int bank = id / BITS_PER_LONG;
+ int offset = id % BITS_PER_LONG;
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ reg = readl(data->membase + (bank * 4));
+ writel(reg | BIT(offset), data->membase + (bank * 4));
+
+ spin_unlock_irqrestore(&data->lock, flags);
+
+ return 0;
+}
+
+static int stm32_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct stm32_reset_data *data = container_of(rcdev,
+struct stm32_reset_data,
+rcdev);
+ int bank = id / BITS_PER_LONG;
+ int offset = id % BITS_PER_LONG;
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ reg = readl(data->membase + (bank * 4));
+ writel(reg & ~BIT(offset), data->membase + (bank * 4));
+
+ spin_unlock_irqrestore(&data->lock, flags);
+
+ return 0;
+}
+
+static const struct reset_control_ops stm32_reset_ops = {
+ .assert = stm32_reset_assert,
+ .deassert = stm32_reset_deassert,
+};
+
+static const struct of_device_id stm32_reset_dt_ids[] = {
+{ .compatible = "st,stm32-rcc", },
+{ /* sentinel */ },
+};
+
+static int stm32_reset_probe(struct platform_device *pdev)
+{
+ struct stm32_reset_data *data;
+ struct resource *res;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->membase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->membase))
+ return PTR_ERR(data->membase);
+
+ spin_lock_init(&data->lock);
+
+ data->rcdev.owner = THIS_MODULE;
+ data->rcdev.nr_resets = resource_size(res) * 8;
+ data->rcdev.ops = &stm32_reset_ops;
+ data->rcdev.of_node = pdev->dev.of_node;
+
+ return devm_reset_controller_register(&pdev->dev, &data->rcdev);
+}
+
+static struct platform_driver stm32_reset_driver = {
+ .probe = stm32_reset_probe,
+ .driver = {
+ .name = "stm32-rcc-reset",
+ .of_match_table = stm32_reset_dt_ids,
+ },
+};
+builtin_platform_driver(stm32_reset_driver);
--
1.9.1
Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()
On 22.07.2016 09:20, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 21 Jul 2016, Chunhui He wrote:
>
>> If neigh entry was CONNECTED and address is not changed, and if new state is
>> STALE, entry state will not change. Because DELAY is not in CONNECTED, it's
>> possible to change state from DELAY to STALE.
>>
>> That is bad. Consider a host in IPv4 nerwork, a neigh entry in STALE state
>> is referenced to send packets, so goes to DELAY state. If the entry is not
>> confirmed by upper layer, it goes to PROBE state, and sends ARP request.
>> The neigh host sends ARP reply, then the entry goes to REACHABLE state.
>> But the entry state may be reseted to STALE by broadcast ARP packets, before
>> the entry goes to PROBE state. So it's possible that the entry will never go
>> to REACHABLE state, without external confirmation.
>>
>> In my case, the gateway refuses to send unicast packets to me, before it sees
>> my ARP request. So it's critical to enter REACHABLE state by sending ARP
>> request, but not by external confirmation.
>>
>> This fixes neigh_update() not to change to STALE if old state is CONNECTED or
>> DELAY.
>>
>> Signed-off-by: Chunhui He
>> ---
>> net/core/neighbour.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
>> index 510cd62..29429eb 100644
>> --- a/net/core/neighbour.c
>> +++ b/net/core/neighbour.c
>> @@ -1152,7 +1152,7 @@ int neigh_update(struct neighbour *neigh, const u8
>> *lladdr, u8 new,
>> } else {
>> if (lladdr == neigh->ha && new == NUD_STALE &&
>> ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
>> - (old & NUD_CONNECTED))
>> + (old & (NUD_CONNECTED | NUD_DELAY)))
>> )
>> new = old;
>> }
>
> You change looks correct to me. But this place
> has more problems. There is no good reason to set NUD_STALE
> for any state that is NUD_VALID if address is not changed.
> This matches perfectly the comment above this code:
> NUD_STALE should change a NUD_VALID state only when
> address changes. It also means that IPv6 does not need
> to provide NEIGH_UPDATE_F_WEAK_OVERRIDE anymore when
> NEIGH_UPDATE_F_OVERRIDE is also present.
>
> By this way the state machine can continue with
> the resolving: NUD_STALE -> NUD_DELAY (traffic) ->
> NUD_PROBE (retries) -> NUD_REACHABLE (unicast reply)
> while the address is not changed. Your change covers only
> NUD_DELAY, not NUD_PROBE, so it is better to allow more
> retries to send. We should not give up until success (NUD_REACHABLE).
>
> Second problem: NEIGH_UPDATE_F_WEAK_OVERRIDE has no
> priority over NEIGH_UPDATE_F_ADMIN. For example, now I can not
> change from NUD_PERMANENT to NUD_STALE:
>
> # ip neigh add 192.168.168.111 lladdr 00:11:22:33:44:55 nud perm dev wlan0
> # ip neigh show to 192.168.168.111
> 192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT
> # ip neigh change 192.168.168.111 lladdr 00:11:22:33:44:55 nud stale dev wlan0
> # ip neigh show to 192.168.168.111
> 192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT
>
> IMHO, here is how this place should look:
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 5cdc62a..2b1cb91 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -1151,10 +1151,8 @@ int neigh_update(struct neighbour *neigh, const u8
> *lladdr, u8 new,
> goto out;
> } else {
> if (lladdr == neigh->ha && new == NUD_STALE &&
> - ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
> - (old & NUD_CONNECTED))
> - )
> - new = old;
> + !(flags & NEIGH_UPDATE_F_ADMIN))
> + goto out;
> }
> }
>
> Any thoughts?
This change makes perfectly sense to me.
Reviewed-by: Hannes Frederic Sowa
Thanks,
Hannes
Re: [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources
On 07/22/2016 05:34 PM, Roger Pau Monné wrote:
> On Fri, Jul 22, 2016 at 04:17:48PM +0800, Bob Liu wrote:
>>
>> On 07/22/2016 03:45 PM, Roger Pau Monné wrote:
>>> On Thu, Jul 21, 2016 at 06:08:05PM +0800, Bob Liu wrote:
On 07/21/2016 04:57 PM, Roger Pau Monné wrote:
>> ..[snip]..
>> +
>> +static ssize_t dynamic_reconfig_device(struct blkfront_info *info,
>> ssize_t count)
>> +{
>> +unsigned int i;
>> +int err = -EBUSY;
>> +
>> +/*
>> + * Make sure no migration in parallel, device lock is actually a
>> + * mutex.
>> + */
>> +if (!device_trylock(&info->xbdev->dev)) {
>> +pr_err("Fail to acquire dev:%s lock, may be in
>> migration.\n",
>> +dev_name(&info->xbdev->dev));
>> +return err;
>> +}
>> +
>> +/*
>> + * Prevent new requests and guarantee no uncompleted reqs.
>> + */
>> +blk_mq_freeze_queue(info->rq);
>> +if (part_in_flight(&info->gd->part0))
>> +goto out;
>> +
>> +/*
>> + * FrontBackend
>> + * Switch to XenbusStateClosed
>> + * frontend_changed():
>> + * case XenbusStateClosed:
>> + *
>> xen_blkif_disconnect()
>> + * Switch to
>> XenbusStateClosed
>> + * blkfront_resume():
>> + * frontend_changed():
>> + * reconnect
>> + * Wait until XenbusStateConnected
>> + */
>> +info->reconfiguring = true;
>> +xenbus_switch_state(info->xbdev, XenbusStateClosed);
>> +
>> +/* Poll every 100ms, 1 minute timeout. */
>> +for (i = 0; i < 600; i++) {
>> +/*
>> + * Wait backend enter XenbusStateClosed,
>> blkback_changed()
>> + * will clear reconfiguring.
>> + */
>> +if (!info->reconfiguring)
>> +goto resume;
>> +schedule_timeout_interruptible(msecs_to_jiffies(100));
>> +}
>
> Instead of having this wait, could you just set info->reconfiguring = 1,
> set
> the frontend state to XenbusStateClosed and mimic exactly what a resume
> from
> suspension does? blkback_changed would have to set the frontend state to
> InitWait when it detects that the backend has switched to Closed, and
> call
> blkfront_resume.
I think that won't work.
In the real "resume" case, the power management system will trigger all
->resume() path.
But there is no place for dynamic configuration.
>>>
>>> Hello,
>>>
>>> I think it should be possible to set info->reconfiguring and wait for the
>>> backend to switch to state Closed, at that point we should call
>>> blkif_resume
>>> (from blkback_changed) and the backend will follow the reconection.
>>>
>>
>> Okay, I get your point. Yes, that's an option.
>>
>> But this will make 'dynamic configuration' to be async, I'm worry about the
>> end-user will get panic.
>> E.g
>> A end-user "echo > /sys/devices/vbd-xxx/max_indirect_segs",
>> but then the device will be Closed and disappeared, the user have to wait
>> for a random time so that the device can resume.
>
> That should not happen, AFAICT on migration the device never dissapears.
Oh, yes.
> alloc_disk and friends should not be called on resume from migration (see
> the switch in blkfront_connect, you should take the BLKIF_STATE_SUSPENDED
> path for the reconfiguration).
>
What about if the end-user starts I/O immediately after writing new value to
/sys?
But the resume is still in progress.
--
Regards,
-Bob
Re: [PATCH] update sc->nr_reclaimed after each shrink_slab
On Fri, Jul 22, 2016 at 09:49:13AM +0200, Michal Hocko wrote: > On Fri 22-07-16 11:43:30, Zhou Chengming wrote: > > In !global_reclaim(sc) case, we should update sc->nr_reclaimed after each > > shrink_slab in the loop. Because we need the correct sc->nr_reclaimed > > value to see if we can break out. > > Does this actually change anything? Maybe I am missing something but > try_to_free_mem_cgroup_pages which is the main entry for the memcg > reclaim doesn't set reclaim_state. I don't remember why... Vladimir? We don't set reclaim_state on memcg reclaim, because there might be a lot of unrelated slab objects freed from the interrupt context (e.g. RCU freed) while we're doing memcg reclaim. Obviously, we don't want them to contribute to nr_reclaimed. Link to the thread with the problem discussion: http://marc.info/?l=linux-kernel&m=142132698209680&w=2
Re: [alsa-devel] [PATCH v4 4/4] ASoC: samsung: Add machine driver for Exynos5433 based TM2 board
On Tue, Jul 05, 2016 at 07:14:37PM +0200, Sylwester Nawrocki wrote:
> This patch adds the sound machine driver for TM2 and TM2E board.
> Speaker and headphone playback, Main Mic capture, Bluetooth,
> Voice call and external accessory are supported.
>
> Signed-off-by: Inha Song
> [k.kozlowski: rebased on 4.1]
> Signed-off-by: Krzysztof Kozlowski
> [s.nawrocki: rebased to 4.7, adjustment to the ASoC core changes,
> removed unused ops and direct calls to the max98504 function,
> added parsing of "audio-amplifier" and "audio-codec"
> properties, added TDM API calls, switched to gpiod API]
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes since v3:
> - removed SND_SOC_SAMSUNG_AUDSS from Kconfig.
>
> Changes since v2:
> - added missing Kconfig dependencies.
>
> Changes since initial version:
> - added PDM Tx channels setup through TDM API
> - adaptation to renamed 'samsung,model', 'samsung,i2s-controller',
>'samsung,speaker-amplifier' properties,
> - removed some dev_dbg() calls,
> - cleaned up mic-bias GPIO handling and switched to gpiod API,
> - added parsing of 'audio-codec' property,
> - initialized codec_of_node of dai_link instead of codec_name,
> - switched to using clock, clock-names properties from the wm5110
>codec node,
> - fixed error paths in probe() (of_node reference counting).
> ---
Apologies for my late response I had missed this.
> +static int tm2_start_sysclk(struct snd_soc_card *card)
> +{
> + struct tm2_machine_priv *priv = snd_soc_card_get_drvdata(card);
> + struct snd_soc_codec *codec = priv->codec;
> + unsigned long mclk_rate = clk_get_rate(priv->codec_mclk1);
> + int ret;
> +
> + ret = clk_prepare_enable(priv->codec_mclk1);
> + if (ret < 0) {
> + dev_err(card->dev, "Failed to enable mclk: %d\n", ret);
> + return ret;
> + }
> +
> + ret = snd_soc_codec_set_pll(codec, WM5110_FLL1,
> + ARIZONA_FLL_SRC_MCLK1,
> + mclk_rate,
> + priv->sysclk_rate);
> + if (ret < 0) {
> + dev_err(codec->dev, "Failed to start FLL: %d\n", ret);
> + return ret;
> + }
> +
> + ret = snd_soc_codec_set_pll(codec, WM5110_FLL1_REFCLK,
> + ARIZONA_FLL_SRC_MCLK1,
> + mclk_rate,
> + priv->sysclk_rate);
> + if (ret < 0) {
> + dev_err(codec->dev, "Failed to set FLL1 Source: %d\n", ret);
> + return ret;
> + }
It would be better to set the REFCLK first. Setting WM5110_FLL1
actually enables the FLL, where as setting WM5110_FLL1_REFCKL
doesn't. So doing it this way round the first time you bring
up the FLL it will enable it then reconfigure the reference
path. Doing it the other way round it will always enable first
time with the correct settings.
> +
> + ret = snd_soc_codec_set_sysclk(codec, ARIZONA_CLK_SYSCLK,
> +ARIZONA_CLK_SRC_FLL1,
> +priv->sysclk_rate,
> +SND_SOC_CLOCK_IN);
> + if (ret < 0) {
> + dev_err(codec->dev, "Failed to set SYSCLK Source: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int tm2_aif1_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct snd_soc_dai *codec_dai = rtd->codec_dai;
> + struct snd_soc_codec *codec = rtd->codec;
> + struct tm2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
> + int ret;
> +
> + switch (params_rate(params)) {
> + case 4000:
> + case 8000:
> + case 12000:
> + case 16000:
> + case 24000:
> + case 32000:
> + case 48000:
> + case 96000:
> + case 192000:
> + /* Highest possible SYSCLK frequency: 147.456MHz */
> + priv->sysclk_rate = 147456000U;
> + break;
> + case 11025:
> + case 22050:
> + case 44100:
> + case 88200:
> + case 176400:
> + /* Highest possible SYSCLK frequency: 135.4752 MHz */
> + priv->sysclk_rate = 135475200U;
> + break;
> + default:
> + dev_err(codec->dev, "Not supported sample rate: %d\n",
> + params_rate(params));
> + return -EINVAL;
> + }
> +
> + ret = snd_soc_dai_set_sysclk(codec_dai, ARIZONA_CLK_SYSCLK, 0, 0);
> + if (ret < 0) {
> + dev_err(codec_dai->dev, "Failed to set SYSCLK: %d\n", ret);
> + return ret;
> + }
If there is no intention to change which clocking domain the DAI
is attached to I would put this in late probe, although it does
no harm here and if that might get added in the future then here
is better.
> +
> + return tm2_start_sysclk(rtd->card);
>
Re: [PATCH v4 1/2] bpf: Add bpf_probe_write BPF helper to be called in tracers (kprobes)
On 07/22/2016 04:14 AM, Alexei Starovoitov wrote:
On Thu, Jul 21, 2016 at 06:09:17PM -0700, Sargun Dhillon wrote:
This allows user memory to be written to during the course of a kprobe.
It shouldn't be used to implement any kind of security mechanism
because of TOC-TOU attacks, but rather to debug, divert, and
manipulate execution of semi-cooperative processes.
Although it uses probe_kernel_write, we limit the address space
the probe can write into by checking the space with access_ok.
This is so the call doesn't sleep.
Given this feature is experimental, and has the risk of crashing
the system, we print a warning on invocation.
It was tested with the tracex7 program on x86-64.
Signed-off-by: Sargun Dhillon
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
---
include/uapi/linux/bpf.h | 12
kernel/bpf/verifier.c | 9 +
kernel/trace/bpf_trace.c | 37 +
samples/bpf/bpf_helpers.h | 2 ++
4 files changed, 60 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 2b7076f..4536282 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -365,6 +365,18 @@ enum bpf_func_id {
*/
BPF_FUNC_get_current_task,
+ /**
+* bpf_probe_write(void *dst, void *src, int len)
+* safely attempt to write to a location
+* @dst: destination address in userspace
+* @src: source address on stack
+* @len: number of bytes to copy
+* Return:
+* Returns number of bytes that could not be copied.
+* On success, this will be zero
that is odd comment.
there are only three possible return values 0, -EFAULT, -EPERM
Agree.
+*/
+ BPF_FUNC_probe_write,
+
__BPF_FUNC_MAX_ID,
};
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index f72f23b..6785008 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1154,6 +1154,15 @@ static int check_call(struct verifier_env *env, int
func_id)
return -EINVAL;
}
+ if (func_id == BPF_FUNC_probe_write) {
+
pr_warn_once("\n");
+ pr_warn_once("* bpf_probe_write: Experimental Feature in use
*\n");
+ pr_warn_once("* bpf_probe_write: Feature may corrupt memory
*\n");
+
pr_warn_once("\n");
+ pr_notice_ratelimited("bpf_probe_write in use by: %.16s-%d",
+ current->comm, task_pid_nr(current));
+ }
I think single line pr_notice_ratelimited() with 'feature may corrupt user
memory'
will be enough.
Agree.
Also please move this to tracing specific part into bpf_trace.c
similar to bpf_get_trace_printk_proto() instead of verifier.c
Yes, sorry for not being too clear about it, this spot will then be
called by the verifier to fetch it for every function call. Meaning that
this could get printed multiple times for loading a single program, but
I think it's okay. If single line, I'd make that pr_warn_ratelimited(),
and probably something like ...
"note: %s[%d] is installing a program with bpf_probe_write helper that may corrupt
user memory!",
current->comm, task_pid_nr(current)
+static u64 bpf_probe_write(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+ void *unsafe_ptr = (void *) (long) r1;
+ void *src = (void *) (long) r2;
+ int size = (int) r3;
+ struct task_struct *task = current;
+
+ /*
bpf_trace.c follows non-net comment style, so it's good here.
just distracting vs the rest of net style.
+* Ensure we're in a user context which it is safe for the helper
+* to run. This helper has no business in a kthread
+*
+* access_ok should prevent writing to non-user memory, but on
+* some architectures (nommu, etc...) access_ok isn't enough
+* So we check the current segment
+*/
+
+ if (unlikely(in_interrupt() || (task->flags & PF_KTHREAD)))
+ return -EPERM;
Should we also add a check for !PF_EXITING ?
Like signals are not delivered to such tasks and I'm not sure
what would be the state of mm of it.
I agree, good point.
You can make that 'current->flags & (PF_KTHREAD | PF_EXITING)' and
we don't need the extra task var either.
+ if (unlikely(segment_eq(get_fs(), KERNEL_DS)))
+ return -EPERM;
+ if (!access_ok(VERIFY_WRITE, unsafe_ptr, size))
+ return -EPERM;
+
+ return probe_kernel_write(unsafe_ptr, src, size);
+}
+
+static const struct bpf_func_proto bpf_probe_write_proto = {
+ .func = bpf_probe_write,
+ .gpl_only = true,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_ANYTHING,
+ .arg2_type = ARG_PTR_TO_STACK,
+ .arg3_type = ARG_CONST_STACK_SIZE,
I have 2nd thoughts on naming.
I think 'consistency' w
Re: [PATCH resend v2 3/5] libata-scsi: use u8 array to store mode page copy
Hello.
On 7/22/2016 2:29 AM, tom.t...@gmail.com wrote:
From: Tom Yan
ata_mselect_*() would initialize a char array for storing a copy of
the current mode page. However, char could be signed char. In that
case, bytes larger than 127 would be converted to negative number.
For example, 0xff from def_control_mpage[] would become -1. This
prevented ata_mselect_control() from working at all, since when it
did the read-only bits check, there would always be a mismatch.
Signed-off-by: Tom Yan
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 4a4e6f1..a28e2ea94 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3610,7 +3610,7 @@ static int ata_mselect_caching(struct ata_queued_cmd *qc,
{
struct ata_taskfile *tf = &qc->tf;
struct ata_device *dev = qc->dev;
- char mpage[CACHE_MPAGE_LEN];
+ u8 mpage[CACHE_MPAGE_LEN];
u8 wce, mask;
int i;
@@ -3668,7 +3668,7 @@ static int ata_mselect_control(struct ata_queued_cmd *qc,
const u8 *buf, int len, u16 *fp)
{
struct ata_device *dev = qc->dev;
- char mpage[CONTROL_MPAGE_LEN];
+u8 mpage[CONTROL_MPAGE_LEN];
Indent with tabs please, as above.
[...]
MBR, Sergei
Re: [PATCH v3 1/7] firmware: rockchip: sip: Add rockchip SIP runtime service
Hi,
Am Freitag, 22. Juli 2016, 17:07:14 schrieb Lin Huang:
> From: Shengfei xu
>
> This patch adds support for the SiP interface, we can pass dram
> paramtert to bl31, and control ddr frequency scaling in bl31.
>
> Signed-off-by: Shengfei xu
> Signed-off-by: Lin Huang
[...]
> +++ b/drivers/firmware/rockchip_sip.c
> @@ -0,0 +1,64 @@
> +/*
> + * 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.
> + *
> + * Copyright (C) 2016 ARM Limited
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "rockchip_sip.h"
> +
> +typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> + unsigned long, unsigned long);
> +asmlinkage psci_fn __invoke_psci_fn_smc;
> +
> +#define CONFIG_DRAM_INIT 0x00
> +#define CONFIG_DRAM_SET_RATE 0x01
> +#define CONFIG_DRAM_ROUND_RATE 0x02
> +#define CONFIG_DRAM_SET_AT_SR0x03
> +#define CONFIG_DRAM_GET_BW 0x04
> +#define CONFIG_DRAM_GET_RATE 0x05
> +#define CONFIG_DRAM_CLR_IRQ 0x06
> +#define CONFIG_DRAM_SET_PARAM 0x07
> +
> +uint64_t sip_smc_ddr_init(void)
if I'm reading the ATF writers guide [0] correctly, the SiP calls are soc-
specific things:
"For example, two SoC providers can use the same Function ID within the SiP
Service calls OEN range to mean different things - as these calls should be
specific to the SoC. "
So I guess the function calls, as well as the constants should have a prefix.
ROCKCHIP_SIP_DDR_FREQ, rockchip_sip_smc_set_ddr_param(), etc.
Looking at Zynq in the ATF [1] seems to strengthen that theory with the
similar constants having the ZYNQMP_ prefix.
I guess it doesn't matter to much on the ATF side, as you build a soc-specific
image, but on the kernel-side I think it should unambiguos, especially as
functions and constants are part of a public header.
I think the code itself looks fine though :-)
Heiko
[0]
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/rt-svc-writers-guide.md
[1]
https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/xilinx/zynqmp/sip_svc_setup.c
> +{
> + return __invoke_psci_fn_smc(SIP_DDR_FREQ, 0,
> + 0, CONFIG_DRAM_INIT);
> +}
> +
> +uint64_t sip_smc_set_ddr_param(uint64_t param)
> +{
> + return __invoke_psci_fn_smc(SIP_DDR_FREQ, param,
> + 0, CONFIG_DRAM_SET_PARAM);
> +}
> +
> +uint64_t sip_smc_set_ddr_rate(uint64_t rate)
> +{
> + return __invoke_psci_fn_smc(SIP_DDR_FREQ, rate, 0,
> + CONFIG_DRAM_SET_RATE);
> +}
> +
> +uint64_t sip_smc_get_ddr_rate(void)
> +{
> + return __invoke_psci_fn_smc(SIP_DDR_FREQ, 0, 0, CONFIG_DRAM_GET_RATE);
> +}
> +
> +uint64_t sip_smc_clr_ddr_irq(void)
> +{
> + return __invoke_psci_fn_smc(SIP_DDR_FREQ, 0, 0, CONFIG_DRAM_CLR_IRQ);
> +}
> +
> +uint64_t sip_smc_get_call_count(void)
> +{
> + return __invoke_psci_fn_smc(SIP_SVC_CALL_COUNT, 0, 0, 0);
> +}
> diff --git a/drivers/firmware/rockchip_sip.h
> b/drivers/firmware/rockchip_sip.h new file mode 100644
> index 000..6487734
> --- /dev/null
> +++ b/drivers/firmware/rockchip_sip.h
> @@ -0,0 +1,59 @@
> +/* Copyright (c) 2010-2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only 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.
> + */
> +#ifndef __SIP_INT_H
> +#define __SIP_INT_H
> +
> +/* SMC function IDs for SiP Service queries */
> +#define SIP_SVC_CALL_COUNT 0x8200ff00
> +#define SIP_SVC_UID 0x8200ff01
> +#define SIP_SVC_VERSION 0x8200ff03
> +#define SIP_DDR_FREQ 0xC208
> +
> +#if IS_ENABLED(CONFIG_ROCKCHIP_SIP)
> +uint64_t sip_smc_set_ddr_rate(uint64_t rate);
> +uint64_t sip_smc_get_ddr_rate(void);
> +uint64_t sip_smc_clr_ddr_irq(void);
> +uint64_t sip_smc_get_call_count(void);
> +uint64_t sip_smc_ddr_init(void);
> +uint64_t sip_smc_set_ddr_param(uint64_t param);
> +#else
> +static inline uint64_t sip_smc_set_ddr_rate(uint64_t rate)
> +{
> + return 0;
> +}
> +
> +static inline uint64_t sip_smc_get_ddr_rate(void)
> +{
> + return 0;
> +}
> +
> +static inline uint64_t sip_smc_clr_ddr_irq(void)
> +{
> + return 0;
Re: [PATCH] i2c: i801: use IS_ENABLED() instead of checking for built-in or module
On Thu, 21 Jul 2016 12:11:01 -0400, Javier Martinez Canillas wrote:
> The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
> built-in or as a module, use that macro instead of open coding the same.
>
> Using the macro makes the code more readable by helping abstract away some
> of the Kconfig built-in and module enable details.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> drivers/i2c/busses/i2c-i801.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 68cec6128ac0..5ef9b733d153 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -98,8 +98,7 @@
> #include
> #include
>
> -#if (defined CONFIG_I2C_MUX_GPIO || defined CONFIG_I2C_MUX_GPIO_MODULE) && \
> - defined CONFIG_DMI
> +#if IS_ENABLED(CONFIG_I2C_MUX_GPIO) && defined CONFIG_DMI
> #include
> #include
> #endif
> @@ -255,8 +254,7 @@ struct i801_priv {
> int len;
> u8 *data;
>
> -#if (defined CONFIG_I2C_MUX_GPIO || defined CONFIG_I2C_MUX_GPIO_MODULE) && \
> - defined CONFIG_DMI
> +#if IS_ENABLED(CONFIG_I2C_MUX_GPIO) && defined CONFIG_DMI
> const struct i801_mux_config *mux_drvdata;
> struct platform_device *mux_pdev;
> #endif
> @@ -1133,8 +1131,7 @@ static void __init input_apanel_init(void) {}
> static void i801_probe_optional_slaves(struct i801_priv *priv) {}
> #endif /* CONFIG_X86 && CONFIG_DMI */
>
> -#if (defined CONFIG_I2C_MUX_GPIO || defined CONFIG_I2C_MUX_GPIO_MODULE) && \
> - defined CONFIG_DMI
> +#if IS_ENABLED(CONFIG_I2C_MUX_GPIO) && defined CONFIG_DMI
> static struct i801_mux_config i801_mux_config_asus_z8_d12 = {
> .gpio_chip = "gpio_ich",
> .values = { 0x02, 0x03 },
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
