[PATCH 0/1] Motorola CPCAP PMIC RTC
Hi,
Here is a driver for the RTC found inside of the
Motorola Droid 4 based on linux-next 2017021.
I tried to set & get the time using hwclock and
used ./tools/testing/selftests/timers/rtctest.c:
$ ./rtctest
RTC Driver Test Example.
Counting 5 update (1/sec) interrupts from reading /dev/rtc0: 1 2 3 4 5
Again, from using select(2) on /dev/rtc: 1 2 3 4 5
Current RTC date/time is 20-2-2017, 07:11:22.
Alarm time now set to 07:11:27.
Waiting 5 seconds for alarm... okay. Alarm rang.
Periodic IRQ rate is 1Hz.
Counting 20 interrupts at:
2Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
4Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
8Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
16Hz:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
32Hz:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
64Hz:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
*** Test complete ***
I did not include a patch for omap4-droid4-xt894.dts,
since the CPCAP DT entry has not yet been added. The
following DT snippet can be used for testing on droid4:
&cpcap {
cpcap_rtc: rtc {
compatible = "motorola,cpcap-rtc";
interrupt-parent = <&cpcap>;
interrupts = <39 IRQ_TYPE_NONE>, <26 IRQ_TYPE_NONE>;
};
};
-- Sebastian
Sebastian Reichel (1):
rtc: cpcap: new rtc driver
.../devicetree/bindings/rtc/cpcap-rtc.txt | 13 +
drivers/rtc/Kconfig| 7 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-cpcap.c| 318 +
4 files changed, 339 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
create mode 100644 drivers/rtc/rtc-cpcap.c
--
2.11.0
[PATCH 1/1] rtc: cpcap: new rtc driver
This driver supports the Motorola CPCAP PMIC found on
some of Motorola's mobile phones, such as the Droid 4.
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/rtc/cpcap-rtc.txt | 13 +
drivers/rtc/Kconfig| 7 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-cpcap.c| 318 +
4 files changed, 339 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
create mode 100644 drivers/rtc/rtc-cpcap.c
diff --git a/Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
b/Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
new file mode 100644
index ..2709c32baf2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
@@ -0,0 +1,13 @@
+Motorola CPCAP PMIC RTC
+
+
+Requires node properties:
+- compatible: should contain "motorola,cpcap-rtc"
+- interrupts: An interrupt specifier for alarm and 1 Hz irq
+
+Example:
+
+cpcap_rtc: rtc {
+ compatible = "motorola,cpcap-rtc";
+ interrupts = <39 IRQ_TYPE_NONE>, <26 IRQ_TYPE_NONE>;
+};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index ee1b0e9dde79..050bec749fae 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1731,6 +1731,13 @@ config RTC_DRV_STM32
This driver can also be built as a module, if so, the module
will be called "rtc-stm32".
+config RTC_DRV_CPCAP
+ depends on MFD_CPCAP
+ tristate "Motorola CPCAP RTC"
+ help
+ Say y here for CPCAP rtc found on some Motorola phones
+ and tablets such as Droid 4.
+
comment "HID Sensor RTC drivers"
config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index f07297b1460a..13857d2fce09 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_RTC_DRV_BQ32K) += rtc-bq32k.o
obj-$(CONFIG_RTC_DRV_BQ4802) += rtc-bq4802.o
obj-$(CONFIG_RTC_DRV_CMOS) += rtc-cmos.o
obj-$(CONFIG_RTC_DRV_COH901331)+= rtc-coh901331.o
+obj-$(CONFIG_RTC_DRV_CPCAP)+= rtc-cpcap.o
obj-$(CONFIG_RTC_DRV_DA9052) += rtc-da9052.o
obj-$(CONFIG_RTC_DRV_DA9055) += rtc-da9055.o
obj-$(CONFIG_RTC_DRV_DA9063) += rtc-da9063.o
diff --git a/drivers/rtc/rtc-cpcap.c b/drivers/rtc/rtc-cpcap.c
new file mode 100644
index ..815beca843ce
--- /dev/null
+++ b/drivers/rtc/rtc-cpcap.c
@@ -0,0 +1,318 @@
+/*
+ * Motorola CPCAP PMIC RTC driver
+ *
+ * Based on cpcap-regulator.c from Motorola Linux kernel tree
+ * Copyright (C) 2009 Motorola, Inc.
+ *
+ * Rewritten for mainline kernel
+ * - use DT
+ * - use regmap
+ * - use standard interrupt framework
+ * - use managed device resources
+ * - remove custom "secure clock daemon" helpers
+ *
+ * Copyright (C) 2017 Sebastian Reichel
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SECS_PER_DAY 86400
+#define DAY_MASK 0x7FFF
+#define TOD1_MASK 0x00FF
+#define TOD2_MASK 0x01FF
+
+struct cpcap_time {
+ int day;
+ int tod1;
+ int tod2;
+};
+
+struct cpcap_rtc {
+ struct regmap *regmap;
+ struct rtc_device *rtc_dev;
+ u16 vendor;
+ int alarm_irq;
+ bool alarm_enabled;
+ int update_irq;
+ bool update_enabled;
+};
+
+static void cpcap2rtc_time(struct rtc_time *rtc, struct cpcap_time *cpcap)
+{
+ unsigned long int tod;
+ unsigned long int time;
+
+ tod = (cpcap->tod1 & TOD1_MASK) | ((cpcap->tod2 & TOD2_MASK) << 8);
+ time = tod + ((cpcap->day & DAY_MASK) * SECS_PER_DAY);
+
+ rtc_time_to_tm(time, rtc);
+}
+
+static void rtc2cpcap_time(struct cpcap_time *cpcap, struct rtc_time *rtc)
+{
+ unsigned long time;
+
+ rtc_tm_to_time(rtc, &time);
+
+ cpcap->day = time / SECS_PER_DAY;
+ time %= SECS_PER_DAY;
+ cpcap->tod2 = (time >> 8) & TOD2_MASK;
+ cpcap->tod1 = time & TOD1_MASK;
+}
+
+static int cpcap_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+ struct cpcap_rtc *rtc = dev_get_drvdata(dev);
+
+ if (rtc->alarm_enabled == enabled)
+ return 0;
+
+ if (enabled)
+ enable_irq(rtc->alarm_irq);
+ else
+ disable_irq(rtc->alarm_irq);
+
+ rtc->alarm_enabled = !!enabled;
+
+ return 0;
+}
+
+static int cpcap_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct cpcap_rtc *rtc;
Re: [GIT PULL] Block pull request for- 4.11-rc1
On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote: > I don't think that's a regression in this series, it just triggers more easily > with this series. The BLOCK_PC removal fixes aren't touching device life times > at all. Yes. > That said, we will look into this again, of course. Christoph, any idea? No idea really - this seems so far away from the code touched, and there are no obvious signs for a memory scamble from another object touched that I think if it really bisects down to that issue it must be a timing issue. But reading Bart's message again: Did you actually bisect it down to the is commit? Or just test the whole tree? Between the 4.10-rc5 merge and all the block tree there might a few more likely suspects like the scsi bdi lifetime fixes that James mentioned.
Re: [PATCH v2] drm/rockchip: cdn-dp: Fix error handling
On 2017年02月20日 15:08, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in this
case.
Add a missing call to 'pm_runtime_put()'.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
Signed-off-by: Christophe JAILLET
looks good for me
Reviewed-by: Mark Yao
---
V2: rename label
add missing call to 'pm_runtime_put_sync()' in error path
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 9ab67a670885..0fe1ec8b8fb1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -111,7 +111,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
ret = pm_runtime_get_sync(dp->dev);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
- goto err_pclk;
+ goto err_pm_runtime_get;
}
reset_control_assert(dp->core_rst);
@@ -133,6 +133,8 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
return 0;
err_set_rate:
+ pm_runtime_put(dp->dev);
+err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
clk_disable_unprepare(dp->pclk);
--
Ｍark Yao
Re: [PATCH 1/2] staging: ks7010: Unnecessary parentheses are removed to make coder nicer.
Hi Arushi,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.10 next-20170217]
[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/Arushi-Singhal/staging-ks7010-Unnecessary-parentheses-are-removed-to-make-coder-nicer/20170220-145647
config: i386-randconfig-x012-201708 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/staging/ks7010/ks_hostif.c: In function 'get_current_ap':
>> drivers/staging/ks7010/ks_hostif.c:116:5: error: incompatible types when
>> assigning to type 'struct local_ap_t *' from type 'struct local_ap_t'
ap = priv->current_ap;
^
vim +116 drivers/staging/ks7010/ks_hostif.c
110 struct local_ap_t *ap;
111 union iwreq_data wrqu;
112 struct net_device *netdev = priv->net_dev;
113 int rc = 0;
114
115 DPRINTK(3, "\n");
> 116 ap = priv->current_ap;
117
118 if ((priv->connect_status & CONNECT_STATUS_MASK) ==
DISCONNECT_STATUS) {
119 memset(ap, 0, sizeof(struct local_ap_t));
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX
* Kees Cook wrote: > On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote: > > Hi! > > > >> > >> -config DEBUG_RODATA > >> +config STRICT_KERNEL_RWX > >> bool "Make kernel text and rodata read-only" if > >> ARCH_OPTIONAL_KERNEL_RWX > >> depends on ARCH_HAS_STRICT_KERNEL_RWX > >> default !ARCH_OPTIONAL_KERNEL_RWX || > > > > Debug features are expected to have runtime cost, so kconfig help is > > silent about those. But there are runtime costs, right? It would be > > nice to mention them in the help text... > > It depends on the architecture. The prior help text for arm said: > > The tradeoff is that each region is padded to section-size (1MiB) > boundaries (because their permissions are different and splitting > the 1M pages into 4K ones causes TLB performance problems), which > can waste memory. > > parisc (somewhat inaccurately) said: > > This option may have a slight performance impact because a > portion of the kernel code won't be covered by a TLB anymore. > > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. BTW., a good strategy with RAM sizes above say 4GB would be to just round up to the next large-TLB boundary (2MB) and waste 0-2MB of RAM - which is only 0.05% of 4GB of RAM. On most workloads, especially with SSDs it's probably a positive RAM vs. performance trade-off. Thanks, Ingo
[ANNOUNCE] linux-4.10-ck1 / MuQSS CPU scheduler 0.152
These are patches designed to improve system responsiveness and interactivity with specific emphasis on the desktop, but configurable for any workload. The patchset is mainly centred around the Multiple Queue Skiplist Scheduler, MuQSS. -ck1 patches: http://ck.kolivas.org/patches/4.0/4.10/4.10-ck1/ Git tree: https://github.com/ckolivas/linux/tree/4.10-ck Ubuntu 16.10 packages: http://ck.kolivas.org/patches/4.0/4.10/4.10-ck1/Ubuntu16.10/ Patch for those struggling with the nvidia driver and 4.10: http://ck.kolivas.org/patches/4.0/4.10/nvidia-375.39-linux-4.10.patch Full patch list: 0001-MuQSS-150-pre-merge.patch 0002-Remove-quick-ramp-up-which-may-have-been-keeping-CPU.patch 0003-Fix-iso-tick-calculation.patch 0004-Prevent-negative-value-causing-further-overflow-in-t.patch 0005-Demote-no-cpumask-message-to-info.patch 0006-Bump-muqss-version-to-0.152.patch 0007-Make-preemptible-kernel-default.patch 0008-Expose-vmsplit-option-for-our-poor-32bit-users.patch 0009-Implement-min-and-msec-hrtimeout-un-interruptible-sc.patch 0010-Special-case-calls-of-schedule_timeout-1-to-use-the-.patch 0011-Convert-msleep-to-use-hrtimers-when-active.patch 0012-Replace-all-schedule-timeout-1-with-schedule_min_hrt.patch 0013-Change-all-schedule_timeout-with-msecs_to_jiffies-po.patch 0014-Replace-all-calls-to-schedule_timeout_interruptible-.patch 0015-Replace-all-calls-to-schedule_timeout_uninterruptibl.patch 0016-Fix-build-for-disabled-highres-timers-with-hrtimeout.patch 0017-Make-hrtimer-granularity-and-minimum-hrtimeout-confi.patch 0018-Make-threaded-IRQs-optionally-the-default-which-can-.patch 0019-Reinstate-default-Hz-of-100-in-combination-with-MuQS.patch 0020-Don-t-use-hrtimer-overlay-when-pm_freezing-since-som.patch 0021-Make-writeback-throttling-default-enabled.patch 0022-Swap-sucks.patch 0023-BFQ-version-8.patch 0024-Make-BFQ-default-IO-scheduler.patch 0025-Add-ck1-version.patch For a brief description of each patch without trawling the git tree, each patch can be found as a quilt series here: http://ck.kolivas.org/patches/4.0/4.10/4.10-ck1/patches/ Hacking blog: http://ck-hack.blogspot.com/ Simple homepage: http://kernel.kolivas.org Enjoy! お楽しみ下さい -- -ck
Re: [PATCHv2 4/5] perf stat: Add -a as a default target
On Sat, Feb 18, 2017 at 06:52:25PM +0100, Borislav Petkov wrote: > On Fri, Feb 17, 2017 at 06:48:13PM +0100, Boris Petkov wrote: > > LGTM. > > > > Acked-by: me > > Well, it looks good but actually trying it is a different story. For > example: > > $ ./perf stat -e amd_nb/event=0xe0,umask=0x1f/ sleep 1 > > still says because argc is not 0. > > So how about the below diff instead? > > $ ./perf stat -e amd_nb/event=0xe0,umask=0x1f/ > > without args dumps the usage message and > > $ ./perf stat -e amd_nb/event=0xe0,umask=0x1f/ sleep 1 > > actually does the system-wide thing: > > Performance counter stats for 'system wide': > >196,469 amd_nb/event=0xe0,umask=0x1f/ > >1.001815180 seconds time elapsed > > Hmmm? ugh, I thought it was too easy ;-) it looks good to me thanks, jirka
[PATCH v2] drm/rockchip: cdn-dp: Fix error handling
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in this
case.
Add a missing call to 'pm_runtime_put()'.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
Signed-off-by: Christophe JAILLET
---
V2: rename label
add missing call to 'pm_runtime_put_sync()' in error path
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 9ab67a670885..0fe1ec8b8fb1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -111,7 +111,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
ret = pm_runtime_get_sync(dp->dev);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
- goto err_pclk;
+ goto err_pm_runtime_get;
}
reset_control_assert(dp->core_rst);
@@ -133,6 +133,8 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
return 0;
err_set_rate:
+ pm_runtime_put(dp->dev);
+err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
clk_disable_unprepare(dp->pclk);
--
2.9.3
[PATCH v10 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding
The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
Acked-by: Rob Herring
---
.../bindings/display/panel/samsung,s6e3ha2.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..18854f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+ - compatible: "samsung,s6e3ha2"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: I/O voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin (active low)
+ - enable-gpios: a GPIO spec for the panel enable pin (active high)
+
+Optional properties:
+ - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+&dsi {
+ ...
+
+ panel@0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+ };
+};
--
1.9.1
[PATCH v10 0/3] Add support for the S6E3HA2 panel on TM2 board
Dear Thierry,
I understand that your opinion is:
It is better to handle the error every time it is input to the
register, rather than error handling at once in the struct using
error. This not only makes the code easier to maintain, but also
reduces unnecessary computation.
So I modified the panel driver to code-by-code error handling.
If this is not your opinion, could you tell me what your opinion?
Best Regards,
Hoegeun
Changes for V10:
- Fixed code-by-code error handling.
Changes for V9:
- Fixed the te-gpio to optional in bindings
Changes for V8:
- Applied below two patches: (drm/exynos)
: drm/exynos: mic: Add mode_set callback function
: drm/exynos: mic: Fix parse_dt function
- The dt-binding patch and driver patch were divided.
- Rebase these patches on samsung SoC tree[1] and tm2 touckey patch[2].
Change for V7:
- Fixed the mode_set callback function of mic device driver.
because the mic register is initialized when entering suspend
mode, so should set the reg value whenever pre_enable is
called.
Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
- Fixed from number size to ARRAY_SIZE().
- Fixed error handling in mipi_dsi_dcs_* functions.
- Fixed the clock of display_mode.
- Removed unnecessary casting and error log.
Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
callback, because mode_set should be performed every time.
Changes for V4:
- Removed display-timings in devicetree, the display-timings has
been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
because the exynos_drm_mic driver can not parse a videomode
struct by removing the display-timings from the devicetree.
Changes for V3:
- In the DT binding document, made it clearly that the panel is a
child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to patch2?
Althogh the panel is a child of dsi, I think OF graph necessary.
because if a remote-endpoint is not specified, the dsi also
panel is not probed.
- The display-timings has been fixed to be provided by the device
driver. however, I think display-timings is necessary in dts.
because if dts does not have display-timings, dsi will not load.
Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
- Added active high or low after the description of the GPIOs.
- Removed the reg and added a description of the virtual
channel number of a DSI peripheral.
Depends on:
[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/ (for-next
branch)
[2] https://patchwork.kernel.org/patch/9504131/
- ("arm64: dts: exynos: Add tm2 touchkey node")
Hoegeun Kwon (2):
dt-bindings: Add support for samsung s6e3ha2 panel binding
drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Hyungwon Hwang (1):
arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
.../bindings/display/panel/samsung,s6e3ha2.txt | 28 +
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 +
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 739 +
5 files changed, 786 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
--
1.9.1
[PATCH v10 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 739 ++
3 files changed, 746 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..d913c83 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
Xperia Z2 tablets
+config DRM_PANEL_SAMSUNG_S6E3HA2
+ tristate "Samsung S6E3HA2 DSI video mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) +=
panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..4cc08d7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,739 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee
+ * Hyungwon Hwang
+ * Hoegeun Kwon
+ *
+ * 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
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT 35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
+ 0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
+ 0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
+ 0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
+ 0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x89, 0x8a, 0x84, 0x89, 0x83, 0x83, 0x86, 0x84, 0x8b,
+ 0x90, 0x84, 0xb0, 0xae, 0x8b, 0xce, 0xad, 0xc8, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x87, 0x89, 0x8a, 0x83, 0x87, 0x82, 0x85, 0x88, 0x87, 0x89,
+ 0x8f, 0x84, 0xac, 0xaa, 0x89, 0xb1, 0x98, 0xaf, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x88, 0x89, 0x84, 0x88, 0x83, 0x82, 0x85, 0x84, 0x8c,
+ 0x91, 0x86, 0xac, 0xaa, 0x89, 0xc2, 0xa5, 0xbd, 0x00, 0x00, 0
[PATCH v10 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index dea0a6f..db3fed2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <25000>, <4>;
};
+&dsi {
+ panel@0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&hsi2c_9 {
status = "okay";
--
1.9.1
Re: [RFC] perf/sdt: Directly record SDT event with 'perf record'
* Ravi Bangoria wrote: > All events from 'perf list', except SDT events, can be directly recorded > with 'perf record'. But, the flow is little different for SDT events. > Probe point for SDT event needs to be created using 'perf probe' before > recording it using 'perf record'. > > As suggested by Ingo[1], it's better to make this process simple by > creating probe points automatically with 'perf record' for SDT events. > > This patch disables 'perf probe' on SDT events to simplify usage. It > enables recording SDT event only with 'perf record'. > > This removes all those 'multiple events with same name' issues by not > allowing manual probe creation to user. When there are multiple events > with same name, 'perf record' will record all of them (in line with > other tools supporting SDT (systemtap)). > > I know 'perf probe' for SDT events has already became interface and > people are using it. But, doing this change will make user interface very > easy and also it will make tool behaviour consistent. Also, it won't > require any changes in uprobe_events structure (suggested by Masami[2]). So I like the automatism you implemented for 'perf record', but why not keep the 'perf probe' flow as well, if people got used to it? It's not like computer software is bad at sorting apart and handling the two cases properly, right? Thanks, Ingo
[PATCH 2/2] arm: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 10.1 initial support
From: Jagan Teki
i.CoreM6 Quad/Dual OpenFrame modules are "system on modules plus
openframe display carriers" which are good solution for develop
user friendly graphic user interface.
General features:
CPU NXP i.MX6Q rev1.2 at 792 MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND SLC,512MB
LVDS Display TFT 10.1" industrial, 1280x800 resolution
Backlight LED backlight, brightness 350 Cd/m2
Power supply 15 to 30 Vdc
Cc: Domenico Acri
Cc: Matteo Lisi
Cc: Michael Trimarchi
Cc: Shawn Guo
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/imx6q-icore-ofcap10.dts | 76 +++
2 files changed, 77 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-icore-ofcap10.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0118084..458ec09 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -398,6 +398,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-h100.dtb \
imx6q-hummingboard.dtb \
imx6q-icore.dtb \
+ imx6q-icore-ofcap10.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
imx6q-mccmon6.dtb \
diff --git a/arch/arm/boot/dts/imx6q-icore-ofcap10.dts
b/arch/arm/boot/dts/imx6q-icore-ofcap10.dts
new file mode 100644
index 000..70600e2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-icore-ofcap10.dts
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 Quad/Dual OpenFrame Capacitive touch 10.1
Kit";
+ compatible = "engicam,imx6-icore", "fsl,imx6q";
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+native-mode = <&timing1>;
+timing1: hsd100pxn1 {
+clock-frequency = <6000>;
+hactive = <1280>;
+vactive = <800>;
+hback-porch = <40>;
+hfront-porch = <40>;
+vback-porch = <10>;
+vfront-porch = <3>;
+hsync-len = <80>;
+vsync-len = <10>;
+};
+};
+ };
+};
--
1.9.1
[PATCH 1/2] arm: dts: imx6qdl-icore: Add backlight support for lvds
From: Jagan Teki
This patch add support for lvds backlight on i.CoreM6 QDL
variant boards.
Cc: Domenico Acri
Cc: Matteo Lisi
Cc: Michael Trimarchi
Cc: Shawn Guo
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/imx6qdl-icore.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi
b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index 55bebfc..7dda608 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -48,6 +48,14 @@
reg = <0x1000 0x8000>;
};
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm3 0 10>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ status = "okay";
+ };
+
reg_3p3v: regulator-3p3v {
compatible = "regulator-fixed";
regulator-name = "3P3V";
@@ -136,6 +144,12 @@
status = "okay";
};
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+ status = "okay";
+};
+
&uart4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart4>;
@@ -246,6 +260,12 @@
>;
};
+ pinctrl_pwm3: pwm3grp-1 {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
+ >;
+ };
+
pinctrl_usbotg: usbotggrp {
fsl,pins = <
MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
--
1.9.1
Re: [Outreachy kernel] [PATCH 2/2] staging: ks7010: Unnecessary parentheses are removed.
On Mon, 20 Feb 2017, Arushi Singhal wrote:
> Unnecessary parentheses should be avoided as reported by checkpatch.pl.
> Remove unnecessary parentheses, as reported by checkpatch as are nicer
> to read.For example:-
> It's often nicer to read if &(foo[0]) is converted to foo like:
> memcpy(&(ap->bssid[0]), &(ap_info->bssid[0]), ETH_ALEN);
> memcpy(ap->bssid, ap_info->bssid, ETH_ALEN);
The commit message is not well presented. One has the impression that all
of the changes are related to 0 array elements. It would be better to
split the patch into two: one for removing parentheses, and one for making
the &x[0] -> x change. They don't really have anything to do with each
other.
julia
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/ks7010/ks_hostif.c | 20 ++--
> drivers/staging/ks7010/ks_wlan_net.c | 20 ++--
> 2 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/staging/ks7010/ks_hostif.c
> b/drivers/staging/ks7010/ks_hostif.c
> index ba283ab741a7..2d5ec57c5cfd 100644
> --- a/drivers/staging/ks7010/ks_hostif.c
> +++ b/drivers/staging/ks7010/ks_hostif.c
> @@ -239,19 +239,19 @@ int get_ap_information(struct ks_wlan_private *priv,
> struct ap_info_t *ap_info,
> *(bp + 1));
> ap->ssid.size = SSID_MAX_SIZE;
> }
> - memcpy(&(ap->ssid.body[0]), bp + 2, ap->ssid.size);
> + memcpy(ap->ssid.body, bp + 2, ap->ssid.size);
> break;
> case 1: /* rate */
> case 50:/* ext rate */
> if ((*(bp + 1) + ap->rate_set.size) <=
> RATE_SET_MAX_SIZE) {
> - memcpy(&(ap->rate_set.body[ap->rate_set.size]),
> + memcpy(&ap->rate_set.body[ap->rate_set.size],
> bp + 2, *(bp + 1));
> ap->rate_set.size += *(bp + 1);
> } else {
> DPRINTK(1, "size over :: rate size=%d\n",
> (*(bp + 1) + ap->rate_set.size));
> - memcpy(&(ap->rate_set.body[ap->rate_set.size]),
> + memcpy(&ap->rate_set.body[ap->rate_set.size],
> bp + 2,
> RATE_SET_MAX_SIZE - ap->rate_set.size);
> ap->rate_set.size +=
> @@ -269,7 +269,7 @@ int get_ap_information(struct ks_wlan_private *priv,
> struct ap_info_t *ap_info,
> *(bp + 1));
> ap->rsn_ie.size = RSN_IE_BODY_MAX;
> }
> - memcpy(&(ap->rsn_ie.body[0]), bp + 2, ap->rsn_ie.size);
> + memcpy(ap->rsn_ie.body, bp + 2, ap->rsn_ie.size);
> break;
> case 221: /* WPA */
> if (!memcmp(bp + 2, "\x00\x50\xf2\x01", 4)) { /* WPA
> OUI check */
> @@ -282,7 +282,7 @@ int get_ap_information(struct ks_wlan_private *priv,
> struct ap_info_t *ap_info,
> *(bp + 1));
> ap->wpa_ie.size = RSN_IE_BODY_MAX;
> }
> - memcpy(&(ap->wpa_ie.body[0]), bp + 2,
> + memcpy(ap->wpa_ie.body, bp + 2,
> ap->wpa_ie.size);
> }
> break;
> @@ -832,8 +832,8 @@ void hostif_scan_indication(struct ks_wlan_private *priv)
> if (priv->scan_ind_count != 0) {
> for (i = 0; i < priv->aplist.size; i++) { /* bssid check
> */
> if (!memcmp
> - (&(ap_info->bssid[0]),
> - &(priv->aplist.ap[i].bssid[0]), ETH_ALEN)) {
> + (ap_info->bssid,
> + &priv->aplist.ap[i].bssid[0], ETH_ALEN)) {
> if (ap_info->frame_type ==
> FRAME_TYPE_PROBE_RESP)
> get_ap_information(priv, ap_info,
> @@ -2652,7 +2652,7 @@ int hostif_init(struct ks_wlan_private *priv)
>
> priv->aplist.size = 0;
> for (i = 0; i < LOCAL_APLIST_MAX; i++)
> - memset(&(priv->aplist.ap[i]), 0, sizeof(struct local_ap_t));
> + memset(&priv->aplist.ap[i], 0, sizeof(struct local_ap_t));
> priv->infra_status = 0;
> priv->current_rate = 4;
> priv->connect_status = DISCONNECT_STATUS;
> @@ -2675,12 +2675,12 @@ int hostif_init(struct ks_wlan_private *priv)
> INIT_WORK(&priv->ks_wlan_wakeup_task, ks_wlan_hw_wakeup_task);
>
> /* WPA */
> - memset(&(priv->wpa), 0, sizeof(priv->wpa));
> + memset(&priv->wp
Re: [PATCH] drm/rockchip: cdn-dp: Fix error handling
On 2017年02月20日 14:41, Christophe JAILLET wrote:
Le 20/02/2017 à 02:40, Mark yao a écrit :
On 2017年02月20日 00:59, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful
in this
case.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for
rk3399")
Signed-off-by: Christophe JAILLET
---
Not sure but a 'pm_runtime_get_sync()' is maybe also required in the
'err_set_rate' path.
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 9ab67a670885..0fe1ec8b8fb1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -111,7 +111,7 @@ static int cdn_dp_clk_enable(struct
cdn_dp_device *dp)
ret = pm_runtime_get_sync(dp->dev);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
-goto err_pclk;
+goto err_sync;
I think the name err_pm_runtime_get is better.
err_sync is not a clear name for the pm_runtime_get_sync.
I will change it.
}
reset_control_assert(dp->core_rst);
@@ -133,6 +133,7 @@ static int cdn_dp_clk_enable(struct
cdn_dp_device *dp)
return 0;
err_set_rate:
+err_sync:
miss pm_runtime_put, it should be:
I am wondering if 'pm_runtime_put_sync' should be added, instead.
We want to revert the 'pm_runtime_get_sync' of line 111. According to
the naming of the function, the _sync version looks more logical to me.
Using ccoccinelle shows that 2/3 of functions calling both
'pm_runtime_get_sync' and 'pm_runtime_get[_sync]' and using the _sync
variant.
pm_runtime_get_sync will block until hardware actually done power configure,
we need make sure power is enable before use the hardware, So we should
use pm_runtime_get_sync at power on.
At power off time, use pm_runtime_put is enough, it can be async, no
need block.
Thanks.
Which semantic is the correct one?
err_set_rate:
pm_runtime_put(dp->dev);
err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
clk_disable_unprepare(dp->pclk);
--
Ｍark Yao
[PATCH 2/2] staging: ks7010: Unnecessary parentheses are removed.
Unnecessary parentheses should be avoided as reported by checkpatch.pl.
Remove unnecessary parentheses, as reported by checkpatch as are nicer
to read.For example:-
It's often nicer to read if &(foo[0]) is converted to foo like:
memcpy(&(ap->bssid[0]), &(ap_info->bssid[0]), ETH_ALEN);
memcpy(ap->bssid, ap_info->bssid, ETH_ALEN);
Signed-off-by: Arushi Singhal
---
drivers/staging/ks7010/ks_hostif.c | 20 ++--
drivers/staging/ks7010/ks_wlan_net.c | 20 ++--
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b/drivers/staging/ks7010/ks_hostif.c
index ba283ab741a7..2d5ec57c5cfd 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -239,19 +239,19 @@ int get_ap_information(struct ks_wlan_private *priv,
struct ap_info_t *ap_info,
*(bp + 1));
ap->ssid.size = SSID_MAX_SIZE;
}
- memcpy(&(ap->ssid.body[0]), bp + 2, ap->ssid.size);
+ memcpy(ap->ssid.body, bp + 2, ap->ssid.size);
break;
case 1: /* rate */
case 50:/* ext rate */
if ((*(bp + 1) + ap->rate_set.size) <=
RATE_SET_MAX_SIZE) {
- memcpy(&(ap->rate_set.body[ap->rate_set.size]),
+ memcpy(&ap->rate_set.body[ap->rate_set.size],
bp + 2, *(bp + 1));
ap->rate_set.size += *(bp + 1);
} else {
DPRINTK(1, "size over :: rate size=%d\n",
(*(bp + 1) + ap->rate_set.size));
- memcpy(&(ap->rate_set.body[ap->rate_set.size]),
+ memcpy(&ap->rate_set.body[ap->rate_set.size],
bp + 2,
RATE_SET_MAX_SIZE - ap->rate_set.size);
ap->rate_set.size +=
@@ -269,7 +269,7 @@ int get_ap_information(struct ks_wlan_private *priv, struct
ap_info_t *ap_info,
*(bp + 1));
ap->rsn_ie.size = RSN_IE_BODY_MAX;
}
- memcpy(&(ap->rsn_ie.body[0]), bp + 2, ap->rsn_ie.size);
+ memcpy(ap->rsn_ie.body, bp + 2, ap->rsn_ie.size);
break;
case 221: /* WPA */
if (!memcmp(bp + 2, "\x00\x50\xf2\x01", 4)) { /* WPA
OUI check */
@@ -282,7 +282,7 @@ int get_ap_information(struct ks_wlan_private *priv, struct
ap_info_t *ap_info,
*(bp + 1));
ap->wpa_ie.size = RSN_IE_BODY_MAX;
}
- memcpy(&(ap->wpa_ie.body[0]), bp + 2,
+ memcpy(ap->wpa_ie.body, bp + 2,
ap->wpa_ie.size);
}
break;
@@ -832,8 +832,8 @@ void hostif_scan_indication(struct ks_wlan_private *priv)
if (priv->scan_ind_count != 0) {
for (i = 0; i < priv->aplist.size; i++) { /* bssid check
*/
if (!memcmp
- (&(ap_info->bssid[0]),
-&(priv->aplist.ap[i].bssid[0]), ETH_ALEN)) {
+ (ap_info->bssid,
+&priv->aplist.ap[i].bssid[0], ETH_ALEN)) {
if (ap_info->frame_type ==
FRAME_TYPE_PROBE_RESP)
get_ap_information(priv, ap_info,
@@ -2652,7 +2652,7 @@ int hostif_init(struct ks_wlan_private *priv)
priv->aplist.size = 0;
for (i = 0; i < LOCAL_APLIST_MAX; i++)
- memset(&(priv->aplist.ap[i]), 0, sizeof(struct local_ap_t));
+ memset(&priv->aplist.ap[i], 0, sizeof(struct local_ap_t));
priv->infra_status = 0;
priv->current_rate = 4;
priv->connect_status = DISCONNECT_STATUS;
@@ -2675,12 +2675,12 @@ int hostif_init(struct ks_wlan_private *priv)
INIT_WORK(&priv->ks_wlan_wakeup_task, ks_wlan_hw_wakeup_task);
/* WPA */
- memset(&(priv->wpa), 0, sizeof(priv->wpa));
+ memset(&priv->wpa, 0, sizeof(priv->wpa));
priv->wpa.rsn_enabled = 0;
priv->wpa.mic_failure.failure = 0;
priv->wpa.mic_failure.last_failure_time = 0;
priv->wpa.mic_failure.stop = 0;
- memset(&(priv->pmklist), 0, sizeof(priv->pmklist));
+ memset(&priv->pmklist, 0, sizeof(priv->pmklist));
INIT_LIST_HEAD(&priv->pmklist.head);
for (i = 0; i < PMK_LIST_MAX; i++)
Re: [PATCH 3/4] iio: accel: adxl345: Add SPI support
On Sun, Feb 19, 2017 at 01:12:50PM +, Jonathan Cameron wrote:
> On 16/02/17 10:02, Eva Rachel Retuya wrote:
> > Add SPI driver for initializing spi regmap for the adxl345 core driver.
> > The driver supports the same functionality as I2C namely the x, y, z and
> > scale readings.
> >
> > Signed-off-by: Eva Rachel Retuya
> Looks nice. I didn't know about the readmask stuff in regmap so
> always good to see something new.
>
Me too. The SPI reads were unusual, and the datasheet mentions some sort of
mask to enable proper consecutive register reads. Grepped the mask and
discovered this. Since then, the reads are no longer incorrect :)
Eva
> Jonathan
> > ---
> > drivers/iio/accel/Kconfig | 13 +++
> > drivers/iio/accel/Makefile | 1 +
> > drivers/iio/accel/adxl345_spi.c | 75
> > +
> > 3 files changed, 89 insertions(+)
> > create mode 100644 drivers/iio/accel/adxl345_spi.c
> >
> > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> > index 5bdd87f..d474fed 100644
> > --- a/drivers/iio/accel/Kconfig
> > +++ b/drivers/iio/accel/Kconfig
> > @@ -21,6 +21,19 @@ config ADXL345_I2C
> > To compile this driver as a module, choose M here: the
> > module will be called adxl345_i2c.
> >
> > +config ADXL345_SPI
> > + tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer SPI
> > Driver"
> > + depends on !(INPUT_ADXL34X=y || INPUT_ADXL34X=m)
> > + depends on SPI
> > + select ADXL345
> > + select REGMAP_SPI
> > + help
> > + Say Y here if you want to build support for the Analog Devices
> > + ADXL345 3-axis digital accelerometer.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called adxl345_spi.
> > +
> > config BMA180
> > tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
> > depends on I2C
> > diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> > index 3f4a6d6..31fba19 100644
> > --- a/drivers/iio/accel/Makefile
> > +++ b/drivers/iio/accel/Makefile
> > @@ -5,6 +5,7 @@
> > # When adding new entries keep the list in alphabetical order
> > obj-$(CONFIG_ADXL345) += adxl345_core.o
> > obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
> > +obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
> > obj-$(CONFIG_BMA180) += bma180.o
> > obj-$(CONFIG_BMA220) += bma220_spi.o
> > obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> > diff --git a/drivers/iio/accel/adxl345_spi.c
> > b/drivers/iio/accel/adxl345_spi.c
> > new file mode 100644
> > index 000..5fcd1fa
> > --- /dev/null
> > +++ b/drivers/iio/accel/adxl345_spi.c
> > @@ -0,0 +1,75 @@
> > +/*
> > + * ADXL345 3-Axis Digital Accelerometer
> > + *
> > + * Copyright (c) 2017 Eva Rachel Retuya
> > + *
> > + * This file is subject to the terms and conditions of version 2 of
> > + * the GNU General Public License. See the file COPYING in the main
> > + * directory of this archive for more details.
> > + *
> > + * SPI driver for ADXL345
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include "adxl345.h"
> > +
> > +#define ADXL345_MAX_SPI_FREQ_HZ500
> > +
> > +static const struct regmap_config adxl345_spi_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > +/* Setting bits 7 and 6 enables multiple-byte read */
> > + .read_flag_mask = BIT(7) | BIT(6),
> Nice. I didn't know about that one ;)
> > +};
> > +
> > +static int adxl345_spi_probe(struct spi_device *spi)
> > +{
> > + struct regmap *regmap;
> > + const struct spi_device_id *id = spi_get_device_id(spi);
> > +
> > + /* Bail out if max_speed_hz exceeds 5 MHz */
> > + if (spi->max_speed_hz > ADXL345_MAX_SPI_FREQ_HZ) {
> > + dev_err(&spi->dev, "SPI CLK, %d Hz exceeds 5 MHz\n",
> > + spi->max_speed_hz);
> > + return -EINVAL;
> > + }
> > +
> > + regmap = devm_regmap_init_spi(spi, &adxl345_spi_regmap_config);
> > + if (IS_ERR(regmap)) {
> > + dev_err(&spi->dev, "Error initializing spi regmap: %d\n",
> > + (int)PTR_ERR(regmap));
> > + return PTR_ERR(regmap);
> > + }
> > +
> > + return adxl345_common_probe(&spi->dev, regmap, id->name);
> > +}
> > +
> > +static int adxl345_spi_remove(struct spi_device *spi)
> > +{
> > + return adxl345_common_remove(&spi->dev);
> > +}
> > +
> > +static const struct spi_device_id adxl345_spi_id[] = {
> > + { "adxl345", 0 },
> > + { }
> > +};
> > +
> > +MODULE_DEVICE_TABLE(spi, adxl345_spi_id);
> > +
> > +static struct spi_driver adxl345_spi_driver = {
> > + .driver = {
> > + .name = "adxl345_spi",
> > + },
> > + .probe = adxl345_spi_probe,
> > + .remove = adxl345_spi_remove,
> > + .id_table = adxl345_spi_id,
> > +};
> > +
> > +module_spi_driver(adxl345_spi_driver);
> > +
> > +MODULE_AUTHOR("Eva Rachel Retuya ");
> > +MODULE_DESCRIPTION("ADXL345 3-Axis Digital Accelerometer SPI driver");
> > +MODULE_LICENSE
Re: [PATCH 2/4] iio: accel: adxl345: Split driver into core and I2C
On Sun, Feb 19, 2017 at 01:11:29PM +, Jonathan Cameron wrote: > On 16/02/17 10:02, Eva Rachel Retuya wrote: > > Move I2C-specific code into its own file and rely on regmap to access > > registers. The core code provides access to x, y, z and scale readings. > > > > Signed-off-by: Eva Rachel Retuya > A few minor comment inline. This unwound the comment about client->dev > in the previous patch, but I'd prefer to see it done there as then the > changes in here will be easier to see (with move detection hopefully working!) > > Jonathan > > --- > > drivers/iio/accel/Kconfig| 8 +- > > drivers/iio/accel/Makefile | 3 +- > > drivers/iio/accel/adxl345.c | 213 > > --- > > drivers/iio/accel/adxl345.h | 18 > > drivers/iio/accel/adxl345_core.c | 182 + > > drivers/iio/accel/adxl345_i2c.c | 70 + > This is a case where allowing git to notice the moves would have lead > to easier to read patches (unless this was sufficiently complex that git > couldn't follow it ;) Hello Jonathan, Thanks for the feedback. I amended the relevant commits as you say and git detects the file adxl345.c -> adxl345_core.c as 78% renamed. The reason for that percentage is that I did some probe/remove renames and some other deletions here and there. Should I commit them separately in order to get the move detection to work? > > 6 files changed, 278 insertions(+), 216 deletions(-) > > delete mode 100644 drivers/iio/accel/adxl345.c > > create mode 100644 drivers/iio/accel/adxl345.h > > create mode 100644 drivers/iio/accel/adxl345_core.c > > create mode 100644 drivers/iio/accel/adxl345_i2c.c > > > > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig > > index 26b8614..5bdd87f 100644 > > --- a/drivers/iio/accel/Kconfig > > +++ b/drivers/iio/accel/Kconfig > > @@ -6,16 +6,20 @@ > > menu "Accelerometers" > > > > config ADXL345 > > - tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer Driver" > > + tristate > > + > > +config ADXL345_I2C > > + tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer I2C > > Driver" > > depends on !(INPUT_ADXL34X=y || INPUT_ADXL34X=m) > > depends on I2C > > + select ADXL345 > > select REGMAP_I2C > > help > > Say Y here if you want to build support for the Analog Devices > > ADXL345 3-axis digital accelerometer. > > > > To compile this driver as a module, choose M here: the > > - module will be called adxl345. > > + module will be called adxl345_i2c. > There are a couple of ways to do this. I personally kind of prefer the > way the bmc150 does it as it gives a cleaner set of options in Kconfig. > > Look at the various ways it is done and if you still prefer this one then > fair enough (it's how we always used to do it ;) Ack. I've seen it but went this way just to be explicit. I agree with doing it cleaner and will reflect it on v2. Eva > > > > config BMA180 > > tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver" > > diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile > > index 618488d..3f4a6d6 100644 > > --- a/drivers/iio/accel/Makefile > > +++ b/drivers/iio/accel/Makefile > > @@ -3,7 +3,8 @@ > > # > > > > # When adding new entries keep the list in alphabetical order > > -obj-$(CONFIG_ADXL345) += adxl345.o > > +obj-$(CONFIG_ADXL345) += adxl345_core.o > > +obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o > > obj-$(CONFIG_BMA180) += bma180.o > > obj-$(CONFIG_BMA220) += bma220_spi.o > > obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o > > diff --git a/drivers/iio/accel/adxl345.c b/drivers/iio/accel/adxl345.c > > deleted file mode 100644 > > index a1fdf60..000 > > --- a/drivers/iio/accel/adxl345.c > > +++ /dev/null > > @@ -1,213 +0,0 @@ > > -/* > > - * ADXL345 3-Axis Digital Accelerometer > > - * > > - * Copyright (c) 2017 Eva Rachel Retuya > > - * > > - * This file is subject to the terms and conditions of version 2 of > > - * the GNU General Public License. See the file COPYING in the main > > - * directory of this archive for more details. > > - * > > - * IIO driver for ADXL345 > > - * 7-bit I2C slave address: 0x1D (ALT ADDRESS pin tied to VDDIO) or > > - * 0x53 (ALT ADDRESS pin grounded) > > - */ > > - > > -#include > > -#include > > -#include > > - > > -#include > > - > > -#define ADXL345_REG_DEVID 0x00 > > -#define ADXL345_REG_POWER_CTL 0x2D > > -#define ADXL345_REG_DATA_FORMAT0x31 > > -#define ADXL345_REG_DATAX0 0x32 > > -#define ADXL345_REG_DATAY0 0x34 > > -#define ADXL345_REG_DATAZ0 0x36 > > - > > -#define ADXL345_POWER_CTL_MEASURE BIT(3) > > -#define ADXL345_POWER_CTL_STANDBY 0x00 > > - > > -#define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits > > resolution */ > > -#define ADXL345_DATA_FORMAT_2G 0 > > -#define ADXL345_DATA_FORMAT_4G 1 > > -#define ADX
Re: [PATCH] drm/rockchip: cdn-dp: Fix error handling
Le 20/02/2017 à 02:40, Mark yao a écrit :
On 2017年02月20日 00:59, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in
this
case.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for
rk3399")
Signed-off-by: Christophe JAILLET
---
Not sure but a 'pm_runtime_get_sync()' is maybe also required in the
'err_set_rate' path.
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 9ab67a670885..0fe1ec8b8fb1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -111,7 +111,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device
*dp)
ret = pm_runtime_get_sync(dp->dev);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
-goto err_pclk;
+goto err_sync;
I think the name err_pm_runtime_get is better.
err_sync is not a clear name for the pm_runtime_get_sync.
I will change it.
}
reset_control_assert(dp->core_rst);
@@ -133,6 +133,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device
*dp)
return 0;
err_set_rate:
+err_sync:
miss pm_runtime_put, it should be:
I am wondering if 'pm_runtime_put_sync' should be added, instead.
We want to revert the 'pm_runtime_get_sync' of line 111. According to
the naming of the function, the _sync version looks more logical to me.
Using ccoccinelle shows that 2/3 of functions calling both
'pm_runtime_get_sync' and 'pm_runtime_get[_sync]' and using the _sync
variant.
Which semantic is the correct one?
err_set_rate:
pm_runtime_put(dp->dev);
err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
clk_disable_unprepare(dp->pclk);
Re: [PATCH v6 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info
Hi Eric,
On Thursday 16 February 2017 04:55 PM, Eric W. Biederman wrote:
+/*
+ * The maximum size of the name of each namespace
+ */
+#define NS_NAME_SIZE 8
+
+struct perf_ns_link_info {
+ charname[NS_NAME_SIZE];
+ __u64 dev;
+ __u64 ino;
+};
Ugh. I missed the name the first time around.
That really looks like useless clutter. You already know the index so
the name doesn't add any information, so unless I am missing something
that name will just slow down the perf kernel implementation with
useless work.
The userspace reader can have the information just as reliably by
looking at the index and indexing into a table.
The set of namespaces changes slowly enough that this is not likely to
be a problem in practice. Especially as perf is released with the
kernel.
Plus who knows how long the name of the next namespace is going to be.
Agreed. Will drop name field from the structure and use an indexing
table to get names in userspace..
Thanks
Hari
[GIT PULL] power-supply changes for 4.11
Hi Linus, Everything in my pull-request has been in linux-next for three weeks. There are overlappings with mfd & arm, but no problems were reported by Stephen, so I assume the immutable branches worked as expected. -- Sebastian The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77: Linux 4.10-rc1 (2016-12-25 16:13:08 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git tags/for-v4.11 for you to fetch changes up to 744cc304a18f1c9de4f3215fbe93fe878f934179: power: supply: add AC power supply driver for AXP20X and AXP22X PMICs (2017-01-29 23:15:18 +0100) power supply and reset changes for the v4.11 series * New drivers - sbs-charger driver - max14656_charger_detector - axp20x_ac_power * New chip/feature support - axp20x_usb_power: add AXP223 support - tps65217: add usb charger support - qcom_smbb: support otg regulator - at91-reset: add samx7 support * Dropped drivers - intel_mid_battery (platform was dropped) * Fixes - at91-poweroff: avoid wearing off LPDDR memory - replace deprecated extcon API - lots of cleanup and style fixes - misc. minor functionality fixes Alexander Kurz (2): dt-bindings: power: supply: Add max14656_charger_detector power: supply: Add support for MAX14656 USB charger detector Alexandre Belloni (3): ARM: at91: define LPDDR types power: reset: at91-poweroff: timely shutdown LPDDR memories power: reset: at91-reset: remove leftover platform_device_id Andy Shevchenko (1): power: supply: remove Intel Moorestown battery support Arnd Bergmann (1): power: supply: qcom_smbb: add regulator dependency Bird, Tim (2): dt-bindings: power: supply: Add otg regulator binding power: supply: qcom_smbb: Add otg regulator for control of vbus Chanwoo Choi (2): power: supply: axp288_charger: Replace the extcon API power: supply: qcom_smbb: Replace the deprecated extcon API Chris Lapa (12): power: supply: bq27xxx: move overtemp tests to a switch statement. power: supply: bq27xxx: rename BQ27500 allow for deprecation in future. power: supply: bq27xxx: rename BQ27510 allow for deprecation in future. power: supply: bq27xxx: adds specific support for bq27500/1 revision. power: supply: bq27xxx: adds specific support for bq27510-g1 revision. power: supply: bq27xxx: adds specific support for bq27510-g2 revision. power: supply: bq27xxx: adds specific support for bq27510-g3 revision. power: supply: bq27xxx: adds specific support for bq27520-g1 revision. power: supply: bq27xxx: adds specific support for bq27520-g2 revision. power: supply: bq27xxx: adds specific support for bq27520-g3 revision. power: supply: bq27xxx: adds specific support for bq27520-g4 revision. power: supply: bq27xxx: adds device tree binding documentation. Colin Ian King (3): power: supply: wm97xx_battery: remove redundant 2nd null check on pdata power: supply: fix spelling mistake: supply: "Celcius" -> "Celsius" power: supply: bq2415x: check for NULL acpi_id to avoid null pointer dereference Gustavo A. R. Silva (2): power: supply: ab8500_btemp: Compress return logic into one line. power: supply: pcf50633-charger: Compress return logic into one line. Hans de Goede (18): power: supply: axp288_charger: Make charger_init_hw_regs propagate i2c errors power: supply: axp288_charger: Drop platform_data dependency power: supply: axp288_fuel_gauge: Drop platform_data dependency power: supply: axp288_fuel_gauge: Fix fuel_gauge_reg_readb return on error power: supply: axp288_fuel_gauge: Read 15 bit values 2 registers at a time power: supply: axp288_fuel_gauge: Read 12 bit values 2 registers at a time power: supply: axp288_charger: Use devm_power_supply_register power: supply: axp288_charger: Register extcon notifers after power_supply power: supply: axp288_charger: Move init_hw_regs call before supply registration power: supply: axp288_charger: Actually get and use the USB_HOST extcon device power: supply: axp288_charger: Handle charger type changing without disconnect power: supply: axp288_charger: Some minor cleanups power: supply: axp288_charger: Get and process initial hardware-state power: supply: axp288_charger: Fix wrong regmap_update_bits power: supply: axp288_charger: Remove unnecessary irq?_en register writes power: supply: axp288_charger: Fix the module not auto-loading power: supply: axp288_charger: Use one notifier_block per extcon cable power: supply: axp288_fuel_gauge: Remove unnecessary irq?_en register writes Javier Martinez Canillas (1): power: supply: max14656: Export I2C and OF device ID as module alias
[PATCH v2] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made
We met an issue for kdump: after kdump kernel boots up,
and there comes a broadcasted mce in first kernel, the
other cpus remaining in first kernel will enter the old
mce handler of first kernel, then timeout and panic due
to MCE synchronization, finally reset the kdump cpus.
This patch lets cpus stay quiet after nmi_shootdown_cpus(),
so before crash cpu shots them down or after kdump boots,
they should not do anything except clearing MCG_STATUS
in case of broadcasted mce. This is useful for kdump
to let the vmcore dumping perform as hard as it can.
Previous efforts:
https://patchwork.kernel.org/patch/6167631/
https://lists.gt.net/linux/kernel/2146557
Cc: Naoya Horiguchi
Suggested-by: Borislav Petkov
Signed-off-by: Xunlei Pang
---
v1->v2:
Using crashing_cpu according to Borislav's suggestion.
arch/x86/include/asm/reboot.h| 1 +
arch/x86/kernel/cpu/mcheck/mce.c | 6 --
arch/x86/kernel/reboot.c | 16 +++-
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/reboot.h b/arch/x86/include/asm/reboot.h
index 2cb1cc2..ec8657b6 100644
--- a/arch/x86/include/asm/reboot.h
+++ b/arch/x86/include/asm/reboot.h
@@ -26,5 +26,6 @@ struct machine_ops {
typedef void (*nmi_shootdown_cb)(int, struct pt_regs*);
void nmi_shootdown_cpus(nmi_shootdown_cb callback);
void run_crash_ipi_callback(struct pt_regs *regs);
+bool cpus_shotdown(void);
#endif /* _ASM_X86_REBOOT_H */
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 8e9725c..3b56710 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include "mce-internal.h"
@@ -1128,8 +1129,9 @@ void do_machine_check(struct pt_regs *regs, long
error_code)
*/
int lmce = 1;
- /* If this CPU is offline, just bail out. */
- if (cpu_is_offline(smp_processor_id())) {
+ /* If nmi shootdown happened or this CPU is offline, just bail out. */
+ if (cpus_shotdown() ||
+ cpu_is_offline(smp_processor_id())) {
u64 mcgstatus;
mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index e244c19..b301c8d 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -752,7 +752,7 @@ void machine_crash_shutdown(struct pt_regs *regs)
#if defined(CONFIG_SMP)
/* This keeps a track of which one is crashing cpu. */
-static int crashing_cpu;
+static int crashing_cpu = -1;
static nmi_shootdown_cb shootdown_callback;
static atomic_t waiting_for_crash_ipi;
@@ -852,6 +852,14 @@ void nmi_panic_self_stop(struct pt_regs *regs)
}
}
+bool cpus_shotdown(void)
+{
+ if (crashing_cpu != -1)
+ return true;
+
+ return false;
+}
+
#else /* !CONFIG_SMP */
void nmi_shootdown_cpus(nmi_shootdown_cb callback)
{
@@ -861,4 +869,10 @@ void nmi_shootdown_cpus(nmi_shootdown_cb callback)
void run_crash_ipi_callback(struct pt_regs *regs)
{
}
+
+bool cpus_shotdown(void)
+{
+ return false;
+}
+
#endif
--
1.8.3.1
Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront
On 17/02/17 20:47, Dmitry Torokhov wrote:
> On Mon, Jan 30, 2017 at 01:27:29PM +0200, Oleksandr Andrushchenko wrote:
>> On 01/30/2017 01:23 PM, Juergen Gross wrote:
>>> On 27/01/17 17:10, Dmitry Torokhov wrote:
On January 27, 2017 12:31:19 AM PST, Juergen Gross wrote:
> On 27/01/17 09:26, Oleksandr Andrushchenko wrote:
>> On 01/27/2017 10:14 AM, Juergen Gross wrote:
>>> On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
On 01/27/2017 09:46 AM, Juergen Gross wrote:
> On 27/01/17 08:21, Oleksandr Andrushchenko wrote:
>> On 01/27/2017 09:12 AM, Juergen Gross wrote:
>>> Instead of using the default resolution of 800*600 for the
> pointing
>>> device of xen-kbdfront try to read the resolution of the
> (virtual)
>>> framebuffer device. Use the default as fallback only.
>>>
>>> Signed-off-by: Juergen Gross
>>> ---
>>> V2: get framebuffer resolution only if CONFIG_FB (Dmitry
> Torokhov)
>>> ---
>>> drivers/input/misc/xen-kbdfront.c | 15 ---
>>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/input/misc/xen-kbdfront.c
>>> b/drivers/input/misc/xen-kbdfront.c
>>> index 3900875..3aae9b4 100644
>>> --- a/drivers/input/misc/xen-kbdfront.c
>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>> @@ -16,6 +16,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> @@ -108,7 +109,7 @@ static irqreturn_t input_handler(int rq,
> void
>>> *dev_id)
>>> static int xenkbd_probe(struct xenbus_device *dev,
>>> const struct xenbus_device_id *id)
>>> {
>>> -int ret, i;
>>> +int ret, i, width, height;
>>> unsigned int abs;
>>> struct xenkbd_info *info;
>>> struct input_dev *kbd, *ptr;
>>> @@ -173,9 +174,17 @@ static int xenkbd_probe(struct
> xenbus_device
>>> *dev,
>>> ptr->id.product = 0xfffe;
>>> if (abs) {
>>> +width = XENFB_WIDTH;
>>> +height = XENFB_HEIGHT;
>>> +#ifdef CONFIG_FB
>>> +if (registered_fb[0]) {
>> This still will not help if FB gets registered after kbd+ptr
> Hmm, so you think I should add a call to fb_register_client() to
> get
> events for new registered framebuffer devices?
yes, but also pay attention to CONFIG_FB_NOTIFY: you may still
end up w/o notification.
>>> Okay, that's not worse than today.
>> agree
> This would probably work. I'll have a try.
>
>
> Thanks,
>
> Juergen
My bigger concern here is that we try to tie keyboard and pointer
> device
to the framebuffer. IMO, these are independent parts of the system
> and
the relation
depends on the use-case. One can have graphics enabled w/o
> framebuffer
at all, e.g.
DRM/KMS + OpenGLES + Weston + kbd + ptr...
>>> Again: that's a use case which will work as today. The current
> defaults
>>> are being used.
>>>
>>> The question is whether we should add a module parameter switching
> off
>>> the automatic adaption of the resolution as there might be use cases
>>> where we don't want this feature.
>> I think for those who doesn't want this resolution there is
>> still a possibility to change it on backend's XenbusStateConnected
>> So, no need for module parameter, IMO
> Fine.
>
> I'll send V3 soon.
How about you do the axis adjustment from userspace (udev rule), and leave
kernel as is?
>>> Hmm, is this a good idea?
>>>
>>> I'd need a udev rule to trigger when either the pointing device or a
>>> new frame buffer is showing up. In both cases I need to read the
>>> geometry of the frame buffer (in case it exists) and set the geometry
>>> of the pointing device (in case it exists) to the same values. This
>>> seems to be much more complicated than the required changes in the
>>> driver.
>>>
>>> I could be wrong, of course, especially as I'm no expert in writing
>>> udev rules. :-)
>> And you may also end up with thin Dom0 w/o udev at all...
>
> So what piece of software is using resolution of this input device and
> why it has to match screen resolution? What happens when framebuffer is
> registered after input device is created? I see that in the later
> version of the patch you hook the notifier and change values, but how
> users would know about that?
The problem showed up in out internal QA: the installer is being tested
automatically in a virtual machine. The output of the (virtual)
framebuffer is captured automatically and verified to match cer
[PATCH 0/2] Revert works for the mapping of cpuid <-> nodeid
Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time. It keeps consistent with the WorkQueue and avoids some bugs which may be caused by the dynamic assignment. As we know, It is implemented by the patches as follows: 2532fc318d, f7c28833c2, 8f54969dc8, 8ad893faf2, dc6db24d24, which depend on ACPI table. Simply speaking: Step 1. Make the "Logical CPU ID <-> Processor ID/UID" fixed Using MADT: We generate the logical CPU IDs by the Local APIC/x2APIC IDs orderly and get the mapping of Processor ID/UID <-> Local Apic ID directly in MADT. So, we get the mapping of *Processor ID/UID <-> Local Apic ID <-> Logical CPU ID* Step 2. Make the "Processor ID/UID <-> Node ID(_PXM)" fixed Using DSDT: The maaping of "Processor ID/UID <-> Node ID(_PXM)" is ready-made in each entities. we just use it directly. So, at last we get the maaping of *Node ID <-> Logical CPU ID* according to step1 and step2: *Node ID(_PXM) <-> Processor ID/UID <-> Local Apic ID <-> Logical CPU ID* But, The ACPI table is unreliable and it is very risky that we use the entity which isn't related to a physical device at booting time. Here has already two bugs we found. 1. Duplicated Processor IDs in DSDT. It has been fixed by commit 8e089eaa19, fd74da217d. 2. The _PXM in DSDT is inconsistent with the one in MADT. It may cause the bug, which is shown in: https://lkml.org/lkml/2017/2/12/200 There may be more later. We shouldn't just only fix them everytime, we should solve this problem from the source to avoid such problems happend again and again. Now, a simple and easy way is found, we revert our patches. Do the Step 2 at hot-plug time, not at booting time where we did some useless work. It also can make the mapping of "cpuid <-> nodeid" fixed and avoid excessive use of the ACPI table. We have tested them in our box: Fujitsu PQ2000 with 2 nodes for hot-plug. To Xiaolong: Please help me to test it in the special machine. Dou Liyang (2): Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping Revert"x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid" arch/x86/kernel/acpi/boot.c | 2 +- drivers/acpi/acpi_processor.c | 5 -- drivers/acpi/bus.c| 1 - drivers/acpi/processor_core.c | 133 +++--- include/linux/acpi.h | 3 - 5 files changed, 23 insertions(+), 121 deletions(-) -- 2.5.5
[PATCH 1/2] Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"
Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time.
It keeps consistent with the WorkQueue and avoids some bugs which may be caused
by the dynamic assignment.
But, The ACPI table is unreliable and it is very risky that we use the entity
which isn't related to a physical device at booting time.
Now, we revert our patches. Do the last mapping of "cpuid <-> nodeid" at
hot-plug time, not at booting time where we did some useless work.
It also can make the mapping of "cpuid <-> nodeid" fixed and avoid excessive
use of the ACPI table.
The patch revert the commit dc6db24d24:
"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting".
Signed-off-by: Dou Liyang
---
arch/x86/kernel/acpi/boot.c | 2 +-
drivers/acpi/acpi_processor.c | 5 ---
drivers/acpi/bus.c| 1 -
drivers/acpi/processor_core.c | 73 ---
include/linux/acpi.h | 3 --
5 files changed, 1 insertion(+), 83 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 64422f8..32846a2 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -709,7 +709,7 @@ static void __init acpi_set_irq_model_ioapic(void)
#ifdef CONFIG_ACPI_HOTPLUG_CPU
#include
-int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
int nid;
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 3de3b6b..f43a586 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -182,11 +182,6 @@ int __weak arch_register_cpu(int cpu)
void __weak arch_unregister_cpu(int cpu) {}
-int __weak acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
-{
- return -ENODEV;
-}
-
static int acpi_processor_hotadd_init(struct acpi_processor *pr)
{
unsigned long long sta;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 95855cb..d4455e4 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1207,7 +1207,6 @@ static int __init acpi_init(void)
acpi_wakeup_device_init();
acpi_debugger_init();
acpi_setup_sb_notify_handler();
- acpi_set_processor_mapping();
return 0;
}
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 611a558..a843862 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -278,79 +278,6 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32
acpi_id)
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
-#ifdef CONFIG_ACPI_HOTPLUG_CPU
-static bool __init
-map_processor(acpi_handle handle, phys_cpuid_t *phys_id, int *cpuid)
-{
- int type, id;
- u32 acpi_id;
- acpi_status status;
- acpi_object_type acpi_type;
- unsigned long long tmp;
- union acpi_object object = { 0 };
- struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
-
- status = acpi_get_type(handle, &acpi_type);
- if (ACPI_FAILURE(status))
- return false;
-
- switch (acpi_type) {
- case ACPI_TYPE_PROCESSOR:
- status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
- if (ACPI_FAILURE(status))
- return false;
- acpi_id = object.processor.proc_id;
-
- /* validate the acpi_id */
- if(acpi_processor_validate_proc_id(acpi_id))
- return false;
- break;
- case ACPI_TYPE_DEVICE:
- status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
- if (ACPI_FAILURE(status))
- return false;
- acpi_id = tmp;
- break;
- default:
- return false;
- }
-
- type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
-
- *phys_id = __acpi_get_phys_id(handle, type, acpi_id, false);
- id = acpi_map_cpuid(*phys_id, acpi_id);
-
- if (id < 0)
- return false;
- *cpuid = id;
- return true;
-}
-
-static acpi_status __init
-set_processor_node_mapping(acpi_handle handle, u32 lvl, void *context,
- void **rv)
-{
- phys_cpuid_t phys_id;
- int cpu_id;
-
- if (!map_processor(handle, &phys_id, &cpu_id))
- return AE_ERROR;
-
- acpi_map_cpu2node(handle, cpu_id, phys_id);
- return AE_OK;
-}
-
-void __init acpi_set_processor_mapping(void)
-{
- /* Set persistent cpu <-> node mapping for all processors. */
- acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
- ACPI_UINT32_MAX, set_processor_node_mapping,
- NULL, NULL, NULL);
-}
-#else
-void __init acpi_set_processor_mapping(void) {}
-#endif /* CONFIG_ACPI_HOTPLUG_CPU */
-
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base,
[PATCH 2/2] Revert"x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid"
After we never do the last mapping of "cpuid <-> nodeid" at booting time. we
also no need to enable MADT APIs to return disabled apicid.
So, The patch work for reverting the commit 8ad893faf2:
"x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid"
Signed-off-by: Dou Liyang
---
drivers/acpi/processor_core.c | 60 ---
1 file changed, 22 insertions(+), 38 deletions(-)
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index a843862..b933061 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -32,12 +32,12 @@ static struct acpi_table_madt *get_madt_table(void)
}
static int map_lapic_id(struct acpi_subtable_header *entry,
-u32 acpi_id, phys_cpuid_t *apic_id, bool ignore_disabled)
+u32 acpi_id, phys_cpuid_t *apic_id)
{
struct acpi_madt_local_apic *lapic =
container_of(entry, struct acpi_madt_local_apic, header);
- if (ignore_disabled && !(lapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (!(lapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (lapic->processor_id != acpi_id)
@@ -48,13 +48,12 @@ static int map_lapic_id(struct acpi_subtable_header *entry,
}
static int map_x2apic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
- bool ignore_disabled)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
{
struct acpi_madt_local_x2apic *apic =
container_of(entry, struct acpi_madt_local_x2apic, header);
- if (ignore_disabled && !(apic->lapic_flags & ACPI_MADT_ENABLED))
+ if (!(apic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration && (apic->uid == acpi_id)) {
@@ -66,13 +65,12 @@ static int map_x2apic_id(struct acpi_subtable_header *entry,
}
static int map_lsapic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
- bool ignore_disabled)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
{
struct acpi_madt_local_sapic *lsapic =
container_of(entry, struct acpi_madt_local_sapic, header);
- if (ignore_disabled && !(lsapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration) {
@@ -89,13 +87,12 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
* Retrieve the ARM CPU physical identifier (MPIDR)
*/
static int map_gicc_mpidr(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *mpidr,
- bool ignore_disabled)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *mpidr)
{
struct acpi_madt_generic_interrupt *gicc =
container_of(entry, struct acpi_madt_generic_interrupt, header);
- if (ignore_disabled && !(gicc->flags & ACPI_MADT_ENABLED))
+ if (!(gicc->flags & ACPI_MADT_ENABLED))
return -ENODEV;
/* device_declaration means Device object in DSDT, in the
@@ -112,7 +109,7 @@ static int map_gicc_mpidr(struct acpi_subtable_header
*entry,
}
static phys_cpuid_t map_madt_entry(struct acpi_table_madt *madt,
- int type, u32 acpi_id, bool ignore_disabled)
+ int type, u32 acpi_id)
{
unsigned long madt_end, entry;
phys_cpuid_t phys_id = PHYS_CPUID_INVALID; /* CPU hardware ID */
@@ -130,20 +127,16 @@ static phys_cpuid_t map_madt_entry(struct acpi_table_madt
*madt,
struct acpi_subtable_header *header =
(struct acpi_subtable_header *)entry;
if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
- if (!map_lapic_id(header, acpi_id, &phys_id,
- ignore_disabled))
+ if (!map_lapic_id(header, acpi_id, &phys_id))
break;
} else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) {
- if (!map_x2apic_id(header, type, acpi_id, &phys_id,
- ignore_disabled))
+ if (!map_x2apic_id(header, type, acpi_id, &phys_id))
break;
} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
- if (!map_lsapic_id(header, type, acpi_id, &phys_id,
- ignore_disabled))
+ if (!map_lsapic_id(header, type, acpi_id, &phys_id))
break;
} else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
- if (!map_gicc_mpidr(header, type, acpi
Re: [PATCH] Make EN2 pin optional in the TRF7970A driver
Hello all, Am 13.02.2017 um 22:31 schrieb Rob Herring: On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher wrote: Hello Rob, Am 10.02.2017 um 16:51 schrieb Rob Herring: On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote: From: Guan Ben Make the EN2 pin optional. This is useful for boards, which have this pin fix wired, for example to ground. Signed-off-by: Guan Ben Signed-off-by: Mark Jonas Signed-off-by: Heiko Schocher --- .../devicetree/bindings/net/nfc/trf7970a.txt | 4 ++-- drivers/nfc/trf7970a.c | 26 -- 2 files changed, 16 insertions(+), 14 deletions(-) diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt index 32b35a0..5889a3d 100644 --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt @@ -5,8 +5,8 @@ Required properties: - spi-max-frequency: Maximum SPI frequency (<= 200). - interrupt-parent: phandle of parent interrupt handler. - interrupts: A single interrupt specifier. -- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the - TRF7970A. +- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the + TRF7970A. EN2 is optional. Could EN ever be optional/fixed? If so, perhaps deprecate this property and do 2 properties, one for each pin. The hardware I have has the EN2 pin fix connected to ground. Looking into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3 and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin selects between Power Down and Sleep Mode ... I see no reason why this is not possible/allowed ... Hmm.. I do not like the idea of deprecating the "ti,enable-gpios" property into 2 seperate properties ... but if this would be a reason for not accepting this patch, I can do this ... How should I name the 2 new properties? I guess if this ever happens, then we just add "ti,enable2-gpios" and ti,enable-gpios continues to point to EN. We don't need to deprecate anything (or maybe just deprecate having both GPIOs on single property). In that case, Acked-by: Rob Herring gentle ping. Are there any more comments to this patch? Is it acceptable as it is? Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Re: [next-20170217] WARN @/arch/powerpc/include/asm/xics.h:124 .icp_hv_eoi+0x40/0x140
>> While booting next-20170217 on a POWER6 box, I ran into following
>> warning. This is a full system lpar. Previous next tree was good.
>> I will try a bisect tomorrow.
>
> Do you have CONFIG_DEBUG_SHIRQ=y ?
>
Yes. CONFIG_DEBUG_SHIRQ is enabled.
As suggested by you reverting following commit allows a clean boot.
f91f694540f3 ("genirq: Reenable shared irq debugging in request_*_irq()”)
>> ipr: IBM Power RAID SCSI Device Driver version: 2.6.3 (October 17, 2015)
>> ipr 0200:00:01.0: Found IOA with IRQ: 305
>> [ cut here ]
>> WARNING: CPU: 12 PID: 1 at ./arch/powerpc/include/asm/xics.h:124
>> .icp_hv_eoi+0x40/0x140
>> Modules linked in:
>> CPU: 12 PID: 1 Comm: swapper/14 Not tainted
>> 4.10.0-rc8-next-20170217-autotest #1
>> task: c002b2a4a580 task.stack: c002b2a5c000
>> NIP: c00731b0 LR: c01389f8 CTR: c0073170
>> REGS: c002b2a5f050 TRAP: 0700 Not tainted
>> (4.10.0-rc8-next-20170217-autotest)
>> MSR: 80029032
>> CR: 28004082 XER: 2004
>> CFAR: c01389e0 SOFTE: 0
>> GPR00: c01389f8 c002b2a5f2d0 c1025800 c002b203f498
>> GPR04: 0064 0131
>> GPR08: 0001 c000d3104cb8 0009b1f8
>> GPR12: 48004082 cedc2400 c000dad0
>> GPR16: 3c007efc c0a9e848
>> GPR20: d8008008 c002af4d47f0 c11efda8 c0a9ea10
>> GPR24: c0a9e848 c002af4d4fb8
>> GPR28: c002b203f498 c0ef8928 c002b203f400
>> NIP [c00731b0] .icp_hv_eoi+0x40/0x140
>> LR [c01389f8] .handle_fasteoi_irq+0x1e8/0x270
>> Call Trace:
>> [c002b2a5f2d0] [c002b2a5f360] 0xc002b2a5f360 (unreliable)
>> [c002b2a5f360] [c01389f8] .handle_fasteoi_irq+0x1e8/0x270
>> [c002b2a5f3e0] [c0136a08] .request_threaded_irq+0x298/0x370
>> [c002b2a5f490] [c05895c0] .ipr_probe_ioa+0x1110/0x1390
>> [c002b2a5f5c0] [c058d030] .ipr_probe+0x30/0x3e0
>> [c002b2a5f670] [c0466860] .local_pci_probe+0x60/0x130
>> [c002b2a5f710] [c0467658] .pci_device_probe+0x148/0x1e0
>> [c002b2a5f7c0] [c0527524] .driver_probe_device+0x2d4/0x5b0
>> [c002b2a5f860] [c052796c] .__driver_attach+0x16c/0x190
>> [c002b2a5f8f0] [c05242c4] .bus_for_each_dev+0x84/0xf0
>> [c002b2a5f990] [c0526af4] .driver_attach+0x24/0x40
>> [c002b2a5fa00] [c0526318] .bus_add_driver+0x2a8/0x370
>> [c002b2a5faa0] [c0528a5c] .driver_register+0x8c/0x170
>> [c002b2a5fb20] [c0465a54] .__pci_register_driver+0x44/0x60
>> [c002b2a5fb90] [c0b8efc8] .ipr_init+0x58/0x70
>> [c002b2a5fc10] [c000d20c] .do_one_initcall+0x5c/0x1c0
>> [c002b2a5fce0] [c0b44738] .kernel_init_freeable+0x280/0x360
>> [c002b2a5fdb0] [c000daec] .kernel_init+0x1c/0x130
>> [c002b2a5fe30] [c000baa0] .ret_from_kernel_thread+0x58/0xb8
>> Instruction dump:
>> f8010010 f821ff71 80e3000c 7c0004ac e94d0030 3d02ffbc 3928f4b8 7d295214
>> 81090004 3948 7d484378 79080fe2 <0b08> 2fa8 40de0050 91490004
>> ---[ end trace 5e18ae409f46392c ]---
>> ipr 0200:00:01.0: Initializing IOA.
>>
>> Thanks
>> -Sachin
>
Re: [PATCH repost] ptr_ring: fix race conditions when resizing
On Sun, Feb 19, 2017 at 12:52:48AM -0500, David Miller wrote: > From: "Michael S. Tsirkin" > Date: Sun, 19 Feb 2017 07:17:17 +0200 > > > Dave, could you merge this before 4.10? If not - I can try. > > I just sent my last pull request to Linus, please merge it to > him directly. > > Thanks. I missed the opportunity. Could you pls queue the fix for next release and copy stable? -- MST
Re: [PATCH V2 4/6] PM / domain: Register for PM QOS performance notifier
On 17-02-17, 15:54, Kevin Hilman wrote:
> Viresh Kumar writes:
>
> > Some platforms have the capability to configure the performance state of
> > their Power Domains. The performance levels are represented by positive
> > integer values, a lower value represents lower performance state.
> >
> > This patch registers the power domain framework for PM QOS performance
> > notifier in order to manage performance state of power domains.
>
> It seems to me it doesm't just register, but actually keeps track of the
> performance_state by always tracking the max.
Yes. Will update the commit log to make sure it is clear.
> > This also allows the power domain drivers to implement a
> > ->set_performance_state() callback, which will be called by the power
> > domain core from the notifier routine.
> >
> > Signed-off-by: Viresh Kumar
> > ---
> > drivers/base/power/domain.c | 98
> > -
> > include/linux/pm_domain.h | 5 +++
> > 2 files changed, 101 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> > index a73d79670a64..1158a07f92de 100644
> > --- a/drivers/base/power/domain.c
> > +++ b/drivers/base/power/domain.c
> > @@ -367,6 +367,88 @@ static int genpd_dev_pm_qos_notifier(struct
> > notifier_block *nb,
> > return NOTIFY_DONE;
> > }
> >
> > +static void update_domain_performance_state(struct generic_pm_domain
> > *genpd,
> > + int depth)
> > +{
> > + struct generic_pm_domain_data *pd_data;
> > + struct generic_pm_domain *subdomain;
> > + struct pm_domain_data *pdd;
> > + unsigned int state = 0;
> > + struct gpd_link *link;
> > +
> > + /* Traverse all devices within the domain */
> > + list_for_each_entry(pdd, &genpd->dev_list, list_node) {
> > + pd_data = to_gpd_data(pdd);
> > +
> > + if (pd_data->performance_state > state)
> > + state = pd_data->performance_state;
> > + }
>
> This seems to only update the state if it's bigger. Maybe I'm missing
> something here, but it seems like won't be able to lower the
> performance_state after it's been raised?
'state' is initialized to 0 to begin with and then the above loop
finds the highest state requested so far. The below code (after the
below loop) then changes the state if it isn't equal to the previous
one. That is, it would update the state if the new target state is
lower than the current one. Or am I missing a bug in there ?
> > + /* Traverse all subdomains within the domain */
> > + list_for_each_entry(link, &genpd->master_links, master_node) {
> > + subdomain = link->slave;
> > +
> > + if (subdomain->performance_state > state)
> > + state = subdomain->performance_state;
> > + }
>
> So subdomains are always assumed to influence the performance_state of
> the parent domains? Is that always the case?
It is true for the hardware we have to work on right now, but I would
assume that being the most common case.
> I suspect this should be
> probably be a reasonable default assumption, but maybe controlled with a
> flag.
Yeah, maybe we can have a flag to ignore a subdomain while doing the
calculations, but I would rather defer that to the first platform that
needs it and leave it as is for now. I am afraid that code may never
get used and maybe we should wait for a real case first.
> > + if (genpd->performance_state == state)
> > + return;
> > +
> > + genpd->performance_state = state;
> > +
> > + if (genpd->set_performance_state) {
> > + genpd->set_performance_state(genpd, state);
> > + return;
> > + }
>
> So is zero not a valid performance_state?
Zero is a *valid* performance state. Are you getting confused with the
above 'if' block which checks for a valid set_performance_state()
callback and not the performance level ?
> > + /* Propagate only if this domain has a single parent */
>
> Why? This limitation should be explained in the cover letter and
> changelog. I would also expect some sort of WARN here since this could
> otherwise be a rather silent failures.
I think this limitation can just be removed, but I am confused a bit.
I thought that support for multiple parent domains isn't yet there,
isn't it? And that few people are trying to add it in kernel and the
stuff is still under review. Like this thread:
https://lkml.org/lkml/2016/11/22/792
--
viresh
linux-next: Tree for Feb 20
Hi all, Changes since 20170217: The pci tree gained a conflict (probably) against Linus' tree. The kspp tree gained a conflict against the net-next tree. The tip tree gained a conflict against the net-next tree. The target-bva tree gained conflicts against the target-updates tree. Non-merge commits (relative to Linus' tree): 9790 10485 files changed, 445345 insertions(+), 205077 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 and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 254 trees (counting Linus' and 37 trees of bug fix patches pending for the current merge release). 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 (137d01df511b Fix missing sanity check in /dev/sg) Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP defines before declaring the functions) Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no longer relevant) Merging arm-current/fixes (9e3440481845 ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user()) Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in atari_get_hardware_list()) Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally) Merging powerpc-fixes/fixes (3f91a89d424a powerpc/64: Disable use of radix under a hypervisor) Merging sparc/master (f9a42e0d58cf Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (00ea1ceebe0d ipv6: release dst on error in ip6_dst_lookup_tail) Merging ipsec/master (e3dc847a5f85 vti6: Don't report path MTU below IPV6_MIN_MTU.) Merging netfilter/master (f95d7a46bc57 netfilter: ctnetlink: Fix regression in CTA_HELP processing) Merging ipvs/master (045169816b31 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading of incorrect firmware) Merging mac80211/master (0c8ef291d976 Merge branch 'rhashtable-allocation-failure-during-insertion') Merging sound-current/for-linus (af677166cf63 ALSA: hda - adding a new NV HDMI/DP codec ID in the driver) Merging pci-current/for-linus (afe3e4d11bdf PCI/PME: Restore pcie_pme_driver.remove) Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4) Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4) Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7) Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix Wmaybe-uninitialized warning) Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN device ID) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1) Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7) Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7) Merging input-current/for-linus (722c5ac708b4 Input: elan_i2c - add ELAN0605 to the ACPI table) Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key length for RFC4106) Merging ide/master (da095587e6be Revert "ide: Fix interface autodetection in legacy IDE driver (trial #2)") Merging vfio-fixes/for-linus (930a42ded3fe vfio/spapr_tce: Set window
Re: [PATCH v3] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs
(Really add Will this time ...)
On Mon, Feb 20, 2017 at 12:53:58PM +0800, Boqun Feng wrote:
> On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote:
> > On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> > > All the locking related cmpxchg's in the following functions are
> > > replaced with the _acquire variants:
> > > - pv_queued_spin_steal_lock()
> > > - trylock_clear_pending()
> > >
> > > This change should help performance on architectures that use LL/SC.
> > >
> > > On a 2-core 16-thread Power8 system with pvqspinlock explicitly
> > > enabled, the performance of a locking microbenchmark with and without
> > > this patch on a 4.10-rc8 kernel with Xinhui's PPC qspinlock patch
> > > were as follows:
> > >
> > > # of thread w/o patchwith patch % Change
> > > --- ---
> > >4 4053.3 Mop/s 4223.7 Mop/s +4.2%
> > >8 3310.4 Mop/s 3406.0 Mop/s +2.9%
> > > 12 2576.4 Mop/s 2674.6 Mop/s +3.8%
> > >
> > > Signed-off-by: Waiman Long
> > > ---
> > >
> > > v2->v3:
> > > - Reduce scope by relaxing cmpxchg's in fast path only.
> > >
> > > v1->v2:
> > > - Add comments in changelog and code for the rationale of the change.
> > >
> > > kernel/locking/qspinlock_paravirt.h | 15 +--
> > > 1 file changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/kernel/locking/qspinlock_paravirt.h
> > > b/kernel/locking/qspinlock_paravirt.h
> > > index e6b2f7a..a59dc05 100644
> > > --- a/kernel/locking/qspinlock_paravirt.h
> > > +++ b/kernel/locking/qspinlock_paravirt.h
> > > @@ -72,7 +72,7 @@ static inline bool pv_queued_spin_steal_lock(struct
> > > qspinlock *lock)
> > > struct __qspinlock *l = (void *)lock;
> > >
> > > if (!(atomic_read(&lock->val) & _Q_LOCKED_PENDING_MASK) &&
> > > - (cmpxchg(&l->locked, 0, _Q_LOCKED_VAL) == 0)) {
> > > + (cmpxchg_acquire(&l->locked, 0, _Q_LOCKED_VAL) == 0)) {
> > > qstat_inc(qstat_pv_lock_stealing, true);
> > > return true;
> > > }
> > > @@ -101,16 +101,16 @@ static __always_inline void clear_pending(struct
> > > qspinlock *lock)
> > >
> > > /*
> > > * The pending bit check in pv_queued_spin_steal_lock() isn't a memory
> > > - * barrier. Therefore, an atomic cmpxchg() is used to acquire the lock
> > > - * just to be sure that it will get it.
> > > + * barrier. Therefore, an atomic cmpxchg_acquire() is used to acquire the
> > > + * lock just to be sure that it will get it.
> > > */
> > > static __always_inline int trylock_clear_pending(struct qspinlock *lock)
> > > {
> > > struct __qspinlock *l = (void *)lock;
> > >
> > > return !READ_ONCE(l->locked) &&
> > > -(cmpxchg(&l->locked_pending, _Q_PENDING_VAL, _Q_LOCKED_VAL)
> > > - == _Q_PENDING_VAL);
> > > +(cmpxchg_acquire(&l->locked_pending, _Q_PENDING_VAL,
> > > + _Q_LOCKED_VAL) == _Q_PENDING_VAL);
> > > }
> > > #else /* _Q_PENDING_BITS == 8 */
> > > static __always_inline void set_pending(struct qspinlock *lock)
> > > @@ -138,7 +138,7 @@ static __always_inline int
> > > trylock_clear_pending(struct qspinlock *lock)
> > >*/
> > > old = val;
> > > new = (val & ~_Q_PENDING_MASK) | _Q_LOCKED_VAL;
> > > - val = atomic_cmpxchg(&lock->val, old, new);
> > > + val = atomic_cmpxchg_acquire(&lock->val, old, new);
> > >
> > > if (val == old)
> > > return 1;
> > > @@ -361,6 +361,9 @@ static void pv_kick_node(struct qspinlock *lock,
> > > struct mcs_spinlock *node)
> > >* observe its next->locked value and advance itself.
> > >*
> > >* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
> > > + *
> > > + * We can't used relaxed form of cmpxchg here as the loading of
> > > + * pn->state can happen before setting next->locked in some archs.
> > >*/
> > > if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != vcpu_halted)
> >
> > Hi Waiman.
> >
> > cmpxchg() does not guarantee the (here implied) smp_mb(), in general; c.f.,
> > e.g., arch/arm64/include/asm/atomic_ll_sc.h, where cmpxchg() get "compiled"
> > to something like:
> >
> > _loop: ldxr; eor; cbnz _exit; stlxr; cbnz _loop; dmb ish; _exit:
> >
>
> Yes, sorry for be late for this one.
>
> So Waiman, the fact is that in this case, we want the following code
> sequence:
>
> CPU 0 CPU 1
> =
> {pn->state = vcpu_running, node->locked = 0}
>
> smp_store_smb(&pn->state, vcpu_halted):
> WRITE_ONCE(pn->state, vcpu_halted);
> smp_mb();
> r1 = READ_ONCE(node->locked);
>
> arch_mcs_spin_unlock_contented();
> WRITE_ONCE(node->locked, 1)
>
>
Re: [PATCH v3] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs
On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote:
> On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> > All the locking related cmpxchg's in the following functions are
> > replaced with the _acquire variants:
> > - pv_queued_spin_steal_lock()
> > - trylock_clear_pending()
> >
> > This change should help performance on architectures that use LL/SC.
> >
> > On a 2-core 16-thread Power8 system with pvqspinlock explicitly
> > enabled, the performance of a locking microbenchmark with and without
> > this patch on a 4.10-rc8 kernel with Xinhui's PPC qspinlock patch
> > were as follows:
> >
> > # of thread w/o patchwith patch % Change
> > --- ---
> >4 4053.3 Mop/s 4223.7 Mop/s +4.2%
> >8 3310.4 Mop/s 3406.0 Mop/s +2.9%
> > 12 2576.4 Mop/s 2674.6 Mop/s +3.8%
> >
> > Signed-off-by: Waiman Long
> > ---
> >
> > v2->v3:
> > - Reduce scope by relaxing cmpxchg's in fast path only.
> >
> > v1->v2:
> > - Add comments in changelog and code for the rationale of the change.
> >
> > kernel/locking/qspinlock_paravirt.h | 15 +--
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/kernel/locking/qspinlock_paravirt.h
> > b/kernel/locking/qspinlock_paravirt.h
> > index e6b2f7a..a59dc05 100644
> > --- a/kernel/locking/qspinlock_paravirt.h
> > +++ b/kernel/locking/qspinlock_paravirt.h
> > @@ -72,7 +72,7 @@ static inline bool pv_queued_spin_steal_lock(struct
> > qspinlock *lock)
> > struct __qspinlock *l = (void *)lock;
> >
> > if (!(atomic_read(&lock->val) & _Q_LOCKED_PENDING_MASK) &&
> > - (cmpxchg(&l->locked, 0, _Q_LOCKED_VAL) == 0)) {
> > + (cmpxchg_acquire(&l->locked, 0, _Q_LOCKED_VAL) == 0)) {
> > qstat_inc(qstat_pv_lock_stealing, true);
> > return true;
> > }
> > @@ -101,16 +101,16 @@ static __always_inline void clear_pending(struct
> > qspinlock *lock)
> >
> > /*
> > * The pending bit check in pv_queued_spin_steal_lock() isn't a memory
> > - * barrier. Therefore, an atomic cmpxchg() is used to acquire the lock
> > - * just to be sure that it will get it.
> > + * barrier. Therefore, an atomic cmpxchg_acquire() is used to acquire the
> > + * lock just to be sure that it will get it.
> > */
> > static __always_inline int trylock_clear_pending(struct qspinlock *lock)
> > {
> > struct __qspinlock *l = (void *)lock;
> >
> > return !READ_ONCE(l->locked) &&
> > - (cmpxchg(&l->locked_pending, _Q_PENDING_VAL, _Q_LOCKED_VAL)
> > - == _Q_PENDING_VAL);
> > + (cmpxchg_acquire(&l->locked_pending, _Q_PENDING_VAL,
> > + _Q_LOCKED_VAL) == _Q_PENDING_VAL);
> > }
> > #else /* _Q_PENDING_BITS == 8 */
> > static __always_inline void set_pending(struct qspinlock *lock)
> > @@ -138,7 +138,7 @@ static __always_inline int trylock_clear_pending(struct
> > qspinlock *lock)
> > */
> > old = val;
> > new = (val & ~_Q_PENDING_MASK) | _Q_LOCKED_VAL;
> > - val = atomic_cmpxchg(&lock->val, old, new);
> > + val = atomic_cmpxchg_acquire(&lock->val, old, new);
> >
> > if (val == old)
> > return 1;
> > @@ -361,6 +361,9 @@ static void pv_kick_node(struct qspinlock *lock, struct
> > mcs_spinlock *node)
> > * observe its next->locked value and advance itself.
> > *
> > * Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
> > +*
> > +* We can't used relaxed form of cmpxchg here as the loading of
> > +* pn->state can happen before setting next->locked in some archs.
> > */
> > if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != vcpu_halted)
>
> Hi Waiman.
>
> cmpxchg() does not guarantee the (here implied) smp_mb(), in general; c.f.,
> e.g., arch/arm64/include/asm/atomic_ll_sc.h, where cmpxchg() get "compiled"
> to something like:
>
> _loop: ldxr; eor; cbnz _exit; stlxr; cbnz _loop; dmb ish; _exit:
>
Yes, sorry for be late for this one.
So Waiman, the fact is that in this case, we want the following code
sequence:
CPU 0 CPU 1
=
{pn->state = vcpu_running, node->locked = 0}
smp_store_smb(&pn->state, vcpu_halted):
WRITE_ONCE(pn->state, vcpu_halted);
smp_mb();
r1 = READ_ONCE(node->locked);
arch_mcs_spin_unlock_contented();
WRITE_ONCE(node->locked, 1)
cmpxchg(&pn->state,
vcpu_halted, vcpu_hashed);
never ends up in:
r1 == 0 && cmpxchg fail(i.e. the read part of cmpxchg reads the
value vcpu_running).
We can have such a guarantee if cmpxchg has a smp_mb() before its load
part, whi
Re: [PATCH v2 2/3] watchdog: sama5d4: Fix setting timeout when watchdog is disabled
On 02/19/2017 03:52 PM, Alexandre Belloni wrote: On 19/02/2017 at 08:57:35 -0800, Guenter Roeck wrote: That means if the watchdog is running, the timeout would not be updated. It should be updated no matter if it is running or not. No, it is enabling the watchdog, then changing WDV and WDD and finally disabling the watchdog if necessary. So, WDV and WDD are always changed. You are correct. Sorry for the noise. Seems odd that the watchdog must be _running_ to change the timeout. Usually, if there is a restriction, it is the opposite. I hope this doesn't cause race conditions, where the watchdog fires immediately after being enabled due to a low timeout. While it is difficult to reproduce, I can confirm it races and sometimes reset the SoC without any good reason. It doesn't matter whether it is disabled or not Outch :-(. I've raised the issue at Atmel last Thursday so I don't have any answer yet. Please keep us in the loop. Thanks, Guenter
Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change
Pan Xinhui writes:
> 在 2017/2/17 14:05, Michael Ellerman 写道:
>> Pan Xinhui writes:
>>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>>> index 9c0e17c..f6e5c3d 100644
>>> --- a/arch/powerpc/xmon/xmon.c
>>> +++ b/arch/powerpc/xmon/xmon.c
>>> @@ -76,6 +76,7 @@ static int xmon_gate;
>>> #endif /* CONFIG_SMP */
>>>
>>> static unsigned long in_xmon __read_mostly = 0;
>>> +static int xmon_off = !IS_ENABLED(CONFIG_XMON_DEFAULT);
>>
>> I think the logic would probably clearer if we invert this to become
>> xmon_on.
>>
> yep, make sense.
>
>>> @@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void)
>>> __initcall(setup_xmon_sysrq);
>>> #endif /* CONFIG_MAGIC_SYSRQ */
>>>
>>> -static int __initdata xmon_early, xmon_off;
>>> +static int __initdata xmon_early;
>>>
>>> static int __init early_parse_xmon(char *p)
>>> {
>>> if (!p || strncmp(p, "early", 5) == 0) {
>>> /* just "xmon" is equivalent to "xmon=early" */
>>> - xmon_init(1);
>>> xmon_early = 1;
>>> + xmon_off = 0;
>>> } else if (strncmp(p, "on", 2) == 0)
>>> - xmon_init(1);
>>> + xmon_off = 0;
>>
>> You've just changed the timing of when xmon gets enabled for the above
>> two cases, from here which is called very early, to xmon_setup() which
>> is called much later in boot.
>>
>> That effectively disables xmon for most of the boot, which we do not
>> want to do.
>>
> Although it is not often that kernel got stucked during boot.
I hope you're joking! :)
cheers
Re: [PATCH] ipmi: bt-bmc: Use a regmap for register access
Hi Cory, On Tue, 2016-12-06 at 16:02 +0100, Cédric Le Goater wrote: > [ this is a resend bc of some mailing list issues] > > On 12/06/2016 03:57 AM, Andrew Jeffery wrote: > > The registers for the bt-bmc device live under the Aspeed LPC > > controller. Devicetree bindings have recently been introduced for the > > LPC controller where the "host" portion of the LPC register space is > > described as a syscon device. Future devicetrees describing the bt-bmc > > device should nest its node under the appropriate "simple-mfd", "syscon" > > compatible node. > > > > This change allows the bt-bmc driver to function with both syscon and > > non-syscon- based devicetree descriptions by always using a regmap for > > register access, either retrieved from the parent syscon device or > > instantiated if none exists. > > > > The patch has been tested on an OpenPOWER Palmetto machine, successfully > > booting, rebooting and powering down the host. > > > > Signed-off-by: Andrew Jeffery > > It would be nice to have an example of the associated binding. > I did not see it. A part from that : > > Reviewed-by: Cédric Le Goater Will this make it into 4.11? Cheers, Andrew signature.asc Description: This is a digitally signed message part
Re: [PATCH 06/35] powerpc: Convert remaining uses of pr_warning to pr_warn
On Mon, 2017-02-20 at 15:40 +1100, Michael Ellerman wrote: > Joe Perches writes: > > > To enable eventual removal of pr_warning > > > > This makes pr_warn use consistent for arch/powerpc > > > > Prior to this patch, there were 36 uses of pr_warning and > > 217 uses of pr_warn in arch/powerpc > > > > Signed-off-by: Joe Perches > > Can I take this via the powerpc tree, or do you want to merge them as a > series? Well, I expect it'd be better if you merge it.
Re: [PATCH 06/35] powerpc: Convert remaining uses of pr_warning to pr_warn
Joe Perches writes: > To enable eventual removal of pr_warning > > This makes pr_warn use consistent for arch/powerpc > > Prior to this patch, there were 36 uses of pr_warning and > 217 uses of pr_warn in arch/powerpc > > Signed-off-by: Joe Perches Can I take this via the powerpc tree, or do you want to merge them as a series? cheers
Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount
James Bottomley writes: > On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote: >> I think I am missing something but I completely do not understand >> that subthread that says use file marks and perform the work in the >> vfs. The problem is that fundamentally we need multiple mappings and >> I don't see a mark on a file (even an inherited mark) providing the >> mapping so I don't see the point. > > The point of the mark is that it's a statement by the system > administrator that the underlying subtree is safe to be mounted by an > unprivileged container in the containers user view (i.e. with > current_user_ns() == s_user_ns). For the unprivileged container > there's no real arbitrary s_user_ns use case because the unprivileged > container must prove it can set up the mapping, so it would likely > always be mounting from within a user_ns with the mapping it wanted. As a statement that it is ok for the unprivileged mapping code to operate that seems reasonable. I don't currently the need for such an ok from the system adminstrator, but if you need it a flag that propagates to children and child directories seems reasonable. Eric
Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction
On Mon, Feb 20, 2017 at 1:04 PM, Zain Wang wrote: > 在 2017/2/20 10:40, Tomasz Figa 写道: >> On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote: >>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >>> index 303083a..5384aca 100644 >>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >>> @@ -1162,5 +1162,5 @@ ssize_t analogix_dp_transfer(struct >>> analogix_dp_device *dp, >>> (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ) >>> msg->reply = DP_AUX_NATIVE_REPLY_ACK; >>> >>> - return num_transferred > 0 ? num_transferred : -EBUSY; >>> + return (num_transferred == msg->size) ? num_transferred : -EBUSY; >> >> I might be missing something but, looking at the code, I don't see any >> possibility of num_transferred ever being different than msg->size. To >> be honest, it doesn't seem to even make any sense keeping the local >> variable there, because msg->size can be simply always returned, as >> errors are handled by jumping to aux_error label. > > Yeah, I agree with you. > The better way to fix this issue is to revert the changes > https://patchwork.kernel.org/patch/9411711/ > (returning num_transferred directly may be better here) I think it's still not enough to clean up the code completely. It should be just enough to remove num_transferred completely and simply return msg->size at the end. Best regards, Tomasz
Re: [PATCH] switchtec: cleanup cdev init
On 19/02/17 02:43 PM, Dan Williams wrote: > Is this race present for all file operations? I've only seen it with > mmap() and late faults. So if these other drivers do not support mmap > it's not clear they can trigger the failure. I don't see how it's related to mmap only. I think there's a number of variations on this but the race I see happens if you try to take a reference to the device in the open/close handlers of a char device file. If a driver puts the last remaining reference in the release handler, then the device structure will be freed, and on returning from the release handler, the char_dev code will try to put the last reference to the cdev structure which may have already been free'd. There needs to be a way for the cdev structure to take a reference on the device structure so it doesn't get freed and the kobj.parent trick seems to accomplish this fairly well. Really, in any situation where there's a cdev and a device in the same structure, the life cycles of the two become linked but their reference counts are not and that is the problem here. I feel like a number of developers have made the same realization independently so this would probably be a good thing to clean up. See these commits for examples spanning around 5 years: 4a215aa Input: fix use-after-free introduced with dynamic minor changes 0d5b7da iio: Prevent race between IIO chardev opening and IIO device ba0ef85 tpm: Fix initialization of the cdev Also, seems both my brother and I have independently looked into this exact issue: https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg25692.html So, I think it would be a good idea to clean it up with Dan's proposed API cleanup. If I have some time tomorrow, I may throw together a patch set with that patch and the changes to the instances around the kernel. Logan
Re: [PATCH v3] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs
On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> All the locking related cmpxchg's in the following functions are
> replaced with the _acquire variants:
> - pv_queued_spin_steal_lock()
> - trylock_clear_pending()
>
> This change should help performance on architectures that use LL/SC.
>
> On a 2-core 16-thread Power8 system with pvqspinlock explicitly
> enabled, the performance of a locking microbenchmark with and without
> this patch on a 4.10-rc8 kernel with Xinhui's PPC qspinlock patch
> were as follows:
>
> # of thread w/o patchwith patch % Change
> --- ---
>4 4053.3 Mop/s 4223.7 Mop/s +4.2%
>8 3310.4 Mop/s 3406.0 Mop/s +2.9%
> 12 2576.4 Mop/s 2674.6 Mop/s +3.8%
>
> Signed-off-by: Waiman Long
> ---
>
> v2->v3:
> - Reduce scope by relaxing cmpxchg's in fast path only.
>
> v1->v2:
> - Add comments in changelog and code for the rationale of the change.
>
> kernel/locking/qspinlock_paravirt.h | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/locking/qspinlock_paravirt.h
> b/kernel/locking/qspinlock_paravirt.h
> index e6b2f7a..a59dc05 100644
> --- a/kernel/locking/qspinlock_paravirt.h
> +++ b/kernel/locking/qspinlock_paravirt.h
> @@ -72,7 +72,7 @@ static inline bool pv_queued_spin_steal_lock(struct
> qspinlock *lock)
> struct __qspinlock *l = (void *)lock;
>
> if (!(atomic_read(&lock->val) & _Q_LOCKED_PENDING_MASK) &&
> - (cmpxchg(&l->locked, 0, _Q_LOCKED_VAL) == 0)) {
> + (cmpxchg_acquire(&l->locked, 0, _Q_LOCKED_VAL) == 0)) {
> qstat_inc(qstat_pv_lock_stealing, true);
> return true;
> }
> @@ -101,16 +101,16 @@ static __always_inline void clear_pending(struct
> qspinlock *lock)
>
> /*
> * The pending bit check in pv_queued_spin_steal_lock() isn't a memory
> - * barrier. Therefore, an atomic cmpxchg() is used to acquire the lock
> - * just to be sure that it will get it.
> + * barrier. Therefore, an atomic cmpxchg_acquire() is used to acquire the
> + * lock just to be sure that it will get it.
> */
> static __always_inline int trylock_clear_pending(struct qspinlock *lock)
> {
> struct __qspinlock *l = (void *)lock;
>
> return !READ_ONCE(l->locked) &&
> -(cmpxchg(&l->locked_pending, _Q_PENDING_VAL, _Q_LOCKED_VAL)
> - == _Q_PENDING_VAL);
> +(cmpxchg_acquire(&l->locked_pending, _Q_PENDING_VAL,
> + _Q_LOCKED_VAL) == _Q_PENDING_VAL);
> }
> #else /* _Q_PENDING_BITS == 8 */
> static __always_inline void set_pending(struct qspinlock *lock)
> @@ -138,7 +138,7 @@ static __always_inline int trylock_clear_pending(struct
> qspinlock *lock)
>*/
> old = val;
> new = (val & ~_Q_PENDING_MASK) | _Q_LOCKED_VAL;
> - val = atomic_cmpxchg(&lock->val, old, new);
> + val = atomic_cmpxchg_acquire(&lock->val, old, new);
>
> if (val == old)
> return 1;
> @@ -361,6 +361,9 @@ static void pv_kick_node(struct qspinlock *lock, struct
> mcs_spinlock *node)
>* observe its next->locked value and advance itself.
>*
>* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
> + *
> + * We can't used relaxed form of cmpxchg here as the loading of
> + * pn->state can happen before setting next->locked in some archs.
>*/
> if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != vcpu_halted)
Hi Waiman.
cmpxchg() does not guarantee the (here implied) smp_mb(), in general; c.f.,
e.g., arch/arm64/include/asm/atomic_ll_sc.h, where cmpxchg() get "compiled"
to something like:
_loop: ldxr; eor; cbnz _exit; stlxr; cbnz _loop; dmb ish; _exit:
Andrea
> return;
> --
> 1.8.3.1
>
Re: [PATCH v6 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info
Hi Peter,
On Thursday 16 February 2017 03:58 PM, Peter Zijlstra wrote:
On Wed, Feb 08, 2017 at 02:01:24PM +0530, Hari Bathini wrote:
With the advert of container technologies like docker, that depend
on namespaces for isolation, there is a need for tracing support for
namespaces. This patch introduces new PERF_RECORD_NAMESPACES event
for tracing based on namespaces related info. This event records
the device and inode numbers for every namespace of all processes.
While device number is same for all namespaces currently, that may
'While device numbers are the same ..." ?
change in future, to avoid the need for a namespace of namespaces.
Unfinished sentence
Unnecessary comma spoiled the sentence, I guess.
Recording device number along with inode number will take care of such
scenario.
More words on why this is so? Because I've no clue.
This should have read:
"Each namespace has a combination of device and inode numbers. Though
every namespace has the same device number currently, that may change
in future to avoid the need for a namespace of namespaces. Considering
such possibility, record both device and inode numbers separately for
each namespace."
Will update changelog accordingly..
@@ -6584,6 +6590,135 @@ void perf_event_comm(struct task_struct *task, bool
exec)
}
/*
+ * namespaces tracking
+ */
+
+struct namespaces_event_id {
+ struct perf_event_headerheader;
+
+ u32 pid;
+ u32 tid;
+ u32 nr_namespaces;
+ struct perf_ns_link_infolink_info[NAMESPACES_MAX];
+};
Contains the same hole and makes the record depend on architecture
alignment requirements.
Ugh! Let me change nr_namespaces type to u64 and also drop name field
in perf_ns_link_info struct.
+static void perf_fill_ns_link_info(struct perf_ns_link_info *ns_link_info,
+ struct task_struct *task,
+ const struct proc_ns_operations *ns_ops)
+{
+ struct path ns_path;
+ struct inode *ns_inode;
+ void *error;
+
+ error = ns_get_path(&ns_path, task, ns_ops);
+ if (!error) {
+ snprintf(ns_link_info->name, NS_NAME_SIZE,
+"%s", ns_path.dentry->d_iname);
+
+ ns_inode = ns_path.dentry->d_inode;
+ ns_link_info->dev = new_encode_dev(ns_inode->i_sb->s_dev);
+ ns_link_info->ino = ns_inode->i_ino;
+ }
+}
+
+static void perf_event_namespaces_output(struct perf_event *event,
+void *data)
+{
+ struct perf_namespaces_event *namespaces_event = data;
+ struct perf_output_handle handle;
+ struct perf_sample_data sample;
+ struct namespaces_event_id *ei;
+ struct task_struct *task = namespaces_event->task;
+ int ret;
+
+ if (!perf_event_namespaces_match(event))
+ return;
+
+ ei = &namespaces_event->event_id;
+ perf_event_header__init_id(&ei->header, &sample, event);
+ ret = perf_output_begin(&handle, event, ei->header.size);
+ if (ret)
+ return;
+
+ ei->pid = perf_event_pid(event, task);
+ ei->tid = perf_event_tid(event, task);
+
+ ei->nr_namespaces = NAMESPACES_MAX;
+
+ perf_fill_ns_link_info(&ei->link_info[MNT_NS_INDEX],
+ task, &mntns_operations);
+
+#ifdef CONFIG_USER_NS
+ perf_fill_ns_link_info(&ei->link_info[USER_NS_INDEX],
+ task, &userns_operations);
+#endif
+#ifdef CONFIG_NET_NS
+ perf_fill_ns_link_info(&ei->link_info[NET_NS_INDEX],
+ task, &netns_operations);
+#endif
+#ifdef CONFIG_UTS_NS
+ perf_fill_ns_link_info(&ei->link_info[UTS_NS_INDEX],
+ task, &utsns_operations);
+#endif
+#ifdef CONFIG_IPC_NS
+ perf_fill_ns_link_info(&ei->link_info[IPC_NS_INDEX],
+ task, &ipcns_operations);
+#endif
+#ifdef CONFIG_PID_NS
+ perf_fill_ns_link_info(&ei->link_info[PID_NS_INDEX],
+ task, &pidns_operations);
+#endif
+#ifdef CONFIG_CGROUPS
+ perf_fill_ns_link_info(&ei->link_info[CGROUP_NS_INDEX],
+ task, &cgroupns_operations);
+#endif
Two points here, since you've given these thingies a string identifier,
do you still need to rely on their positional index? If not, you could
generate smaller events if we lack some of these CONFIG knobs.
Dropping name field. So, I don't think this applies now..
Secondly, does anything in here depend on @event? Afaict you're
generating the exact same information for each event.
The reason we set {pid,tid} for each event is because of PID_NS, we
report the pid number as per the namespace associated with the event.
But from what I can tell, there is no such namespace of namespaces
dependency her
Re: [PATCH] Add pidfs filesystem
Alexey Gladkov writes:
> The pidfs filesystem contains a subset of the /proc file system which
> contains only information about the processes.
My summary of your motivation.
It hurts when I create a container with a processes with uid 0 inside of
it. This generates lots of hacks to attempt to limit uid 0.
My answer: Don't run a container with a real uid 0 inside of it.
Any reasonable permission check will on proc files
will keep you safe if your container does not have a real uid 0 in it.
That said I am not opposed in principle to a pidfs. And the idea of
using overlay for this purpose is intriguing. I have not looked at it
in enough detail comment on the technical merits.
Eric
> Some of the container virtualization systems are mounted /proc inside
> the container. This is done in most cases to operate with information
> about the processes. Knowing that /proc filesystem is not fully
> virtualized they are mounted on top of dangerous places empty files or
> directories (for exmaple /proc/kcore, /sys/firmware, etc.).
>
> The structure of this filesystem is dynamic and any module can create a
> new object which will not necessarily be virtualized. There are
> proprietary modules that aren't in the mainline whose work we can not
> verify.
>
> This opens up a potential threat to the system. The developers of the
> virtualization system can't predict all dangerous places in /proc by
> definition.
>
> A more effective solution would be to mount into the container only what
> is necessary and ignore the rest.
>
> Right now there is the opportunity to pass in the container any port of
> the /proc filesystem using mount --bind expect the pids.
>
> This patch allows to mount only the part of /proc related to pids
> without rest objects. Since this is an addon to /proc, flags applied to
> /proc have an effect on this pidfs filesystem.
>
> Why not implement it as another flag to /proc ?
>
> The /proc flags is stored in the pid_namespace and are global for
> namespace. It means that if you add a flag to hide all except the pids,
> then it will act on all mounted instances of /proc.
>
> Originally the idea was that the container will be mounted only pidfs
> and additional required files will be mounted on top using the
> overlayfs. But I found out that /proc does not support overlayfs and
> does not allow to mount anything on top or under it.
>
> My question is whether it's possible to add overlayfs support for /proc?
>
> Cc: Kirill A. Shutemov
> Signed-off-by: Alexey Gladkov
> ---
> Documentation/filesystems/pidfs.txt | 16
> fs/proc/Kconfig | 8
> fs/proc/inode.c | 8 +++-
> fs/proc/internal.h | 2 +
> fs/proc/root.c | 76
> ++---
> fs/proc/self.c | 6 +++
> fs/proc/thread_self.c | 6 +++
> include/linux/pid_namespace.h | 5 +++
> 8 files changed, 119 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/filesystems/pidfs.txt
>
> diff --git a/Documentation/filesystems/pidfs.txt
> b/Documentation/filesystems/pidfs.txt
> new file mode 100644
> index 000..ce958a5
> --- /dev/null
> +++ b/Documentation/filesystems/pidfs.txt
> @@ -0,0 +1,16 @@
> +The PIDFS Filesystem
> +
> +
> +The pidfs filesystem contains a subset of the /proc file system which
> contains
> +only information about the processes. The link self points to the process
> +reading the file system. All other special files and directories in /proc are
> +not available in this filesystem.
> +
> +The pidfs is not an independent filesystem, its implementation shares code
> +with /proc.
> +
> +All mount options applicable to /proc filesystem are also applicable
> +to pidfs filesystem. For example, access to the information in /proc/[pid]
> +directories can be restricted using hidepid option.
> +
> +To get more information about the processes read the proc.txt
> diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
> index 1ade120..fa568f6 100644
> --- a/fs/proc/Kconfig
> +++ b/fs/proc/Kconfig
> @@ -43,6 +43,14 @@ config PROC_VMCORE
> help
> Exports the dump image of crashed kernel in ELF format.
>
> +config PROC_PIDFS
> + bool "pidfs file system support"
> + depends on PROC_FS
> + default n
> + help
> + The pidfs filesystem contains a subset of the /proc file system
> + which contains only information only about the processes.
> +
> config PROC_SYSCTL
> bool "Sysctl support (/proc/sys)" if EXPERT
> depends on PROC_FS
> diff --git a/fs/proc/inode.c b/fs/proc/inode.c
> index 783bc19..1be65b4 100644
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -474,12 +474,16 @@ struct inode *proc_get_inode(struct super_block *sb,
> struct proc_dir_entry *de)
> int proc_fill_super(struct super_block *s, void *data, int silent)
> {
> struct pid_namespace *ns = get_pid_ns(s->s_fs_info);
> +
Re: [PATCH v2] MAINTAINERS: cpufreq: add bmips-cpufreq.c
On 19 February 2017 at 19:29, Viresh Kumar wrote: > On 17-02-17, 12:27, Markus Mayer wrote: >> From: Markus Mayer >> >> Add maintainer information for bmips-cpufreq.c. >> >> Signed-off-by: Markus Mayer >> Acked-by: Florian Fainelli >> --- >> >> This is based on PM's linux-next from today (February 17). >> >> This patch could be squashed into patch 3/4 of the original series if that >> is acceptable (see [1]) or it can remain separate. >> >> [1] https://lkml.org/lkml/2017/2/7/775 >> >> Changes in v2: >> - added bcm-kernel-feedback-l...@broadcom.com >> >> MAINTAINERS | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 107c10e..d4ac248 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -2692,6 +2692,13 @@ F: drivers/irqchip/irq-brcmstb* >> F: include/linux/bcm963xx_nvram.h >> F: include/linux/bcm963xx_tag.h >> >> +BROADCOM BMIPS CPUFREQ DRIVER >> +M: Markus Mayer >> +M: bcm-kernel-feedback-l...@broadcom.com > > Isn't this a list as well? Shouldn't this be L: ? We used to do that, but then there was a discussion at some point in the past (I don't have the link handy for it at this point), where it was suggested that we use M: for the Broadcom list, because it is a private, closed list (i.e. you can't just go and subscribe). It does reach a bunch of folks at Broadcom, however, who work on upstreaming. Therefore, the reasoning was that it fits the "maintainer" category better than the "list" category (where people might expect to be able to subscribe or find a public archive). >> +L: linux...@vger.kernel.org >> +S: Maintained >> +F: drivers/cpufreq/bmips-cpufreq.c >> + >> BROADCOM TG3 GIGABIT ETHERNET DRIVER >> M: Siva Reddy Kallam >> M: Prashant Sreedharan > > -- > viresh
Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction
Hi Tomasz, 在 2017/2/20 10:40, Tomasz Figa 写道: Hi Zain, On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote: The analogix_dp_transfer() will return -EBUSY if num_transferred is zero. But sometimes we will send a bare address packet to start the transaction, like drm_dp_i2c_xfer() show: .. /* Send a bare address packet to start the transaction. * Zero sized messages specify an address only (bare * address) transaction. */ msg.buffer = NULL; msg.size = 0; err = drm_dp_i2c_do_msg(aux, &msg); .. In this case, the msg->size is zero, so the num_transferred will be zero too. We can't return -EBUSY here, let's we return num_transferred if num_transferred equals msg->size. Please see my question inline. Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c index 303083a..5384aca 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c @@ -1162,5 +1162,5 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device *dp, (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ) msg->reply = DP_AUX_NATIVE_REPLY_ACK; - return num_transferred > 0 ? num_transferred : -EBUSY; + return (num_transferred == msg->size) ? num_transferred : -EBUSY; I might be missing something but, looking at the code, I don't see any possibility of num_transferred ever being different than msg->size. To be honest, it doesn't seem to even make any sense keeping the local variable there, because msg->size can be simply always returned, as errors are handled by jumping to aux_error label. Yeah, I agree with you. The better way to fix this issue is to revert the changes https://patchwork.kernel.org/patch/9411711/ (returning num_transferred directly may be better here) Maybe we can revert the changes above with some new comment. @Sean, How do you think about Tomasz's comment? Thanks Zain Best regards, Tomasz
[PATCH net-next V2] virito-net: set queues after reset during xdp_set
We set queues before reset which will cause a crash[1]. This is
because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs
number to do the correct detection. So fix this by
- passing xdp queue pairs and current queue pairs to virtnet_reset()
- change vi->xdp_qp after reset but before refill, to make sure both
free_unused_bufs() and refill can make correct detection of XDP.
- remove the duplicated queue pairs setting before virtnet_reset()
since we will do it inside virtnet_reset()
[1]
[ 74.328168] general protection fault: [#1] SMP
[ 74.328625] Modules linked in: nfsd xfs libcrc32c virtio_net virtio_pci
[ 74.329117] CPU: 0 PID: 2849 Comm: xdp2 Not tainted 4.10.0-rc7+ #499
[ 74.329577] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
[ 74.330424] task: 88007a894000 task.stack: c90004388000
[ 74.330844] RIP: 0010:skb_release_head_state+0x28/0x80
[ 74.331298] RSP: 0018:c9000438b8d0 EFLAGS: 00010206
[ 74.331676] RAX: RBX: 88007ad96300 RCX:
[ 74.332217] RDX: 88007fc137a8 RSI: 88007fc0db28 RDI: 0001bf0001be
[ 74.332758] RBP: c9000438b8d8 R08: 0005008f R09: 05f9
[ 74.333274] R10: 88007d001700 R11: 820a8a4d R12: 88007ad96300
[ 74.333787] R13: 0002 R14: 880036604000 R15: 77ff8000
[ 74.334308] FS: 7fc70d8a7b40() GS:88007fc0()
knlGS:
[ 74.334891] CS: 0010 DS: ES: CR0: 80050033
[ 74.335314] CR2: 7fff4144a710 CR3: 7ab56000 CR4: 003406f0
[ 74.335830] DR0: DR1: DR2:
[ 74.336373] DR3: DR6: fffe0ff0 DR7: 0400
[ 74.336895] Call Trace:
[ 74.337086] skb_release_all+0xd/0x30
[ 74.337356] consume_skb+0x2c/0x90
[ 74.337607] free_unused_bufs+0x1ff/0x270 [virtio_net]
[ 74.337988] ? vp_synchronize_vectors+0x3b/0x60 [virtio_pci]
[ 74.338398] virtnet_xdp+0x21e/0x440 [virtio_net]
[ 74.338741] dev_change_xdp_fd+0x101/0x140
[ 74.339048] do_setlink+0xcf4/0xd20
[ 74.339304] ? symcmp+0xf/0x20
[ 74.339529] ? mls_level_isvalid+0x52/0x60
[ 74.339828] ? mls_range_isvalid+0x43/0x50
[ 74.340135] ? nla_parse+0xa0/0x100
[ 74.340400] rtnl_setlink+0xd4/0x120
[ 74.340664] ? cpumask_next_and+0x30/0x50
[ 74.340966] rtnetlink_rcv_msg+0x7f/0x1f0
[ 74.341259] ? sock_has_perm+0x59/0x60
[ 74.341586] ? napi_consume_skb+0xe2/0x100
[ 74.342010] ? rtnl_newlink+0x890/0x890
[ 74.342435] netlink_rcv_skb+0x92/0xb0
[ 74.342846] rtnetlink_rcv+0x23/0x30
[ 74.343277] netlink_unicast+0x162/0x210
[ 74.343677] netlink_sendmsg+0x2db/0x390
[ 74.343968] sock_sendmsg+0x33/0x40
[ 74.344233] SYSC_sendto+0xee/0x160
[ 74.344482] ? SYSC_bind+0xb0/0xe0
[ 74.344806] ? sock_alloc_file+0x92/0x110
[ 74.345106] ? fd_install+0x20/0x30
[ 74.345360] ? sock_map_fd+0x3f/0x60
[ 74.345586] SyS_sendto+0x9/0x10
[ 74.345790] entry_SYSCALL_64_fastpath+0x1a/0xa9
[ 74.346086] RIP: 0033:0x7fc70d1b8f6d
[ 74.346312] RSP: 002b:7fff4144a708 EFLAGS: 0246 ORIG_RAX:
002c
[ 74.346785] RAX: ffda RBX: RCX: 7fc70d1b8f6d
[ 74.347244] RDX: 002c RSI: 7fff4144a720 RDI: 0003
[ 74.347683] RBP: 0003 R08: R09:
[ 74.348544] R10: R11: 0246 R12: 7fff4144bd90
[ 74.349082] R13: 0002 R14: 0002 R15: 7fff4144cda0
[ 74.349607] Code: 00 00 00 55 48 89 e5 53 48 89 fb 48 8b 7f 58 48 85 ff 74
0e 40 f6 c7 01 74 3d 48 c7 43 58 00 00 00 00 48 8b 7b 68 48 85 ff 74 05 ff
0f 74 20 48 8b 43 60 48 85 c0 74 14 65 8b 15 f3 ab 8d 7e
[ 74.351008] RIP: skb_release_head_state+0x28/0x80 RSP: c9000438b8d0
[ 74.351625] ---[ end trace fe6e19fd11cfc80b ]---
Fixes: 2de2f7f40ef9 ("virtio_net: XDP support for adjust_head")
Cc: John Fastabend
Signed-off-by: Jason Wang
---
Changes from V1:
- passing xdp_qp and curr_qp to virtnet_reset() to refill correctly
- remove the duplicated queue pair setting after virtnet_reset()
---
drivers/net/virtio_net.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 11e2853..d12e5d6 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1737,7 +1737,7 @@ static int virtnet_restore_up(struct virtio_device *vdev)
return err;
}
-static int virtnet_reset(struct virtnet_info *vi)
+static int virtnet_reset(struct virtnet_info *vi, int curr_qp, int xdp_qp)
{
struct virtio_device *dev = vi->vdev;
int ret;
@@ -1755,10 +1755,11 @@ static int virtnet_reset(struct virtnet_info *vi)
if (ret)
goto err;
+ vi->xdp_queue_pairs = xdp_qp;
r
[PATCH] MIPS:wrong usage of l_exc_copy in octeon-memcpy.S
l_exc_copy() is usually to be used like this: 1 EXC( LOADt0, UNIT(0)(src), l_exc) 2 EXC( LOADt1, UNIT(1)(src), l_exc_copy) 3 EXC( LOADt2, UNIT(2)(src), l_exc_copy) 4 EXC( LOADt3, UNIT(3)(src), l_exc_copy) When the fault occurs on row 4, l_exc_copy will get the bad addr through THREAD_BUADDR(), complete the copy of row 1,2 and 3, and then return the len that has not been copied. l_exc_copy assumes the src is smaller thann the bad addr.It will increase src by 1 until reach the bad addr. octeon-memcpy.S use the l_exc_copy with wrong way which make src could be greater than bad addr. We will fix it in this patch. We add the max offset of LOAD to 15 here to fix the issue without adding new commands . Howerver, the side effect is that, when LOAD fails in few case, l_exc_copy has to copy more. Signed-off-by: jianchao.wang --- arch/mips/cavium-octeon/octeon-memcpy.S | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/arch/mips/cavium-octeon/octeon-memcpy.S b/arch/mips/cavium-octeon/octeon-memcpy.S index 64e08df..b0fe98e 100644 --- a/arch/mips/cavium-octeon/octeon-memcpy.S +++ b/arch/mips/cavium-octeon/octeon-memcpy.S @@ -205,22 +205,22 @@ EXC( LOADt3, UNIT(7)(src), l_exc_copy) EXC( STORE t0, UNIT(4)(dst), s_exc_p12u) EXC( STORE t1, UNIT(5)(dst), s_exc_p11u) EXC( STORE t2, UNIT(6)(dst), s_exc_p10u) - ADD src, src, 16*NBYTES EXC( STORE t3, UNIT(7)(dst), s_exc_p9u) +EXC( LOADt0, UNIT(8)(src), l_exc_copy) +EXC( LOADt1, UNIT(9)(src), l_exc_copy) +EXC( LOADt2, UNIT(10)(src), l_exc_copy) +EXC( LOADt3, UNIT(11)(src), l_exc_copy) +EXC( STORE t0, UNIT(8)(dst), s_exc_p8u) +EXC( STORE t1, UNIT(9)(dst), s_exc_p7u) +EXC( STORE t2, UNIT(10)(dst), s_exc_p6u) +EXC( STORE t3, UNIT(11)(dst), s_exc_p5u) +EXC( LOADt0, UNIT(12)(src), l_exc_copy) +EXC( LOADt1, UNIT(13)(src), l_exc_copy) +EXC( LOADt2, UNIT(14)(src), l_exc_copy) +EXC( LOADt3, UNIT(15)(src), l_exc_copy) ADD dst, dst, 16*NBYTES -EXC( LOADt0, UNIT(-8)(src), l_exc_copy) -EXC( LOADt1, UNIT(-7)(src), l_exc_copy) -EXC( LOADt2, UNIT(-6)(src), l_exc_copy) -EXC( LOADt3, UNIT(-5)(src), l_exc_copy) -EXC( STORE t0, UNIT(-8)(dst), s_exc_p8u) -EXC( STORE t1, UNIT(-7)(dst), s_exc_p7u) -EXC( STORE t2, UNIT(-6)(dst), s_exc_p6u) -EXC( STORE t3, UNIT(-5)(dst), s_exc_p5u) -EXC( LOADt0, UNIT(-4)(src), l_exc_copy) -EXC( LOADt1, UNIT(-3)(src), l_exc_copy) -EXC( LOADt2, UNIT(-2)(src), l_exc_copy) -EXC( LOADt3, UNIT(-1)(src), l_exc_copy) EXC( STORE t0, UNIT(-4)(dst), s_exc_p4u) + ADD src, src, 16*NBYTES EXC( STORE t1, UNIT(-3)(dst), s_exc_p3u) EXC( STORE t2, UNIT(-2)(dst), s_exc_p2u) EXC( STORE t3, UNIT(-1)(dst), s_exc_p1u) -- 2.7.4
Re: [PATCH net-next] virito-net: set queues after reset during xdp_set
On 2017年02月19日 13:08, Michael S. Tsirkin wrote:
- oxdp_qp = vi->xdp_queue_pairs;
-
/* Changing the headroom in buffers is a disruptive operation because
* existing buffers must be flushed and reallocated. This will happen
* when a xdp program is initially added or xdp is disabled by removing
* the xdp program resulting in number of XDP queues changing.
*/
if (vi->xdp_queue_pairs != xdp_qp) {
- vi->xdp_queue_pairs = xdp_qp;
err = virtnet_reset(vi);
- if (err)
+ if (err) {
+ dev_warn(&dev->dev, "XDP reset failure.\n");
goto virtio_reset_err;
+ }
+ vi->xdp_queue_pairs = xdp_qp;
But xdp_queue_pairs is being used to detect if we should allocate the XDP
headroom. If we move it here do we have a set of buffers in the ring without
the proper headroom when we assign the xdp program below?
Right, so how about passing xdp_queue_pairs as a parameter to
virtnet_reset(). Then virtnet_reset() can set it after _remove_vq_common()
but before virtnet_restore_up()?
Thanks
Jason, wouldn't you say it's cleaner to avoid resets?
Would you be interested in completing this work:
20170207053455-mutt-send-email-...@kernel.org
Yes, but this seems still need drop packets, is this acceptable?
Thanks
[GIT PULL] hwmon updates for v4.11
Hi Linus, Please pull hwmon updates for Linux v4.11 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v4.11 Thanks, Guenter -- The following changes since commit e9572fdd13e299cfba03abbfd2786c84ac055249: hwmon: (lm90) fix temp1_max_alarm attribute (2017-01-02 10:15:28 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/hwmon-for-linus-v4.11 for you to fetch changes up to 2f1736ff0664937636f8c0a4994c4a5a23da2090: hwmon: (sht15) Add device tree support (2017-02-16 06:49:05 -0800) hwmon updates for v4.11 - new driver for stts751 - it87: Added support for IT8622E and IT8792E; improved support for other chips - lm70: Added support for TMP122/124 - use permission-specific DEVICE_ATTR variants where possible - fixed overflows in various drivers - minor improvements in various drivers Alexander Koch (4): devicetree: hwmon: Add bindings for ADC128D818 hwmon: (adc128d818) Implement mode selection via dt hwmon: (adc128d818) Support operation modes 1-3 hwmon: (adc128d818) Preserve operation mode Christian Lamparter (1): devicetree: add lm90 thermal_zone sensor support Corentin LABBE (1): hwmon: (sch56xx) Remove unneeded linux/miscdevice.h include Florian Fainelli (2): hwmon: (lm70) Utilize dev_warn instead of pr_warn hwmon: (lm70) Add support for TI TMP122/124 Guenter Roeck (14): hwmon: (dme1737) Fix overflows seen when writing into limit attributes hwmon: (gl518sm) Fix overflows seen when writing into limit attributes hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes hwmon: Make name attribute mandatory for new APIs hwmon: Update documentation to clarify rules for the 'name' attribute hwmon: Relax name attribute validation for new APIs hwmon: Register thermal zone only if 'dev' parameter was provided hwmon: (it87) Add feature flag indicating that VIN3 is connected to 5V hwmon: (it87) Add support for IT8622E hwmon: (it87) Improve IT8622 support hwmon: (it87) Ensure that pwm control cache is current before updating values hwmon: (it87) Fix pwm4 detection for IT8620 and IT8628 hwmon: (it87) Do not overwrite bit 2..6 of pwm control registers hwmon: (it87) Add support for IT8792E Javier Martinez Canillas (1): hwmon: (ltc4151) Export OF device ID table as module aliases Jeroen De Wachter (1): hwmon: (tmp401) use smb word operations instead of 2 smb byte operations Julia Lawall (66): hwmon: (adm1021) use permission-specific DEVICE_ATTR variants hwmon: (adm1026) use permission-specific DEVICE_ATTR variants hwmon: (adm1031) use permission-specific DEVICE_ATTR variants hwmon: (adm9240) use permission-specific DEVICE_ATTR variants hwmon: (adt7470) use permission-specific DEVICE_ATTR variants hwmon: (adt7x10) use permission-specific DEVICE_ATTR variants hwmon: (asb100) use permission-specific DEVICE_ATTR variants hwmon: (atxp1) use permission-specific DEVICE_ATTR variants hwmon: (ds1621) use permission-specific DEVICE_ATTR variants hwmon: (f71882fg) use permission-specific DEVICE_ATTR variants hwmon: (fschmd) use permission-specific DEVICE_ATTR variants hwmon: (g760a) use permission-specific DEVICE_ATTR variants hwmon: (g762) use permission-specific DEVICE_ATTR variants hwmon: (gl520sm) use permission-specific DEVICE_ATTR variants hwmon: (gpio-fan) use permission-specific DEVICE_ATTR variants hwmon: (core) use permission-specific DEVICE_ATTR variants hwmon: (i5500_temp) use permission-specific DEVICE_ATTR variants hwmon: (i5k_amb) use permission-specific DEVICE_ATTR variants hwmon: (jz4740) use permission-specific DEVICE_ATTR variants hwmon: (lm63) use permission-specific DEVICE_ATTR variants hwmon: (lm70) use permission-specific DEVICE_ATTR variants hwmon: (lm80) use permission-specific DEVICE_ATTR variants hwmon: (lm85) use permission-specific DEVICE_ATTR variants hwmon: (lm87) use permission-specific DEVICE_ATTR variants hwmon: (lm92) use permission-specific DEVICE_ATTR variants hwmon: (lm93) use permission-specific DEVICE_ATTR variants hwmon: (max) use permission-specific DEVICE_ATTR variants hwmon: (max1619) use permission-specific DEVICE_ATTR variants hwmon: (max197) use permission-specific DEVICE_ATTR variants hwmon: (mc13783-adc) use permission-specific DEVICE_ATTR variants hwmon: (mcp3021) use permission-specific DEVICE_ATTR variants hwmon: (nct6683) use permission-specific DEVICE_ATTR variants hwmon: (nsa320) use permission-specific DEVICE_ATTR variants hwm
Re: [PATCH] mm/thp/autonuma: Use TNF flag instead of vm fault.
On February 19, 2017 6:00 PM Aneesh Kumar K.V wrote:
>
> We are using wrong flag value in task_numa_falt function. This can result in
> us doing wrong numa fault statistics update, because we update
> num_pages_migrate
> and numa_fault_locality etc based on the flag argument passed.
>
> Signed-off-by: Aneesh Kumar K.V
Fix: bae473a423 ("mm: introduce fault_env")
Acked-by: Hillf Danton
> ---
> mm/huge_memory.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 5f3ad65c85de..8f1d93257fb9 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1333,7 +1333,7 @@ int do_huge_pmd_numa_page(struct vm_fault *vmf, pmd_t
> pmd)
>
> if (page_nid != -1)
> task_numa_fault(last_cpupid, page_nid, HPAGE_PMD_NR,
> - vmf->flags);
> + flags);
>
> return 0;
> }
> --
> 2.7.4
Re: [PATCH v2] MAINTAINERS: cpufreq: add bmips-cpufreq.c
On 17-02-17, 12:27, Markus Mayer wrote: > From: Markus Mayer > > Add maintainer information for bmips-cpufreq.c. > > Signed-off-by: Markus Mayer > Acked-by: Florian Fainelli > --- > > This is based on PM's linux-next from today (February 17). > > This patch could be squashed into patch 3/4 of the original series if that > is acceptable (see [1]) or it can remain separate. > > [1] https://lkml.org/lkml/2017/2/7/775 > > Changes in v2: > - added bcm-kernel-feedback-l...@broadcom.com > > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 107c10e..d4ac248 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2692,6 +2692,13 @@ F: drivers/irqchip/irq-brcmstb* > F: include/linux/bcm963xx_nvram.h > F: include/linux/bcm963xx_tag.h > > +BROADCOM BMIPS CPUFREQ DRIVER > +M: Markus Mayer > +M: bcm-kernel-feedback-l...@broadcom.com Isn't this a list as well? Shouldn't this be L: ? > +L: linux...@vger.kernel.org > +S: Maintained > +F: drivers/cpufreq/bmips-cpufreq.c > + > BROADCOM TG3 GIGABIT ETHERNET DRIVER > M: Siva Reddy Kallam > M: Prashant Sreedharan -- viresh
[PATCH v4 05/10] powerpc/perf: Generic imc pmu event functions
Since, the IMC counters' data are periodically fed to a memory location,
the functions to read/update, start/stop, add/del can be generic and can
be used by all IMC PMU units.
This patch adds a set of generic imc pmu related event functions to be
used by each imc pmu unit. Add code to setup format attribute and to
register imc pmus. Add a event_init function for nest_imc events.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Cc: Anju T Sudhakar
Signed-off-by: Hemant Kumar
---
arch/powerpc/include/asm/imc-pmu.h| 1 +
arch/powerpc/perf/imc-pmu.c | 121 ++
arch/powerpc/platforms/powernv/opal-imc.c | 30 +++-
3 files changed, 148 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/imc-pmu.h
b/arch/powerpc/include/asm/imc-pmu.h
index 3232322..7b58721 100644
--- a/arch/powerpc/include/asm/imc-pmu.h
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -70,4 +70,5 @@ struct imc_pmu {
#define UNKNOWN_DOMAIN -1
+int imc_get_domain(struct device_node *pmu_dev);
#endif /* PPC_POWERNV_IMC_PMU_DEF_H */
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 7b6ce50..f6f1ef9 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -17,6 +17,116 @@
struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+/* Needed for sanity check */
+extern u64 nest_max_offset;
+
+PMU_FORMAT_ATTR(event, "config:0-20");
+static struct attribute *imc_format_attrs[] = {
+ &format_attr_event.attr,
+ NULL,
+};
+
+static struct attribute_group imc_format_group = {
+ .name = "format",
+ .attrs = imc_format_attrs,
+};
+
+static int nest_imc_event_init(struct perf_event *event)
+{
+ int chip_id;
+ u32 config = event->attr.config;
+ struct perchip_nest_info *pcni;
+
+ if (event->attr.type != event->pmu->type)
+ return -ENOENT;
+
+ /* Sampling not supported */
+ if (event->hw.sample_period)
+ return -EINVAL;
+
+ /* unsupported modes and filters */
+ if (event->attr.exclude_user ||
+ event->attr.exclude_kernel ||
+ event->attr.exclude_hv ||
+ event->attr.exclude_idle ||
+ event->attr.exclude_host ||
+ event->attr.exclude_guest)
+ return -EINVAL;
+
+ if (event->cpu < 0)
+ return -EINVAL;
+
+ /* Sanity check for config (event offset) */
+ if (config > nest_max_offset)
+ return -EINVAL;
+
+ chip_id = topology_physical_package_id(event->cpu);
+ pcni = &nest_perchip_info[chip_id];
+ event->hw.event_base = pcni->vbase[config/PAGE_SIZE] +
+ (config & ~PAGE_MASK);
+
+ return 0;
+}
+
+static void imc_read_counter(struct perf_event *event)
+{
+ u64 *addr, data;
+
+ addr = (u64 *)event->hw.event_base;
+ data = __be64_to_cpu(*addr);
+ local64_set(&event->hw.prev_count, data);
+}
+
+static void imc_perf_event_update(struct perf_event *event)
+{
+ u64 counter_prev, counter_new, final_count, *addr;
+
+ addr = (u64 *)event->hw.event_base;
+ counter_prev = local64_read(&event->hw.prev_count);
+ counter_new = __be64_to_cpu(*addr);
+ final_count = counter_new - counter_prev;
+
+ local64_set(&event->hw.prev_count, counter_new);
+ local64_add(final_count, &event->count);
+}
+
+static void imc_event_start(struct perf_event *event, int flags)
+{
+ imc_read_counter(event);
+}
+
+static void imc_event_stop(struct perf_event *event, int flags)
+{
+ imc_perf_event_update(event);
+}
+
+static int imc_event_add(struct perf_event *event, int flags)
+{
+ if (flags & PERF_EF_START)
+ imc_event_start(event, flags);
+
+ return 0;
+}
+
+/* update_pmu_ops : Populate the appropriate operations for "pmu" */
+static int update_pmu_ops(struct imc_pmu *pmu)
+{
+ if (!pmu)
+ return -EINVAL;
+
+ pmu->pmu.task_ctx_nr = perf_invalid_context;
+ pmu->pmu.event_init = nest_imc_event_init;
+ pmu->pmu.add = imc_event_add;
+ pmu->pmu.del = imc_event_stop;
+ pmu->pmu.start = imc_event_start;
+ pmu->pmu.stop = imc_event_stop;
+ pmu->pmu.read = imc_perf_event_update;
+ pmu->attr_groups[1] = &imc_format_group;
+ pmu->pmu.attr_groups = pmu->attr_groups;
+
+ return 0;
+}
+
/* dev_str_attr : Populate event "name" and string "str" in attribute */
static struct attribute *dev_str_attr(const char *name, const char *str)
{
@@ -83,6 +193,17 @@ int init_imc_pmu(struct imc_events *events, int idx,
if (ret)
goto err_free;
+ ret = update_p
[PATCH v4 04/10] powerpc/perf: Add event attribute and group to IMC pmus
Device tree IMC driver code parses the IMC units and their events. It
passes the information to IMC pmu code which is placed in powerpc/perf
as "imc-pmu.c".
This patch creates only event attributes and attribute groups for the
IMC pmus.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Cc: Anju T Sudhakar
Signed-off-by: Hemant Kumar
---
arch/powerpc/perf/Makefile| 6 +-
arch/powerpc/perf/imc-pmu.c | 96 +++
arch/powerpc/platforms/powernv/opal-imc.c | 12 +++-
3 files changed, 111 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/perf/imc-pmu.c
diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index 4d606b9..d0d1f04 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -2,10 +2,14 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
obj-$(CONFIG_PERF_EVENTS) += callchain.o perf_regs.o
+imc-$(CONFIG_PPC_POWERNV) += imc-pmu.o
+
obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o bhrb.o
obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \
power5+-pmu.o power6-pmu.o power7-pmu.o \
- isa207-common.o power8-pmu.o power9-pmu.o
+ isa207-common.o power8-pmu.o power9-pmu.o \
+ $(imc-y)
+
obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
new file mode 100644
index 000..7b6ce50
--- /dev/null
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -0,0 +1,96 @@
+/*
+ * Nest Performance Monitor counter support.
+ *
+ * Copyright (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ * (C) 2016 Hemant K Shaw, IBM Corporation.
+ * 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
+
+struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
+struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+
+/* dev_str_attr : Populate event "name" and string "str" in attribute */
+static struct attribute *dev_str_attr(const char *name, const char *str)
+{
+ struct perf_pmu_events_attr *attr;
+
+ attr = kzalloc(sizeof(*attr), GFP_KERNEL);
+
+ sysfs_attr_init(&attr->attr.attr);
+
+ attr->event_str = str;
+ attr->attr.attr.name = name;
+ attr->attr.attr.mode = 0444;
+ attr->attr.show = perf_event_sysfs_show;
+
+ return &attr->attr.attr;
+}
+
+/*
+ * update_events_in_group: Update the "events" information in an attr_group
+ * and assign the attr_group to the pmu "pmu".
+ */
+static int update_events_in_group(struct imc_events *events,
+ int idx, struct imc_pmu *pmu)
+{
+ struct attribute_group *attr_group;
+ struct attribute **attrs;
+ int i;
+
+ /* Allocate memory for attribute group */
+ attr_group = kzalloc(sizeof(*attr_group), GFP_KERNEL);
+ if (!attr_group)
+ return -ENOMEM;
+
+ /* Allocate memory for attributes */
+ attrs = kzalloc((sizeof(struct attribute *) * (idx + 1)), GFP_KERNEL);
+ if (!attrs) {
+ kfree(attr_group);
+ return -ENOMEM;
+ }
+
+ attr_group->name = "events";
+ attr_group->attrs = attrs;
+ for (i = 0; i < idx; i++, events++) {
+ attrs[i] = dev_str_attr((char *)events->ev_name,
+ (char *)events->ev_value);
+ }
+
+ pmu->attr_groups[0] = attr_group;
+ return 0;
+}
+
+/*
+ * init_imc_pmu : Setup the IMC pmu device in "pmu_ptr" and its events
+ *"events".
+ * Setup the cpu mask information for these pmus and setup the state machine
+ * hotplug notifiers as well.
+ */
+int init_imc_pmu(struct imc_events *events, int idx,
+struct imc_pmu *pmu_ptr)
+{
+ int ret = -ENODEV;
+
+ ret = update_events_in_group(events, idx, pmu_ptr);
+ if (ret)
+ goto err_free;
+
+ return 0;
+
+err_free:
+ /* Only free the attr_groups which are dynamically allocated */
+ if (pmu_ptr->attr_groups[0]) {
+ kfree(pmu_ptr->attr_groups[0]->attrs);
+ kfree(pmu_ptr->attr_groups[0]);
+ }
+
+ return ret;
+}
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
index c58b893..ed1e091 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -31,8 +31,11 @@
#include
#include
-s
[PATCH v4 06/10] powerpc/perf: IMC pmu cpumask and cpu hotplug support
Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any
online CPU) from each chip for nest PMUs is designated to read counters.
On CPU hotplug, dying CPU is checked to see whether it is one of the
designated cpus, if yes, next online cpu from the same chip (for nest
units) is designated as new cpu to read counters. For this purpose, we
introduce a new state : CPUHP_AP_PERF_POWERPC_NEST_ONLINE.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Cc: Anju T Sudhakar
Signed-off-by: Hemant Kumar
---
arch/powerpc/include/asm/opal-api.h| 3 +-
arch/powerpc/include/asm/opal.h| 3 +
arch/powerpc/perf/imc-pmu.c| 163 -
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
include/linux/cpuhotplug.h | 1 +
5 files changed, 169 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index a0aa285..e15fb20 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -168,7 +168,8 @@
#define OPAL_INT_SET_MFRR 125
#define OPAL_PCI_TCE_KILL 126
#define OPAL_NMMU_SET_PTCR 127
-#define OPAL_LAST 127
+#define OPAL_NEST_IMC_COUNTERS_CONTROL 128
+#define OPAL_LAST 128
/* Device tree flags */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 1ff03a6..d93d082 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -227,6 +227,9 @@ int64_t opal_pci_tce_kill(uint64_t phb_id, uint32_t
kill_type,
uint64_t dma_addr, uint32_t npages);
int64_t opal_nmmu_set_ptcr(uint64_t chip_id, uint64_t ptcr);
+int64_t opal_nest_imc_counters_control(uint64_t mode, uint64_t value1,
+ uint64_t value2, uint64_t value3);
+
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
int depth, void *data);
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index f6f1ef9..e46ff6d 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -16,6 +16,7 @@
struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+static cpumask_t nest_imc_cpumask;
/* Needed for sanity check */
extern u64 nest_max_offset;
@@ -31,6 +32,160 @@ static struct attribute_group imc_format_group = {
.attrs = imc_format_attrs,
};
+/* Get the cpumask printed to a buffer "buf" */
+static ssize_t imc_pmu_cpumask_get_attr(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ cpumask_t *active_mask;
+
+ active_mask = &nest_imc_cpumask;
+ return cpumap_print_to_pagebuf(true, buf, active_mask);
+}
+
+static DEVICE_ATTR(cpumask, S_IRUGO, imc_pmu_cpumask_get_attr, NULL);
+
+static struct attribute *imc_pmu_cpumask_attrs[] = {
+ &dev_attr_cpumask.attr,
+ NULL,
+};
+
+static struct attribute_group imc_pmu_cpumask_attr_group = {
+ .attrs = imc_pmu_cpumask_attrs,
+};
+
+/*
+ * nest_init : Initializes the nest imc engine for the current chip.
+ */
+static void nest_init(int *loc)
+{
+ int rc;
+
+ rc = opal_nest_imc_counters_control(NEST_IMC_PRODUCTION_MODE,
+ NEST_IMC_ENGINE_START, 0, 0);
+ if (rc)
+ loc[smp_processor_id()] = 1;
+}
+
+static void nest_change_cpu_context(int old_cpu, int new_cpu)
+{
+ int i;
+
+ for (i = 0;
+(per_nest_pmu_arr[i] != NULL) && (i < IMC_MAX_PMUS); i++)
+ perf_pmu_migrate_context(&per_nest_pmu_arr[i]->pmu,
+ old_cpu, new_cpu);
+}
+
+static int ppc_nest_imc_cpu_online(unsigned int cpu)
+{
+ int nid, fcpu, ncpu;
+ struct cpumask *l_cpumask, tmp_mask;
+
+ /* Fint the cpumask of this node */
+ nid = cpu_to_node(cpu);
+ l_cpumask = cpumask_of_node(nid);
+
+ /*
+* If any of the cpu from this node is already present in the mask,
+* just return, if not, then set this cpu in the mask.
+*/
+ if (!cpumask_and(&tmp_mask, l_cpumask, &nest_imc_cpumask)) {
+ cpumask_set_cpu(cpu, &nest_imc_cpumask);
+ return 0;
+ }
+
+ fcpu = cpumask_first(l_cpumask);
+ ncpu = cpumask_next(cpu, l_cpumask);
+ if (cpu == fcpu) {
+ if (cpumask_test_and_clear_cpu(ncpu, &nest_imc_cpumask)) {
+ cpumask_set_cpu(cpu, &nest_imc_cpumask);
+ nest_change_cpu_context(ncp
[PATCH v4 07/10] powerpc/powernv: Core IMC events detection
This patch adds support for detection of core IMC events along with the
Nest IMC events. It adds a new domain IMC_DOMAIN_CORE and its determined
with the help of the compatibility string "ibm,imc-counters-core" based
on the IMC device tree.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Cc: Anju T Sudhakar
Signed-off-by: Hemant Kumar
---
arch/powerpc/include/asm/imc-pmu.h| 2 ++
arch/powerpc/perf/imc-pmu.c | 3 +++
arch/powerpc/platforms/powernv/opal-imc.c | 18 --
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/imc-pmu.h
b/arch/powerpc/include/asm/imc-pmu.h
index 7b58721..59de083 100644
--- a/arch/powerpc/include/asm/imc-pmu.h
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -30,6 +30,7 @@
#define IMC_DTB_COMPAT "ibm,opal-in-memory-counters"
#define IMC_DTB_NEST_COMPAT"ibm,imc-counters-nest"
+#define IMC_DTB_CORE_COMPAT"ibm,imc-counters-core"
/*
* Structure to hold per chip specific memory address
@@ -67,6 +68,7 @@ struct imc_pmu {
* Domains for IMC PMUs
*/
#define IMC_DOMAIN_NEST1
+#define IMC_DOMAIN_CORE2
#define UNKNOWN_DOMAIN -1
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index e46ff6d..9a0e3bc 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -18,8 +18,11 @@ struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
static cpumask_t nest_imc_cpumask;
+struct imc_pmu *core_imc_pmu;
+
/* Needed for sanity check */
extern u64 nest_max_offset;
+extern u64 core_max_offset;
PMU_FORMAT_ATTR(event, "config:0-20");
static struct attribute *imc_format_attrs[] = {
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
index a65aa2d..67ce873 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -33,10 +33,12 @@
extern struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
extern struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+extern struct imc_pmu *core_imc_pmu;
extern int init_imc_pmu(struct imc_events *events,
int idx, struct imc_pmu *pmu_ptr);
u64 nest_max_offset;
+u64 core_max_offset;
static int imc_event_info(char *name, struct imc_events *events)
{
@@ -80,6 +82,10 @@ static void update_max_value(u32 value, int pmu_domain)
if (nest_max_offset < value)
nest_max_offset = value;
break;
+ case IMC_DOMAIN_CORE:
+ if (core_max_offset < value)
+ core_max_offset = value;
+ break;
default:
/* Unknown domain, return */
return;
@@ -231,6 +237,8 @@ int imc_get_domain(struct device_node *pmu_dev)
{
if (of_device_is_compatible(pmu_dev, IMC_DTB_NEST_COMPAT))
return IMC_DOMAIN_NEST;
+ if (of_device_is_compatible(pmu_dev, IMC_DTB_CORE_COMPAT))
+ return IMC_DOMAIN_CORE;
else
return UNKNOWN_DOMAIN;
}
@@ -298,7 +306,10 @@ static int imc_pmu_create(struct device_node *parent, int
pmu_index)
goto free_pmu;
/* Needed for hotplug/migration */
- per_nest_pmu_arr[pmu_index] = pmu_ptr;
+ if (pmu_ptr->domain == IMC_DOMAIN_CORE)
+ core_imc_pmu = pmu_ptr;
+ else if (pmu_ptr->domain == IMC_DOMAIN_NEST)
+ per_nest_pmu_arr[pmu_index] = pmu_ptr;
/*
* "events" property inside a PMU node contains the phandle value
@@ -354,7 +365,10 @@ static int imc_pmu_create(struct device_node *parent, int
pmu_index)
}
/* Save the name to register it later */
- sprintf(buf, "nest_%s", (char *)pp->value);
+ if (pmu_ptr->domain == IMC_DOMAIN_NEST)
+ sprintf(buf, "nest_%s", (char *)pp->value);
+ else
+ sprintf(buf, "%s_imc", (char *)pp->value);
pmu_ptr->pmu.name = (char *)buf;
/*
--
2.7.4
[PATCH v4 01/10] powerpc/powernv: Data structure and macros definitions
Create new header file "imc-pmu.h" to add the data structures
and macros needed for IMC pmu support.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Cc: Anju T Sudhakar
Signed-off-by: Hemant Kumar
---
arch/powerpc/include/asm/imc-pmu.h | 73 ++
1 file changed, 73 insertions(+)
create mode 100644 arch/powerpc/include/asm/imc-pmu.h
diff --git a/arch/powerpc/include/asm/imc-pmu.h
b/arch/powerpc/include/asm/imc-pmu.h
new file mode 100644
index 000..3232322
--- /dev/null
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -0,0 +1,73 @@
+#ifndef PPC_POWERNV_IMC_PMU_DEF_H
+#define PPC_POWERNV_IMC_PMU_DEF_H
+
+/*
+ * IMC Nest Performance Monitor counter support.
+ *
+ * Copyright (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ * (C) 2016 Hemant K Shaw, IBM Corporation.
+ *
+ * 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
+
+#define IMC_MAX_CHIPS 32
+#define IMC_MAX_PMUS 32
+#define IMC_MAX_PMU_NAME_LEN 256
+
+#define NEST_IMC_ENGINE_START 1
+#define NEST_IMC_ENGINE_STOP 0
+#define NEST_MAX_PAGES 16
+
+#define NEST_IMC_PRODUCTION_MODE 1
+
+#define IMC_DTB_COMPAT "ibm,opal-in-memory-counters"
+#define IMC_DTB_NEST_COMPAT"ibm,imc-counters-nest"
+
+/*
+ * Structure to hold per chip specific memory address
+ * information for nest pmus. Nest Counter data are exported
+ * in per-chip reserved memory region by the PORE Engine.
+ */
+struct perchip_nest_info {
+ u32 chip_id;
+ u64 pbase;
+ u64 vbase[NEST_MAX_PAGES];
+ u64 size;
+};
+
+/*
+ * Place holder for nest pmu events and values.
+ */
+struct imc_events {
+ char *ev_name;
+ char *ev_value;
+};
+
+/*
+ * Device tree parser code detects IMC pmu support and
+ * registers new IMC pmus. This structure will
+ * hold the pmu functions and attrs for each imc pmu and
+ * will be referenced at the time of pmu registration.
+ */
+struct imc_pmu {
+ struct pmu pmu;
+ int domain;
+ const struct attribute_group *attr_groups[4];
+};
+
+/*
+ * Domains for IMC PMUs
+ */
+#define IMC_DOMAIN_NEST1
+
+#define UNKNOWN_DOMAIN -1
+
+#endif /* PPC_POWERNV_IMC_PMU_DEF_H */
--
2.7.4
[PATCH v4 02/10] powerpc/powernv: Autoload IMC device driver module
This patch does three things :
- Enables "opal.c" to create a platform device for the IMC interface
according to the appropriate compatibility string.
- Find the reserved-memory region details from the system device tree
and get the base address of HOMER region address for each chip.
- We also get the Nest PMU counter data offsets (in the HOMER region)
and their sizes. The offsets for the counters' data are fixed and
won't change from chip to chip.
The device tree parsing logic is separated from the PMU creation
functions (which is done in subsequent patches). Right now, only Nest
units are taken care of.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Cc: Anju T Sudhakar
Signed-off-by: Hemant Kumar
---
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/opal-imc.c | 117 ++
arch/powerpc/platforms/powernv/opal.c | 13
3 files changed, 131 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/powernv/opal-imc.c
diff --git a/arch/powerpc/platforms/powernv/Makefile
b/arch/powerpc/platforms/powernv/Makefile
index b5d98cb..44909fe 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y += setup.o opal-wrappers.o opal.o
opal-async.o idle.o
obj-y += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o
opal-sensor.o
obj-y += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y += opal-kmsg.o
+obj-y += opal-kmsg.o opal-imc.o
obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
new file mode 100644
index 000..ee2ae45
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -0,0 +1,117 @@
+/*
+ * OPAL IMC interface detection driver
+ * Supported on POWERNV platform
+ *
+ * Copyright (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ *(C) 2016 Hemant K Shaw, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
+
+static int opal_imc_counters_probe(struct platform_device *pdev)
+{
+ struct device_node *child, *imc_dev, *rm_node = NULL;
+ struct perchip_nest_info *pcni;
+ u32 reg[4], pages, nest_offset, nest_size, idx;
+ int i = 0;
+ const char *node_name;
+
+ if (!pdev || !pdev->dev.of_node)
+ return -ENODEV;
+
+ imc_dev = pdev->dev.of_node;
+
+ /*
+* nest_offset : where the nest-counters' data start.
+* size : size of the entire nest-counters region
+*/
+ if (of_property_read_u32(imc_dev, "imc-nest-offset", &nest_offset))
+ goto err;
+ if (of_property_read_u32(imc_dev, "imc-nest-size", &nest_size))
+ goto err;
+
+ /* Find the "homer region" for each chip */
+ rm_node = of_find_node_by_path("/reserved-memory");
+ if (!rm_node)
+ goto err;
+
+ for_each_child_of_node(rm_node, child) {
+ if (of_property_read_string_index(child, "name", 0,
+ &node_name))
+ continue;
+ if (strncmp("ibm,homer-image", node_name,
+ strlen("ibm,homer-image")))
+ continue;
+
+ /* Get the chip id to which the above homer region belongs to */
+ if (of_property_read_u32(child, "ibm,chip-id", &idx))
+ goto err;
+
+ /* reg property will have four u32 cells. */
+ if (of_property_read_u32_array(child, "reg", reg, 4))
+ goto err;
+
+ pcni = &nest_perchip_info[idx];
+
+ /* Fetch the homer region base address */
+ pcni->pbase = reg[0];
+ pcni->pbase = pcni->pbase << 32 | reg[1];
+ /* Add the nest IMC Base offset */
+ pcni->pbase
[PATCH v4 03/10] powerpc/powernv: Detect supported IMC units and its events
Parse device tree to detect IMC units. Traverse through each IMC unit
node to find supported events and corresponding unit/scale files (if any).
The device tree for IMC counters starts at the node :
"imc-counters". This node contains all the IMC PMU nodes and event nodes
for these IMC PMUs. The PMU nodes have an "events" property which has a
phandle value for the actual events node. The events are separated from
the PMU nodes to abstract out the common events. For example, PMU node
"mcs0", "mcs1" etc. will contain a pointer to "nest-mcs-events" since,
the events are common between these PMUs. These events have a different
prefix based on their relation to different PMUs, and hence, the PMU
nodes themselves contain an "events-prefix" property. The value for this
property concatenated to the event name, forms the actual event
name. Also, the PMU have a "reg" field as the base offset for the events
which belong to this PMU. This "reg" field is added to an event in the
"events" node, which gives us the location of the counter data. Kernel
code uses this offset as event configuration value.
Device tree parser code also looks for scale/unit property in the event
node and passes on the value as an event attr for perf interface to use
in the post processing by the perf tool. Some PMUs may have common scale
and unit properties which implies that all events supported by this PMU
inherit the scale and unit properties of the PMU itself. For those
events, we need to set the common unit and scale values.
For failure to initialize any unit or any event, disable that unit and
continue setting up the rest of them.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Signed-off-by: Hemant Kumar
Signed-off-by: Anju T Sudhakar
---
arch/powerpc/platforms/powernv/opal-imc.c | 385 ++
1 file changed, 385 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
index ee2ae45..c58b893 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -32,6 +32,390 @@
#include
struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
+struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
+
+static int imc_event_info(char *name, struct imc_events *events)
+{
+ char *buf;
+
+ /* memory for content */
+ buf = kzalloc(IMC_MAX_PMU_NAME_LEN, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ events->ev_name = name;
+ events->ev_value = buf;
+ return 0;
+}
+
+static int imc_event_info_str(struct property *pp, char *name,
+ struct imc_events *events)
+{
+ int ret;
+
+ ret = imc_event_info(name, events);
+ if (ret)
+ return ret;
+
+ if (!pp->value || (strnlen(pp->value, pp->length) == pp->length) ||
+ (pp->length > IMC_MAX_PMU_NAME_LEN))
+ return -EINVAL;
+ strncpy(events->ev_value, (const char *)pp->value, pp->length);
+
+ return 0;
+}
+
+static int imc_event_info_val(char *name, u32 val,
+ struct imc_events *events)
+{
+ int ret;
+
+ ret = imc_event_info(name, events);
+ if (ret)
+ return ret;
+ sprintf(events->ev_value, "event=0x%x", val);
+
+ return 0;
+}
+
+static int set_event_property(struct property *pp, char *event_prop,
+ struct imc_events *events, char *ev_name)
+{
+ char *buf;
+ int ret;
+
+ buf = kzalloc(IMC_MAX_PMU_NAME_LEN, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ sprintf(buf, "%s.%s", ev_name, event_prop);
+ ret = imc_event_info_str(pp, buf, events);
+ if (ret) {
+ kfree(events->ev_name);
+ kfree(events->ev_value);
+ }
+
+ return ret;
+}
+
+/*
+ * imc_events_node_parser: Parse the event node "dev" and assign the parsed
+ * information to event "events".
+ *
+ * Parses the "reg" property of this event. "reg" gives us the event offset.
+ * Also, parse the "scale" and "unit" properties, if any.
+ */
+static int imc_events_node_parser(struct device_node *dev,
+ struct imc_events *events,
+ struct property *event_scale,
+ struct property *event_unit,
+ struct property *name_prefix,
+ u32 reg)
+{
+ struct property *name, *pp;
+ char *ev_name;
+ u32 val;
+ int idx = 0, ret;
+
+ if (!dev)
+ return -EINVAL;
+
+ /*
+* Loop through each property of an event node
+*/
+ name = of_find_property(dev, "event-name", NULL);
+
[PATCH v4 10/10] powerpc/perf: Thread IMC PMU functions
This patch adds the PMU functions required for event initialization,
read, update, add, del etc. for thread IMC PMU. Thread IMC PMUs are used
for per-task monitoring. These PMUs don't need any hotplugging support.
For each CPU, a page of memory is allocated and is kept static i.e.,
these pages will exist till the machine shuts down. The base address of
this page is assigned to the ldbar of that cpu. As soon as we do that,
the thread IMC counters start running for that cpu and the data of these
counters are assigned to the page allocated. But we use this for
per-task monitoring. Whenever we start monitoring a task, the event is
added is onto the task. At that point, we read the initial value of the
event. Whenever, we stop monitoring the task, the final value is taken
and the difference is the event data.
Now, a task can move to a different cpu. Suppose a task X is moving from
cpu A to cpu B. When the task is scheduled out of A, we get an
event_del for A, and hence, the event data is updated. And, we stop
updating the X's event data. As soon as X moves on to B, event_add is
called for B, and we again update the event_data. And this is how it
keeps on updating the event data even when the task is scheduled on to
different cpus.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Cc: Anju T Sudhakar
Signed-off-by: Hemant Kumar
---
arch/powerpc/include/asm/imc-pmu.h | 4 +
arch/powerpc/perf/imc-pmu.c| 161 -
2 files changed, 164 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/imc-pmu.h
b/arch/powerpc/include/asm/imc-pmu.h
index f2b4f12..8b7141b 100644
--- a/arch/powerpc/include/asm/imc-pmu.h
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -22,6 +22,7 @@
#define IMC_MAX_PMUS 32
#define IMC_MAX_PMU_NAME_LEN 256
#define IMC_MAX_CORES 256
+#define IMC_MAX_CPUS2048
#define NEST_IMC_ENGINE_START 1
#define NEST_IMC_ENGINE_STOP 0
@@ -34,6 +35,9 @@
#define IMC_DTB_CORE_COMPAT"ibm,imc-counters-core"
#define IMC_DTB_THREAD_COMPAT "ibm,imc-counters-thread"
+#define THREAD_IMC_LDBAR_MASK 0x0003e000
+#define THREAD_IMC_ENABLE 0x8000
+
/*
* Structure to hold per chip specific memory address
* information for nest pmus. Nest Counter data are exported
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index a48c5be..4033b2d 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -23,6 +23,9 @@ static u64 per_core_pdbar_add[IMC_MAX_CHIPS][IMC_MAX_CORES];
static cpumask_t core_imc_cpumask;
struct imc_pmu *core_imc_pmu;
+/* Maintains base address for all the cpus */
+static u64 per_cpu_add[IMC_MAX_CPUS];
+
/* Needed for sanity check */
extern u64 nest_max_offset;
extern u64 core_max_offset;
@@ -443,6 +446,56 @@ static int core_imc_event_init(struct perf_event *event)
return 0;
}
+static int thread_imc_event_init(struct perf_event *event)
+{
+ struct task_struct *target;
+
+ if (event->attr.type != event->pmu->type)
+ return -ENOENT;
+
+ /* Sampling not supported */
+ if (event->hw.sample_period)
+ return -EINVAL;
+
+ event->hw.idx = -1;
+
+ /* Sanity check for config (event offset) */
+ if (event->attr.config > thread_max_offset)
+ return -EINVAL;
+
+ target = event->hw.target;
+
+ if (!target)
+ return -EINVAL;
+
+ event->pmu->task_ctx_nr = perf_sw_context;
+ return 0;
+}
+
+static void thread_imc_read_counter(struct perf_event *event)
+{
+ u64 *addr, data;
+ int cpu_id = smp_processor_id();
+
+ addr = (u64 *)(per_cpu_add[cpu_id] + event->attr.config);
+ data = __be64_to_cpu(*addr);
+ local64_set(&event->hw.prev_count, data);
+}
+
+static void thread_imc_perf_event_update(struct perf_event *event)
+{
+ u64 counter_prev, counter_new, final_count, *addr;
+ int cpu_id = smp_processor_id();
+
+ addr = (u64 *)(per_cpu_add[cpu_id] + event->attr.config);
+ counter_prev = local64_read(&event->hw.prev_count);
+ counter_new = __be64_to_cpu(*addr);
+ final_count = counter_new - counter_prev;
+
+ local64_set(&event->hw.prev_count, counter_new);
+ local64_add(final_count, &event->count);
+}
+
static void imc_read_counter(struct perf_event *event)
{
u64 *addr, data;
@@ -483,6 +536,53 @@ static int imc_event_add(struct perf_event *event, int
flags)
return 0;
}
+static void thread_imc_event_start(struct perf_event *event, int flags)
+{
+ thread_imc_read_counter(event);
+}
+
+static void thread_imc_event_stop(struct perf_event *event, int flags)
+{
+ thread_
[PATCH v4 09/10] powerpc/powernv: Thread IMC events detection
Patch adds support for detection of thread IMC events. It adds a new
domain IMC_DOMAIN_THREAD and it is determined with the help of the
compatibility string "ibm,imc-counters-thread" based on the IMC device
tree.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Cc: Anju T Sudhakar
Signed-off-by: Hemant Kumar
---
arch/powerpc/include/asm/imc-pmu.h| 2 ++
arch/powerpc/perf/imc-pmu.c | 1 +
arch/powerpc/platforms/powernv/opal-imc.c | 11 +--
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/imc-pmu.h
b/arch/powerpc/include/asm/imc-pmu.h
index 5e76cd0..f2b4f12 100644
--- a/arch/powerpc/include/asm/imc-pmu.h
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -32,6 +32,7 @@
#define IMC_DTB_COMPAT "ibm,opal-in-memory-counters"
#define IMC_DTB_NEST_COMPAT"ibm,imc-counters-nest"
#define IMC_DTB_CORE_COMPAT"ibm,imc-counters-core"
+#define IMC_DTB_THREAD_COMPAT "ibm,imc-counters-thread"
/*
* Structure to hold per chip specific memory address
@@ -70,6 +71,7 @@ struct imc_pmu {
*/
#define IMC_DOMAIN_NEST1
#define IMC_DOMAIN_CORE2
+#define IMC_DOMAIN_THREAD 3
#define UNKNOWN_DOMAIN -1
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 61d99c7..a48c5be 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -26,6 +26,7 @@ struct imc_pmu *core_imc_pmu;
/* Needed for sanity check */
extern u64 nest_max_offset;
extern u64 core_max_offset;
+extern u64 thread_max_offset;
PMU_FORMAT_ATTR(event, "config:0-20");
static struct attribute *imc_format_attrs[] = {
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
index 6db3c5f..a5565e7 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -39,6 +39,7 @@ extern int init_imc_pmu(struct imc_events *events,
int idx, struct imc_pmu *pmu_ptr);
u64 nest_max_offset;
u64 core_max_offset;
+u64 thread_max_offset;
static int imc_event_info(char *name, struct imc_events *events)
{
@@ -86,6 +87,10 @@ static void update_max_value(u32 value, int pmu_domain)
if (core_max_offset < value)
core_max_offset = value;
break;
+ case IMC_DOMAIN_THREAD:
+ if (thread_max_offset < value)
+ thread_max_offset = value;
+ break;
default:
/* Unknown domain, return */
return;
@@ -239,6 +244,8 @@ int imc_get_domain(struct device_node *pmu_dev)
return IMC_DOMAIN_NEST;
if (of_device_is_compatible(pmu_dev, IMC_DTB_CORE_COMPAT))
return IMC_DOMAIN_CORE;
+ if (of_device_is_compatible(pmu_dev, IMC_DTB_THREAD_COMPAT))
+ return IMC_DOMAIN_THREAD;
else
return UNKNOWN_DOMAIN;
}
@@ -277,7 +284,7 @@ static void imc_free_events(struct imc_events *events, int
nr_entries)
/*
* imc_pmu_create : Takes the parent device which is the pmu unit and a
* pmu_index as the inputs.
- * Allocates memory for the pmu, sets up its domain (NEST or CORE), and
+ * Allocates memory for the pmu, sets up its domain (NEST/CORE/THREAD), and
* allocates memory for the events supported by this pmu. Assigns a name for
* the pmu. Calls imc_events_node_parser() to setup the individual events.
* If everything goes fine, it calls, init_imc_pmu() to setup the pmu device
@@ -305,7 +312,7 @@ static int imc_pmu_create(struct device_node *parent, int
pmu_index)
if (pmu_ptr->domain == UNKNOWN_DOMAIN)
goto free_pmu;
- /* Needed for hotplug/migration */
+ /* Needed for hotplug/migration for nest and core IMC PMUs */
if (pmu_ptr->domain == IMC_DOMAIN_CORE)
core_imc_pmu = pmu_ptr;
else if (pmu_ptr->domain == IMC_DOMAIN_NEST)
--
2.7.4
[PATCH v4 00/10] IMC Instrumentation Support
Power 9 has In-Memory-Collection (IMC) infrastructure which contains
various Performance Monitoring Units (PMUs) at Nest level (these are
on-chip but off-core), Core level and Thread level.
The Nest PMU counters are handled by a Nest IMC microcode which runs
in the OCC (On-Chip Controller) complex. The microcode collects the
counter data and moves the nest IMC counter data to memory.
The Core and Thread IMC PMU counters are handled in the core. Core
level PMU counters give us the IMC counters' data per core and thread
level PMU counters give us the IMC counters' data per CPU thread.
This patchset enables the nest IMC, core IMC and thread IMC
PMUs and is based on the initial work done by Madhavan Srinivasan.
"Nest Instrumentation Support" :
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-August/132078.html
v1 for this patchset can be found here :
https://lwn.net/Articles/705475/
Nest events:
Per-chip nest instrumentation provides various per-chip metrics
such as memory, powerbus, Xlink and Alink bandwidth.
Core events:
Per-core IMC instrumentation provides various per-core metrics
such as non-idle cycles, non-idle instructions, various cache and
memory related metrics etc.
Thread events:
All the events for thread level are same as core level with the
difference being in the domain. These are per-cpu metrics.
PMU Events' Information:
OPAL obtains the IMC PMU and event information from the IMC Catalog
and passes on to the kernel via the device tree. The events' information
contains :
- Event name
- Event Offset
- Event description
and, maybe :
- Event scale
- Event unit
Some PMUs may have a common scale and unit values for all their
supported events. For those cases, the scale and unit properties for
those events must be inherited from the PMU.
The event offset in the memory is where the counter data gets
accumulated.
The OPAL-side patches are posted upstream :
https://lists.ozlabs.org/pipermail/skiboot/2017-January/005979.html
The kernel discovers the IMC counters information in the device tree
at the "imc-counters" device node which has a compatible field
"ibm,opal-in-memory-counters".
Parsing of the Events' information:
To parse the IMC PMUs and events information, the kernel has to
discover the "imc-counters" node and walk through the pmu and event
nodes.
Here is an excerpt of the dt showing the imc-counters with
mcs0 (nest), core and thread node:
/dts-v1/;
[...]
/dts-v1/;
/ {
name = "";
compatible = "ibm,opal-in-memory-counters";
#address-cells = <0x1>;
#size-cells = <0x1>;
imc-nest-offset = <0x32>;
imc-nest-size = <0x3>;
version-id = "";
NEST_MCS: nest-mcs-events {
#address-cells = <0x1>;
#size-cells = <0x1>;
event@0 {
event-name = "RRTO_QFULL_NO_DISP" ;
reg = <0x0 0x8>;
desc = "RRTO not dispatched in MCS0 due to capacity -
pulses once for each time a valid RRTO op is not dispatched due to a command
list full condition" ;
};
event@8 {
event-name = "WRTO_QFULL_NO_DISP" ;
reg = <0x8 0x8>;
desc = "WRTO not dispatched in MCS0 due to capacity -
pulses once for each time a valid WRTO op is not dispatched due to a command
list full condition" ;
};
[...]
mcs0 {
compatible = "ibm,imc-counters-nest";
events-prefix = "PM_MCS0_";
unit = "";
scale = "";
reg = <0x118 0x8>;
events = < &NEST_MCS >;
};
mcs1 {
compatible = "ibm,imc-counters-nest";
events-prefix = "PM_MCS1_";
unit = "";
scale = "";
reg = <0x198 0x8>;
events = < &NEST_MCS >;
};
[...]
CORE_EVENTS: core-events {
#address-cells = <0x1>;
#size-cells = <0x1>;
event@e0 {
event-name = "0THRD_NON_IDLE_PCYC" ;
reg = <0xe0 0x8>;
desc = "The number of processor cycles when all threads
are idle" ;
};
event@120 {
event-name = "1THRD_NON_IDLE_PCYC" ;
reg = <0x120 0x8>;
desc = "The number of processor cycles when exactly one
SMT thread is executing non-idle code" ;
};
[...]
core {
compatible = "ibm,imc-counters-core";
events-prefix = "CPM_";
unit = "";
scale = "";
reg = <0x0 0x8>;
events = < &CORE_EVENTS >;
};
thread {
compatible = "ibm,imc-counters-core";
events-prefix
[PATCH v4 08/10] powerpc/perf: PMU functions for Core IMC and hotplugging
This patch adds the PMU function to initialize a core IMC event. It also
adds cpumask initialization function for core IMC PMU. For
initialization, a page of memory is allocated per core where the data
for core IMC counters will be accumulated. The base address for this
page is sent to OPAL via an OPAL call which initializes various SCOMs
related to Core IMC initialization. Upon any errors, the pages are
free'ed and core IMC counters are disabled using the same OPAL call.
For CPU hotplugging, a cpumask is initialized which contains an online
CPU from each core. If a cpu goes offline, we check whether that cpu
belongs to the core imc cpumask, if yes, then, we migrate the PMU
context to any other online cpu (if available) in that core. If a cpu
comes back online, then this cpu will be added to the core imc cpumask
only if there was no other cpu from that core in the previous cpumask.
To register the hotplug functions for core_imc, a new state
CPUHP_AP_PERF_POWERPC_COREIMC_ONLINE is added to the list of existing
states.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Michael Neuling
Cc: Stewart Smith
Cc: Daniel Axtens
Cc: Stephane Eranian
Cc: Balbir Singh
Cc: Anju T Sudhakar
Signed-off-by: Hemant Kumar
---
arch/powerpc/include/asm/imc-pmu.h | 1 +
arch/powerpc/include/asm/opal-api.h| 10 +-
arch/powerpc/include/asm/opal.h| 2 +
arch/powerpc/perf/imc-pmu.c| 248 -
arch/powerpc/platforms/powernv/opal-imc.c | 4 +-
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
include/linux/cpuhotplug.h | 1 +
7 files changed, 257 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/imc-pmu.h
b/arch/powerpc/include/asm/imc-pmu.h
index 59de083..5e76cd0 100644
--- a/arch/powerpc/include/asm/imc-pmu.h
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -21,6 +21,7 @@
#define IMC_MAX_CHIPS 32
#define IMC_MAX_PMUS 32
#define IMC_MAX_PMU_NAME_LEN 256
+#define IMC_MAX_CORES 256
#define NEST_IMC_ENGINE_START 1
#define NEST_IMC_ENGINE_STOP 0
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index e15fb20..4ee52e8 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -169,7 +169,8 @@
#define OPAL_PCI_TCE_KILL 126
#define OPAL_NMMU_SET_PTCR 127
#define OPAL_NEST_IMC_COUNTERS_CONTROL 128
-#define OPAL_LAST 128
+#define OPAL_CORE_IMC_COUNTERS_CONTROL 129
+#define OPAL_LAST 129
/* Device tree flags */
@@ -929,6 +930,13 @@ enum {
OPAL_PCI_TCE_KILL_ALL,
};
+/* Operation argument to Core IMC */
+enum {
+ OPAL_CORE_IMC_DISABLE,
+ OPAL_CORE_IMC_ENABLE,
+ OPAL_CORE_IMC_INIT,
+};
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_API_H */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index d93d082..c4baa6d 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -229,6 +229,8 @@ int64_t opal_nmmu_set_ptcr(uint64_t chip_id, uint64_t ptcr);
int64_t opal_nest_imc_counters_control(uint64_t mode, uint64_t value1,
uint64_t value2, uint64_t value3);
+int64_t opal_core_imc_counters_control(uint64_t operation, uint64_t addr,
+ uint64_t value2, uint64_t value3);
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 9a0e3bc..61d99c7 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -1,5 +1,5 @@
/*
- * Nest Performance Monitor counter support.
+ * IMC Performance Monitor counter support.
*
* Copyright (C) 2016 Madhavan Srinivasan, IBM Corporation.
* (C) 2016 Hemant K Shaw, IBM Corporation.
@@ -18,6 +18,9 @@ struct perchip_nest_info nest_perchip_info[IMC_MAX_CHIPS];
struct imc_pmu *per_nest_pmu_arr[IMC_MAX_PMUS];
static cpumask_t nest_imc_cpumask;
+/* Maintains base addresses for all the cores */
+static u64 per_core_pdbar_add[IMC_MAX_CHIPS][IMC_MAX_CORES];
+static cpumask_t core_imc_cpumask;
struct imc_pmu *core_imc_pmu;
/* Needed for sanity check */
@@ -37,11 +40,18 @@ static struct attribute_group imc_format_group = {
/* Get the cpumask printed to a buffer "buf" */
static ssize_t imc_pmu_cpumask_get_attr(struct device *dev,
- struct device_attribute *attr, char *buf)
+ struct device_attribute *attr,
+ char *buf)
{
+ struct pmu *pmu = dev_get_drvdata(dev);
cpumask_t *active_mask;
-
Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
Hi Borislav, On Sun, Feb 19, 2017 at 02:50:19PM +0100, Borislav Petkov wrote: On Sun, Feb 19, 2017 at 09:06:51AM +0800, Fengguang Wu wrote: Yes if we add it as a line below the branch URL, it could be a time saver. Right. Since it's hard to teach ALL people about the rule, it'd be best if we can work w/o any rules -- unless you want to be accurate&helpful or to customize test behaviors. Since we already tested the original patch/commit (hence the report), we should know where the fixup should be applied to. And it'd be reasonably easy to tell whether the fix is incremental or a replacement -- just try git-am onto the original commit first, if failed, continue to try the parent commit. For old bugs the fix could be against linus/master or linux-next/master, which could be tried too. Makes sense. Yes, that'd be most convenient. In general the email interface could be something like this: # "key: value" fields; if you Re: to an earlier bug report, they can be auto retrieved compiler: gcc-6 # optional base-commit: v4.10-rc8 # the robot knows kernel commits from hundreds of public git trees --- the patch --- attach kconfig files Yap, just stick those rules somewhere on a website. OK, will do when the feature is ready. According to Xiaolong, the automated test-of-fixup-patches feature is already in our plan. For introductions of the now-working build/boot test services and instructions on customization, we could probably add some markdown document under https://github.com/fengguang/lkp-tests/tree/master/doc Philip/Ying, what do you think? I can draft it. Btw, this is not only useful for a follow-on, fix patch but also for initial test request. For example, I want to backport patch to stable and would like to run it on a bunch of kernels: base-commit: v4.4-stable, v4.9-stable, ... i.e., a list of trees to apply it to. I believe people might like this a lot. Or, for example, a patch touching a bunch of arches and author doesn't necessarily have access to all those different toolchains. Shoot a mail to the 0day bot: base-commit: linus/master arch: x86_64, powerpc, sparc, ... Would be very useful too. We actually already test LKML patch in that way (Xiaolong maintains this feature). Nevertheless if developers specify "base-commit:" it could help eliminate the guessing works by the dumb robot. We'll appreciate if the "base-commit:" or "base-patchid:" tags are listed in the patches, especially in some non-obvious situations. Such tags could be regarded as "explicit" test requests, where we could send "BUILD COMPLETE" emails as a response (comparing to our normal LKML patch tests, which only build regressions will trigger an email notification). Anyway, just a couple of ideas. What would also be cool if you guys had a 0day bot howto with all those things we should pay attention to and we can go and look up. OK. Your ideas are very welcome, thanks! Regards, Fengguang
Re: [GIT PULL] Block pull request for- 4.11-rc1
On 02/19/2017 07:59 PM, Jens Axboe wrote: > On 02/19/2017 07:12 PM, James Bottomley wrote: >> On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: >>> On 02/19/2017 06:09 PM, Bart Van Assche wrote: On 02/19/2017 04:11 PM, Jens Axboe wrote: > - Removal of the BLOCK_PC support in struct request, and > refactoring of > carrying SCSI payloads in the block layer. This cleans up the > code > nicely, and enables us to kill the SCSI specific parts of > struct > request, shrinking it down nicely. From Christoph mainly, with > help > from Hannes. Hello Jens, Christoph and Mike, Is anyone working on a fix for the regression introduced by the BLOCK_PC removal changes (general protection fault) that I had reported three weeks ago? See also https://www.spinics.net/lists/raid/msg55494.html >>> >>> I don't think that's a regression in this series, it just triggers >>> more easily with this series. The BLOCK_PC removal fixes aren't >>> touching device life times at all. >>> >>> That said, we will look into this again, of course. Christoph, any >>> idea? >> >> We could do with tracing the bdi removal failure issue fingered both by >> the block xfstests and Omar. It's something to do with this set of >> commits >> >>> - Fixes for duplicate bdi registrations and bdi/queue life time >>> problems from Jan and Dan. >> >> But no-one has actually root caused it yet. > > The above set from Jan and Dan fixed one set of issues around this, and > the reproducer test case was happy as well. But we've recently found > that there are still corner cases that aren't happy, Omar reported that > separately on Friday. So there will be a followup set for that, > hopefully intersecting with the issue that Bart reported. Forgot to mention, that these cases exist in 4.0 and 4.6 as well, so neither are a new problem with this series. The fixes from Jan and Dan didn't close all of them. -- Jens Axboe
Re: [GIT PULL] Block pull request for- 4.11-rc1
On 02/19/2017 07:12 PM, James Bottomley wrote: > On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: >> On 02/19/2017 06:09 PM, Bart Van Assche wrote: >>> On 02/19/2017 04:11 PM, Jens Axboe wrote: - Removal of the BLOCK_PC support in struct request, and refactoring of carrying SCSI payloads in the block layer. This cleans up the code nicely, and enables us to kill the SCSI specific parts of struct request, shrinking it down nicely. From Christoph mainly, with help from Hannes. >>> >>> Hello Jens, Christoph and Mike, >>> >>> Is anyone working on a fix for the regression introduced by the >>> BLOCK_PC removal changes (general protection fault) that I had >>> reported three weeks ago? See also >>> https://www.spinics.net/lists/raid/msg55494.html >> >> I don't think that's a regression in this series, it just triggers >> more easily with this series. The BLOCK_PC removal fixes aren't >> touching device life times at all. >> >> That said, we will look into this again, of course. Christoph, any >> idea? > > We could do with tracing the bdi removal failure issue fingered both by > the block xfstests and Omar. It's something to do with this set of > commits > >> - Fixes for duplicate bdi registrations and bdi/queue life time >> problems from Jan and Dan. > > But no-one has actually root caused it yet. The above set from Jan and Dan fixed one set of issues around this, and the reproducer test case was happy as well. But we've recently found that there are still corner cases that aren't happy, Omar reported that separately on Friday. So there will be a followup set for that, hopefully intersecting with the issue that Bart reported. -- Jens Axboe
linux-next: manual merge of the target-bva tree with the target-updates tree
Hi Bart,
Today's linux-next merge of the target-bva tree got conflicts in:
drivers/target/iscsi/cxgbit/cxgbit_target.c
drivers/target/iscsi/iscsi_target.c
include/target/iscsi/iscsi_transport.h
between commits:
9a584bf9bf0a ("target/iscsi: split iscsit_check_dataout_hdr()")
79e57cfe00f4 ("target/cxgbit: add T6 iSCSI DDP completion feature")
from the target-updates tree and commit:
b6f2cd5ab404 ("target/iscsi: split iscsit_check_dataout_hdr()")
b0d5eab94c37 ("target/cxgbit: add T6 iSCSI DDP completion feature")
from the target-bva tree.
I fixed it up (the target-update versions are updates from the others,
so I used those) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
Re: [PATCH RESEND v7 1/1] usb: xhci: plat: Enable async suspend/resume
On 10 February 2017 at 22:56, Robert Foss wrote: > From: Andrew Bresticker > > USB host controllers can take a significant amount of time to suspend > and resume, adding several hundred miliseconds to the kernel resume > time. Since the XHCI controller has no outside dependencies (other than > clocks, which are suspended late/resumed early), allow it to suspend and > resume asynchronously. > > Signed-off-by: Andrew Bresticker > Tested-by: Andrew Bresticker > Tested-by: Robert Foss > Signed-off-by: Robert Foss > --- > drivers/usb/host/xhci-plat.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c > index 3cf8e120c620..4d6741a0d8f8 100644 > --- a/drivers/usb/host/xhci-plat.c > +++ b/drivers/usb/host/xhci-plat.c > @@ -257,6 +257,7 @@ static int xhci_plat_probe(struct platform_device *pdev) > > pm_runtime_set_active(&pdev->dev); > pm_runtime_enable(&pdev->dev); > + device_enable_async_suspend(&pdev->dev); > > return 0; > > -- > 2.11.0.453.g787f75f05 > Reviewed-by: Baolin Wang -- Baolin.wang Best Regards
Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM
Hi Mathias, On 6 February 2017 at 13:26, Baolin Wang wrote: > Hi Mathias, > > On 31 January 2017 at 21:14, Mathias Nyman > wrote: >> On 16.01.2017 12:56, Baolin Wang wrote: >>> >>> Hi Mathias, >> >> >> Hi >> >> Sorry about the long review delay >> CC Alan in case my pm assumptions need to be corrected >> >> >>> >>> On 13 December 2016 at 15:49, Baolin Wang wrote: Enable the xhci plat runtime PM for parent device to suspend/resume xhci. Also call pm_runtime_get_noresume() in probe() function in case the parent device doesn't call suspend/resume callback by runtime PM now. Signed-off-by: Baolin Wang --- Changes since v4: - No updates. Changes since v3: - Fix kbuild error. Changes since v2: - Add pm_runtime_get_noresume() in probe() function. - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() function. Changes since v1: - No updates. --- >>> >>> >>> Do you have any comments about this patch? Thanks. >>> drivers/usb/host/xhci-plat.c | 41 - 1 file changed, 36 insertions(+), 5 deletions(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index ed56bf9..5805c6a 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev) if (ret) goto dealloc_usb2_hcd; + pm_runtime_get_noresume(&pdev->dev); + pm_runtime_set_active(&pdev->dev); + pm_runtime_enable(&pdev->dev); + return 0; >> >> To me this looks like we are not really enabling runtime pm for xhci, we >> increment the >> usage count in probe, and keep it until remove is called. >> >> This would normally prevent parent dwc3 from runtime suspending, but I see >> that in patch 2/2 adds >> pm_suspend_ignore_children(dev, true) to dwc3, and, that dwc3 actually >> controls xhci runtime >> pm by calling pm_runtime_get/put for xhci in its own dwc3 >> runtime_suspend/resume callbacks. >> >> Looks a bit upside down to me, what's the reason for this? >> >> what prevents calling pm_runtime_put_* before leaving probe in xhci and let >> pm code handle >> the runtime suspend and parent/child relationships? > > When dwc3 controller is working on host mode, which will create and > add the USB hcd for host side. Then if we want to suspend dwc3 > controller as host mode, the USB device (bus) of host side will > runtime suspend automatically if there are no slave attached (by > usb_runtime_suspend()--->usb_suspend_both()--->usb_suspend_interface()--->usb_suspend_device()--->generic_suspend()--->hcd_bus_suspend()--->xhci_bus_suspend()), > but we should not suspend xHCI device (issuing xhci_suspend()) now, > since some other controllers did not implement the runtime PM to > control xHCI device's runtime state, which will cause other > controllers can not resume xHCI device (issuing xhci_resume()) if the > xHCI device suspend automatically by its child device. Thus we should > get the runtime count for xHCI device in xhci_plat_probe() in case > xHCI device will also suspend automatically by its child device. > According to that, for xHCI device's parent: dwc3 device, we should > put the xHCI device's runtime count to suspend xHCI device manually. > Any more comments? -- Baolin.wang Best Regards
Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction
Hi Zain, On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote: > > The analogix_dp_transfer() will return -EBUSY if num_transferred is zero. > But sometimes we will send a bare address packet to start the transaction, > like drm_dp_i2c_xfer() show: > .. > /* Send a bare address packet to start the transaction. > * Zero sized messages specify an address only (bare > * address) transaction. > */ > msg.buffer = NULL; > msg.size = 0; > err = drm_dp_i2c_do_msg(aux, &msg); > .. > > In this case, the msg->size is zero, so the num_transferred will be zero too. > We can't return -EBUSY here, let's we return num_transferred if > num_transferred > equals msg->size. > Please see my question inline. > Signed-off-by: zain wang > --- > drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > index 303083a..5384aca 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c > @@ -1162,5 +1162,5 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device > *dp, > (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ) > msg->reply = DP_AUX_NATIVE_REPLY_ACK; > > - return num_transferred > 0 ? num_transferred : -EBUSY; > + return (num_transferred == msg->size) ? num_transferred : -EBUSY; I might be missing something but, looking at the code, I don't see any possibility of num_transferred ever being different than msg->size. To be honest, it doesn't seem to even make any sense keeping the local variable there, because msg->size can be simply always returned, as errors are handled by jumping to aux_error label. Best regards, Tomasz
Re: [PATCH] staging: lustre: ko2iblnd: Adapt to the removal of ib_get_dma_mr()
> In Linux kernel 4.9-rc1, the function ib_get_dma_mr()
> was removed and a second parameter was added to ib_alloc_pd().
> As this broke the building of the ko2iblnd module in
> staging, the Kconfig for LNet has marked ko2iblnd as broken
> and stopped building it.
>
> This patch fixes this breakage by:
>
> - Removing the BROKEN tag from lnet/Kconfig.
> - Make it so the module parameter map_on_demand can no longer be
> zero (we have to configure FMR/FastReg pools; it can no longer be
> off).
> - No longer try to use the global DMA memory region, but make use
> of the FMR/FastReg pool for all RDMA Tx operations.
> - Everywhere we are using the device DMA mr to derive the
> L-key for non-registered memory regions, use the
> pd->local_dma_lkey value instead.
> - Make the default map_on_demand = 256. This will allow nodes with
> this patch to still connected to older nodes without this patch
> and FMR/FastReg turned off. When FMR/FastReg is turned off, we
> use 256 as the max frags so the two sides will still be able to
> communicate and work.
> - Fix a mistake with BUILD_BUG_ON calls in o2iblnd.c which caused
> compiling to fail.
>
> Signed-off-by: Doug Oucharek
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-9026
> Reviewed-on: https://review.whamcloud.com/#/c/24931/
> Reviewed-by: James Simmons
Reviewed-by: James Simmons
> Changelog:
> v1) Initial patch
> v2) Rebased and handle a fix to BUILD_BUG_ON
> ---
> drivers/staging/lustre/lnet/Kconfig| 1 -
> .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c| 77
> ++
> .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 3 -
> .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 17 +
> .../lustre/lnet/klnds/o2iblnd/o2iblnd_modparams.c | 12 ++--
> 5 files changed, 16 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/staging/lustre/lnet/Kconfig
> b/drivers/staging/lustre/lnet/Kconfig
> index 13b4327..2b59301 100644
> --- a/drivers/staging/lustre/lnet/Kconfig
> +++ b/drivers/staging/lustre/lnet/Kconfig
> @@ -35,7 +35,6 @@ config LNET_SELFTEST
> config LNET_XPRT_IB
> tristate "LNET infiniband support"
> depends on LNET && INFINIBAND && INFINIBAND_ADDR_TRANS
> - depends on BROKEN
> default LNET && INFINIBAND
> help
> This option allows the LNET users to use infiniband as an
> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> index b1e8508..0618b79 100644
> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> @@ -1281,27 +1281,6 @@ static void kiblnd_map_tx_pool(struct kib_tx_pool *tpo)
> }
> }
>
> -struct ib_mr *kiblnd_find_rd_dma_mr(struct lnet_ni *ni, struct kib_rdma_desc
> *rd,
> - int negotiated_nfrags)
> -{
> - struct kib_net *net = ni->ni_data;
> - struct kib_hca_dev *hdev = net->ibn_dev->ibd_hdev;
> - struct lnet_ioctl_config_o2iblnd_tunables *tunables;
> - __u16 nfrags;
> - int mod;
> -
> - tunables = &ni->ni_lnd_tunables->lt_tun_u.lt_o2ib;
> - mod = tunables->lnd_map_on_demand;
> - nfrags = (negotiated_nfrags != -1) ? negotiated_nfrags : mod;
> -
> - LASSERT(hdev->ibh_mrs);
> -
> - if (mod > 0 && nfrags <= rd->rd_nfrags)
> - return NULL;
> -
> - return hdev->ibh_mrs;
> -}
> -
> static void kiblnd_destroy_fmr_pool(struct kib_fmr_pool *fpo)
> {
> LASSERT(!fpo->fpo_map_count);
> @@ -2168,21 +2147,12 @@ static int kiblnd_net_init_pools(struct kib_net *net,
> lnet_ni_t *ni, __u32 *cpts
>int ncpts)
> {
> struct lnet_ioctl_config_o2iblnd_tunables *tunables;
> - unsigned long flags;
> int cpt;
> int rc;
> int i;
>
> tunables = &ni->ni_lnd_tunables->lt_tun_u.lt_o2ib;
>
> - read_lock_irqsave(&kiblnd_data.kib_global_lock, flags);
> - if (!tunables->lnd_map_on_demand) {
> - read_unlock_irqrestore(&kiblnd_data.kib_global_lock, flags);
> - goto create_tx_pool;
> - }
> -
> - read_unlock_irqrestore(&kiblnd_data.kib_global_lock, flags);
> -
> if (tunables->lnd_fmr_pool_size < *kiblnd_tunables.kib_ntx / 4) {
> CERROR("Can't set fmr pool size (%d) < ntx / 4(%d)\n",
> tunables->lnd_fmr_pool_size,
> @@ -2227,7 +2197,6 @@ static int kiblnd_net_init_pools(struct kib_net *net,
> lnet_ni_t *ni, __u32 *cpts
> if (i > 0)
> LASSERT(i == ncpts);
>
> - create_tx_pool:
> /*
>* cfs_precpt_alloc is creating an array of struct kib_tx_poolset
>* The number of struct kib_tx_poolsets create is equal to the
> @@ -2283,20 +2252,8 @@ static int kiblnd_hdev_get_attr(struct kib_hca_dev
> *hdev)
> return -EINVAL;
> }
>
> -static void kiblnd_hdev_cleanup_mrs(struct kib_hca_dev *hdev)
> -{
> - if (!hdev->ibh_mrs)
> -
Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase
On 17 February 2017 at 16:04, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: (One possible approach would be to have the setup routine return different values for explicit and implicit status stages -- for example, return 1 if it wants to submit an explicit status request. That wouldn't be very different from the current USB_GADGET_DELAYED_STATUS approach.) >>> >>> not really, no. The idea was for composite.c and/or functions to support >>> both methods (temporarily) and use "gadget->wants_explicit_stages" to >>> explicitly queue DATA and STATUS. That would mean that f_mass_storage >>> wouldn't have to return DELAYED_STATUS if >>> (gadget->wants_explicit_stages). >>> >>> After all UDCs are converted over and set wants_explicit_stages (which >>> should all be done in a single series), then we get rid of the flag and >>> the older method of DELAYED_STATUS. >> >> (Sorry for late reply due to my holiday) >> I also met the problem pointed by Alan, from my test, I still want to >> need one return value to indicate if it wants to submit an explicit >> status request. Think about the Control-IN with a data stage, we can >> not get the STATUS phase request from usb_ep_queue() call, and we need > > why not? wLength tells you that this is a 3-stage transfer. Gadget > driver should be able to figure out that it needs to usb_ep_queue() > another request for status stage. > >> to handle this STATUS phase request in dwc3_ep0_xfernotready(). But >> Control-OUT will get one 0-length IN request for the status stage from >> usb_ep_queue(), so we need one return value from setup routine to > > no we don't :-) > >> distinguish these in dwc3_ep0_xfernotready(), or we can not handle >> status request correctly. Maybe I missed something else. >>> On the other hand, I am very doubtful about requiring explicit setup requests. >>> >>> right, me too ;-) >> >> So do you suggest me continue to try to do this? Thanks. > > explicit setup? no > explicit status? yes > > If you don't wanna do it, it's fine :-) I'll just add to my TODO > list. It just depends on how much other tasks you have on your end ;-) OK, I will take some time to check and test again. It will be better if I send out one RFC patch to review. -- Baolin.wang Best Regards
Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction
Hi Sean, Could you give some comments for this patch? Thanks Zain 在 2017/2/13 17:27, zain wang 写道: The analogix_dp_transfer() will return -EBUSY if num_transferred is zero. But sometimes we will send a bare address packet to start the transaction, like drm_dp_i2c_xfer() show: .. /* Send a bare address packet to start the transaction. * Zero sized messages specify an address only (bare * address) transaction. */ msg.buffer = NULL; msg.size = 0; err = drm_dp_i2c_do_msg(aux, &msg); .. In this case, the msg->size is zero, so the num_transferred will be zero too. We can't return -EBUSY here, let's we return num_transferred if num_transferred equals msg->size. Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c index 303083a..5384aca 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c @@ -1162,5 +1162,5 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device *dp, (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ) msg->reply = DP_AUX_NATIVE_REPLY_ACK; - return num_transferred > 0 ? num_transferred : -EBUSY; + return (num_transferred == msg->size) ? num_transferred : -EBUSY; }
Re: [GIT PULL] Block pull request for- 4.11-rc1
On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: > On 02/19/2017 06:09 PM, Bart Van Assche wrote: > > On 02/19/2017 04:11 PM, Jens Axboe wrote: > > > - Removal of the BLOCK_PC support in struct request, and > > > refactoring of > > > carrying SCSI payloads in the block layer. This cleans up the > > > code > > > nicely, and enables us to kill the SCSI specific parts of > > > struct > > > request, shrinking it down nicely. From Christoph mainly, with > > > help > > > from Hannes. > > > > Hello Jens, Christoph and Mike, > > > > Is anyone working on a fix for the regression introduced by the > > BLOCK_PC removal changes (general protection fault) that I had > > reported three weeks ago? See also > > https://www.spinics.net/lists/raid/msg55494.html > > I don't think that's a regression in this series, it just triggers > more easily with this series. The BLOCK_PC removal fixes aren't > touching device life times at all. > > That said, we will look into this again, of course. Christoph, any > idea? We could do with tracing the bdi removal failure issue fingered both by the block xfstests and Omar. It's something to do with this set of commits > - Fixes for duplicate bdi registrations and bdi/queue life time > problems from Jan and Dan. But no-one has actually root caused it yet. James
[PATCH] PM / AVS: rockchip-io: add io selectors and supplies for rk3328
From: "david.wu"
This adds the necessary data for handling io voltage domains on the rk3328.
As interesting tidbit, the rk3328 only contains one iodomain area in the
regular General Register Files (GRF).
Signed-off-by: david.wu
---
.../bindings/power/rockchip-io-domain.txt | 1 +
drivers/power/avs/rockchip-io-domain.c | 41 ++
2 files changed, 42 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
index d23dc00..d3a5a93 100644
--- a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
+++ b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
@@ -33,6 +33,7 @@ Required properties:
- compatible: should be one of:
- "rockchip,rk3188-io-voltage-domain" for rk3188
- "rockchip,rk3288-io-voltage-domain" for rk3288
+ - "rockchip,rk3328-io-voltage-domain" for rk3328
- "rockchip,rk3368-io-voltage-domain" for rk3368
- "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains
- "rockchip,rk3399-io-voltage-domain" for rk3399
diff --git a/drivers/power/avs/rockchip-io-domain.c
b/drivers/power/avs/rockchip-io-domain.c
index 56bce19..8581252 100644
--- a/drivers/power/avs/rockchip-io-domain.c
+++ b/drivers/power/avs/rockchip-io-domain.c
@@ -43,6 +43,10 @@
#define RK3288_SOC_CON2_FLASH0 BIT(7)
#define RK3288_SOC_FLASH_SUPPLY_NUM2
+#define RK3328_SOC_CON40x410
+#define RK3328_SOC_CON4_VCCIO2 BIT(7)
+#define RK3328_SOC_VCCIO2_SUPPLY_NUM 1
+
#define RK3368_SOC_CON15 0x43c
#define RK3368_SOC_CON15_FLASH0BIT(14)
#define RK3368_SOC_FLASH_SUPPLY_NUM2
@@ -166,6 +170,25 @@ static void rk3288_iodomain_init(struct rockchip_iodomain
*iod)
dev_warn(iod->dev, "couldn't update flash0 ctrl\n");
}
+static void rk3328_iodomain_init(struct rockchip_iodomain *iod)
+{
+ int ret;
+ u32 val;
+
+ /* if no vccio2 supply we should leave things alone */
+ if (!iod->supplies[RK3328_SOC_VCCIO2_SUPPLY_NUM].reg)
+ return;
+
+ /*
+* set vccio2 iodomain to also use this framework
+* instead of a special gpio.
+*/
+ val = RK3328_SOC_CON4_VCCIO2 | (RK3328_SOC_CON4_VCCIO2 << 16);
+ ret = regmap_write(iod->grf, RK3328_SOC_CON4, val);
+ if (ret < 0)
+ dev_warn(iod->dev, "couldn't update vccio2 vsel ctrl\n");
+}
+
static void rk3368_iodomain_init(struct rockchip_iodomain *iod)
{
int ret;
@@ -247,6 +270,20 @@ static void rk3399_pmu_iodomain_init(struct
rockchip_iodomain *iod)
.init = rk3288_iodomain_init,
};
+static const struct rockchip_iodomain_soc_data soc_data_rk3328 = {
+ .grf_offset = 0x410,
+ .supply_names = {
+ "vccio1",
+ "vccio2",
+ "vccio3",
+ "vccio4",
+ "vccio5",
+ "vccio6",
+ "pmuio",
+ },
+ .init = rk3328_iodomain_init,
+};
+
static const struct rockchip_iodomain_soc_data soc_data_rk3368 = {
.grf_offset = 0x900,
.supply_names = {
@@ -312,6 +349,10 @@ static void rk3399_pmu_iodomain_init(struct
rockchip_iodomain *iod)
.data = (void *)&soc_data_rk3288
},
{
+ .compatible = "rockchip,rk3328-io-voltage-domain",
+ .data = (void *)&soc_data_rk3328
+ },
+ {
.compatible = "rockchip,rk3368-io-voltage-domain",
.data = (void *)&soc_data_rk3368
},
--
1.9.1
Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images
On 2017-02-19 17:33, Bryan O'Donoghue wrote:
>
>
> On 19/02/17 13:33, Jan Kiszka wrote:
>>> I would not object strongly to having conditionally compiled code in
>>> mainline that adds support for this, but bodging the default code path
>>> like this for a Quark quirk is out of the question imo.
>> I'm open for any consensus that avoids bending mainline too much and
>> still helps us (and maybe also other Quark X1020 integrators) getting
>> rid of additional patches.
>
> We could make efi_capsule_setup_info() a weak symbol just like
>
> drivers/firmware/efi/reboot.c:
> bool __weak efi_poweroff_required(void)
>
> that way Arm is none the wiser and we can bury the Quark Quirk in
> x86/platform/efi/quirks.c - where you're right Ard it arguably belongs -
> not in the core code.
>
> diff --git a/arch/x86/platform/efi/quirks.c
> b/arch/x86/platform/efi/quirks.c
> index 30031d5..950663da 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -495,3 +495,19 @@ bool efi_poweroff_required(void)
> {
> return acpi_gbl_reduced_hardware || acpi_no_s5;
> }
> +
> +ssize_t csh_efi_capsule_setup_info(struct capsule_info *cap_info,
> + void *kbuff, size_t hdr_bytes)
> +{
> + /* Code to deal with the CSH goes here */
> + return 0;
> +}
> +
> +ssize_t efi_capsule_setup_info(struct capsule_info *cap_info,
> + void *kbuff, size_t hdr_bytes)
> +{
> + if (quark)
> + return csh_efi_capsule_setup_info(cap_info, kbuff,
> hdr_bytes);
> + else
> + return __efi_capsule_setup_info(cap_info, kbuff,
> hdr_bytes);
> +}
>
> diff --git a/drivers/firmware/efi/capsule-loader.c
> b/drivers/firmware/efi/capsule-loader.c
> index 9ae6c11..d8bdc6f 100644
> --- a/drivers/firmware/efi/capsule-loader.c
> +++ b/drivers/firmware/efi/capsule-loader.c
> @@ -53,7 +53,7 @@ static void efi_free_all_buff_pages(struct
> capsule_info *cap_info)
> * @kbuff: a mapped first page buffer pointer
> * @hdr_bytes: the total received number of bytes for efi header
> **/
> -static ssize_t efi_capsule_setup_info(struct capsule_info *cap_info,
> +ssize_t __efi_capsule_setup_info(struct capsule_info *cap_info,
> void *kbuff, size_t hdr_bytes)
> {
> efi_capsule_header_t *cap_hdr;
> @@ -98,6 +98,13 @@ static ssize_t efi_capsule_setup_info(struct
> capsule_info *cap_info,
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(__efi_capsule_setup_info);
> +
> +ssize_t __weak efi_capsule_setup_info(struct capsule_info *cap_info,
> +void *kbuff, size_t hdr_bytes)
> +{
> + return __efi_capsule_setup_info(cap_info, kbuff, hdr_bytes);
> +}
>
Good idea.
> One thing we want is to continue to have Quark work on ia32 builds
> without having to compile a Quark specific kernel just to get this
> feature working.
>
> Jan I haven't had time to look at what you said about the BSP code not
> working with capsules on Gen2 (I will during the week though). If you
> currently have to strip the CSH to make this work then we're missing a
> trick on tip-of-tree and need to sort that out for the final version of
> this.
Yes, I agree. I will look into this when I'm back from ELC next week (no
related hardware with me).
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
[GIT pull] irq updates for 4.11
Linus,
please pull the latest irq-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus
This update provides:
- Yet another two irq controller chip drivers
- A few updates and fixes for GICV3
- A resource managed function for interrupt allocation
- Fixes, updates and enhancements all over the place
Thanks,
tglx
-->
Agustin Vega-Frias (3):
ACPI: Generic GSI: Do not attempt to map non-GSI IRQs during bus scan
ACPI: Add support for ResourceSource/IRQ domain mapping
irqchip/qcom: Add IRQ combiner driver
Alim Akhtar (1):
irqchip/gic-v3: Remove duplicate definition of GICD_TYPER_LPIS
Arnd Bergmann (1):
genirq/msi: Add stubs for get_cached_msi_msg/pci_write_msi_msg
Bartosz Golaszewski (1):
irqdesc: Add a resource managed version of irq_alloc_descs()
Christophe JAILLET (1):
irqchip/qcom: Fix error handling
H Hartley Sweeten (1):
genirq: Fix /proc/interrupts output alignment
Heiner Kallweit (1):
genirq/devres: Use dev_name(dev) as default for devname
Jeremy Kerr (1):
genirq: Clarify logic calculating bogus irqreturn_t values
Linus Walleij (2):
irqchip: DT bindings for Cortina Gemini irqchip
irqchip: Add a driver for Cortina Gemini
Marc Zyngier (4):
irqchip/gic-v3-its: Refactor command encoding
irqchip/gic-v3-its: Drop deprecated GITS_BASER_TYPE_CPU
irqchip/gic-v3-its: Rename MAPVI to MAPTI
irqchip/gic-v3-its: Zero command on allocation
Marcin Nowakowski (1):
irqchip/mips-gic: Fix local interrupts
Matthias Brugger (1):
irq/platform-msi: Fix comment about maximal MSIs
Robert Richter (1):
irqchip/gic-v3-its: Fix command buffer allocation
Shanker Donthineni (1):
irqchip/gic-v3-its: Enable cacheable attribute Read-allocate hints
.../cortina,gemini-interrupt-controller.txt| 22 ++
Documentation/driver-model/devres.txt | 5 +
drivers/acpi/Makefile | 2 +-
drivers/acpi/gsi.c | 98 ---
drivers/acpi/irq.c | 297 +
drivers/acpi/resource.c| 18 +-
drivers/base/platform-msi.c| 2 +-
drivers/base/platform.c| 10 +
drivers/irqchip/Kconfig| 9 +
drivers/irqchip/Makefile | 2 +
drivers/irqchip/irq-gemini.c | 185 +
drivers/irqchip/irq-gic-v3-its.c | 85 +++---
drivers/irqchip/irq-mips-gic.c | 29 ++
drivers/irqchip/qcom-irq-combiner.c| 296
include/linux/acpi.h | 10 +
include/linux/irq.h| 19 ++
include/linux/irqchip/arm-gic-v3.h | 5 +-
include/linux/msi.h| 11 +-
kernel/irq/devres.c| 65 -
kernel/irq/proc.c | 2 +
kernel/irq/spurious.c | 4 +-
21 files changed, 1027 insertions(+), 149 deletions(-)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/cortina,gemini-interrupt-controller.txt
delete mode 100644 drivers/acpi/gsi.c
create mode 100644 drivers/acpi/irq.c
create mode 100644 drivers/irqchip/irq-gemini.c
create mode 100644 drivers/irqchip/qcom-irq-combiner.c
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/cortina,gemini-interrupt-controller.txt
b/Documentation/devicetree/bindings/interrupt-controller/cortina,gemini-interrupt-controller.txt
new file mode 100644
index ..97c1167fa533
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/cortina,gemini-interrupt-controller.txt
@@ -0,0 +1,22 @@
+* Cortina Systems Gemini interrupt controller
+
+This interrupt controller is found on the Gemini SoCs.
+
+Required properties:
+- compatible: must be "cortina,gemini-interrupt-controller"
+- reg: The register bank for the interrupt controller.
+- interrupt-controller: Identifies the node as an interrupt controller
+- #interrupt-cells: The number of cells to define the interrupts.
+ Must be 2 as the controller can specify level or rising edge
+ IRQs. The bindings follows the standard binding for controllers
+ with two cells specified in
+ interrupt-controller/interrupts.txt
+
+Example:
+
+interrupt-controller@4800 {
+ compatible = "cortina,gemini-interrupt-controller";
+ reg = <0x4800 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+};
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index ca9d1eb46bc0..bf34d5b3a733 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -306,6 +306,11 @@ IR
[PATCH v2 1/1] gpio: altera: Use handle_level_irq when configured as a level_high
When a threaded irq handler is chained attached to one of the gpio
pins when configure for level irq the altera_gpio_irq_leveL_high_handler
does not mask the interrupt while being handled by the chained irq.
This resulting in the threaded irq not getting enough cycles to complete
quickly enough before the irq was disabled as faulty. handle_level_irq
should be used in this situation instead of handle_simple_irq.
In gpiochip_irqchip_add set default handler to handle_bad_irq as
per Documentation/gpio/driver.txt. Then set the correct handler in
the set_type callback.
Signed-off-by: Phil Reid
---
Notes:
Change from v1:
- As per hint from Andy.
Set handler to handle_bad_irq in gpiochip_irqchip_add
This is inline with documentation but not what most gpio drivers do.
So I'm guessing this is now the correct way to do things.
drivers/gpio/gpio-altera.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
index 5bddbd5..3fe6a21 100644
--- a/drivers/gpio/gpio-altera.c
+++ b/drivers/gpio/gpio-altera.c
@@ -90,21 +90,18 @@ static int altera_gpio_irq_set_type(struct irq_data *d,
altera_gc = gpiochip_get_data(irq_data_get_irq_chip_data(d));
- if (type == IRQ_TYPE_NONE)
+ if (type == IRQ_TYPE_NONE) {
+ irq_set_handler_locked(d, handle_bad_irq);
return 0;
- if (type == IRQ_TYPE_LEVEL_HIGH &&
- altera_gc->interrupt_trigger == IRQ_TYPE_LEVEL_HIGH)
- return 0;
- if (type == IRQ_TYPE_EDGE_RISING &&
- altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_RISING)
- return 0;
- if (type == IRQ_TYPE_EDGE_FALLING &&
- altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_FALLING)
- return 0;
- if (type == IRQ_TYPE_EDGE_BOTH &&
- altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_BOTH)
+ }
+ if (type == altera_gc->interrupt_trigger) {
+ if (type == IRQ_TYPE_LEVEL_HIGH)
+ irq_set_handler_locked(d, handle_level_irq);
+ else
+ irq_set_handler_locked(d, handle_simple_irq);
return 0;
-
+ }
+ irq_set_handler_locked(d, handle_bad_irq);
return -EINVAL;
}
@@ -230,7 +227,6 @@ static void altera_gpio_irq_edge_handler(struct irq_desc
*desc)
chained_irq_exit(chip, desc);
}
-
static void altera_gpio_irq_leveL_high_handler(struct irq_desc *desc)
{
struct altera_gpio_chip *altera_gc;
@@ -310,7 +306,7 @@ static int altera_gpio_probe(struct platform_device *pdev)
altera_gc->interrupt_trigger = reg;
ret = gpiochip_irqchip_add(&altera_gc->mmchip.gc, &altera_irq_chip, 0,
- handle_simple_irq, IRQ_TYPE_NONE);
+ handle_bad_irq, IRQ_TYPE_NONE);
if (ret) {
dev_err(&pdev->dev, "could not add irqchip\n");
--
1.8.3.1
Re: [PATCH] drm/rockchip: cdn-dp: Fix error handling
On 2017年02月20日 00:59, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in this
case.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
Signed-off-by: Christophe JAILLET
---
Not sure but a 'pm_runtime_get_sync()' is maybe also required in the
'err_set_rate' path.
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 9ab67a670885..0fe1ec8b8fb1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -111,7 +111,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
ret = pm_runtime_get_sync(dp->dev);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
- goto err_pclk;
+ goto err_sync;
I think the name err_pm_runtime_get is better.
err_sync is not a clear name for the pm_runtime_get_sync.
}
reset_control_assert(dp->core_rst);
@@ -133,6 +133,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
return 0;
err_set_rate:
+err_sync:
miss pm_runtime_put, it should be:
err_set_rate:
pm_runtime_put(dp->dev);
err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
clk_disable_unprepare(dp->pclk);
--
Ｍark Yao
[GIT pull} timer updates for 4.11
Linus,
please pull the latest timers-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-core-for-linus
Nothing exciting, just the usual pile of fixes, updates and cleanups:
- A bunch of clocksource driver updates
- Removal of CONFIG_TIMER_STATS and the related /proc file
- More posix timer slim down work
- A scalability enhancement in the tick broadcast code
- Math cleanups
Thanks,
tglx
-->
Bhumika Goyal (1):
clocksource/drivers/arm_arch_timer:: Mark cyclecounter __ro_after_init
Chris Brandt (2):
clocksource/drivers/ostm: Document renesas-ostm timer DT bindings
clocksource/drivers/ostm: Add renesas-ostm timer driver
Daniel Lezcano (1):
clockevents: Add a clkevt-of mechanism like clksrc-of
David Engraf (1):
clocksource/drivers/tcb_clksrc: Use 32 bit tcb as sched_clock
Ding Tianhong (4):
clocksource/drivers/arm_arch_timer: Add dt binding for
hisilicon-161010101 erratum
clocksource/drivers/arm_arch_timer: Remove fsl-a008585 parameter
clocksource/drivers/arm_arch_timer: Introduce generic errata handling
infrastructure
clocksource/drivers/arm_arch_timer: Work around Hisilicon erratum
161010101
Geliang Tang (1):
timerqueue: Use rb_entry_safe() instead of open-coding it
Jiri Slaby (1):
x86/timer: Make delay() work during early bootup
Kees Cook (1):
time: Remove CONFIG_TIMER_STATS
Linus Walleij (2):
clocksource: add DT bindings for Cortina Gemini
clocksource/drivers/gemini: Add driver for the Cortina Gemini
Marc Zyngier (1):
hrtimer: Catch invalid clockids again
Mars Cheng (1):
timer_list: Remove useless cast when printing
Nicolas Pitre (1):
timers: Omit POSIX timer stuff from task_struct when disabled
Peter Zijlstra (1):
math64, timers: Fix 32bit mul_u64_u32_shr() and friends
Russell King (1):
delay: Add explanation of udelay() inaccuracy
Stephen Boyd (1):
timekeeping: Remove unused timekeeping_{get,set}_tai_offset()
Sudip Mukherjee (1):
math64, tile: Fix build failure
Thomas Gleixner (1):
timerfd: Protect the might cancel mechanism proper
Waiman Long (1):
tick/broadcast: Reduce lock cacheline contention
Documentation/admin-guide/kernel-parameters.txt| 9 -
.../devicetree/bindings/arm/arch_timer.txt | 6 +
.../bindings/timer/cortina,gemini-timer.txt| 22 ++
.../devicetree/bindings/timer/renesas,ostm.txt | 30 ++
Documentation/timers/timer_stats.txt | 73
arch/arm/mach-shmobile/Kconfig | 1 +
arch/arm64/include/asm/arch_timer.h| 38 +-
arch/tile/include/asm/Kbuild | 1 -
arch/tile/include/asm/div64.h | 16 +
arch/x86/include/asm/div64.h | 11 +
arch/x86/lib/delay.c | 4 +-
drivers/clocksource/Kconfig| 38 ++
drivers/clocksource/Makefile | 3 +
drivers/clocksource/arm_arch_timer.c | 153 ++--
drivers/clocksource/clkevt-probe.c | 56 +++
drivers/clocksource/renesas-ostm.c | 265 +
drivers/clocksource/tcb_clksrc.c | 16 +-
drivers/clocksource/timer-gemini.c | 277 ++
fs/proc/base.c | 4 +-
fs/timerfd.c | 17 +-
include/linux/clockchips.h | 9 +
include/linux/cpumask.h| 7 +-
include/linux/delay.h | 11 +
include/linux/hrtimer.h| 11 -
include/linux/init_task.h | 40 +-
include/linux/math64.h | 26 +-
include/linux/sched.h | 13 +-
include/linux/timer.h | 45 ---
kernel/fork.c | 10 +-
kernel/kthread.c | 1 -
kernel/sched/rt.c | 4 +
kernel/sched/stats.h | 32 +-
kernel/time/Makefile | 1 -
kernel/time/hrtimer.c | 58 +--
kernel/time/tick-broadcast.c | 15 +-
kernel/time/timekeeping.c | 39 +-
kernel/time/timekeeping.h | 2 -
kernel/time/timer.c| 48 +--
kernel/time/timer_list.c | 12 +-
kernel/time/timer_stats.c | 425 -
kernel/workqueue.c | 2 -
lib/Kconfig.debug | 14 -
lib/timerqueue.c | 3 +-
43 files changed, 1022 insertions(+), 846 deletions(-)
[tip:WIP.sched/core 102/154] include/linux/list.h:463:43: error: dereferencing pointer to incomplete type
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.sched/core
head: 12372f63e2728a509817b56878cd6633d92053b3
commit: 39a8751a41237a0f039083161faddb8bf48e4e70 [102/154] sched/headers:
Remove the dependency from
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
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
git checkout 39a8751a41237a0f039083161faddb8bf48e4e70
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from drivers/video/fbdev/auo_k190x.c:11:
drivers/video/fbdev/auo_k190x.c: In function 'auok190xfb_dpy_deferred_io':
>> include/linux/list.h:463:43: error: dereferencing pointer to incomplete type
for (pos = list_first_entry(head, typeof(*pos), member); \
^
include/linux/kernel.h:850:18: note: in definition of macro 'container_of'
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
include/linux/list.h:376:2: note: in expansion of macro 'list_entry'
list_entry((ptr)->next, type, member)
^
include/linux/list.h:463:13: note: in expansion of macro 'list_first_entry'
for (pos = list_first_entry(head, typeof(*pos), member); \
^
drivers/video/fbdev/auo_k190x.c:330:2: note: in expansion of macro
'list_for_each_entry'
list_for_each_entry(cur, &fbdefio->pagelist, lru) {
^
include/linux/kernel.h:850:48: warning: initialization from incompatible
pointer type
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
include/linux/list.h:365:2: note: in expansion of macro 'container_of'
container_of(ptr, type, member)
^
include/linux/list.h:376:2: note: in expansion of macro 'list_entry'
list_entry((ptr)->next, type, member)
^
include/linux/list.h:463:13: note: in expansion of macro 'list_first_entry'
for (pos = list_first_entry(head, typeof(*pos), member); \
^
drivers/video/fbdev/auo_k190x.c:330:2: note: in expansion of macro
'list_for_each_entry'
list_for_each_entry(cur, &fbdefio->pagelist, lru) {
^
>> include/linux/list.h:463:43: error: dereferencing pointer to incomplete type
for (pos = list_first_entry(head, typeof(*pos), member); \
^
include/linux/kernel.h:851:3: note: in definition of macro 'container_of'
(type *)( (char *)__mptr - offsetof(type,member) );})
^
include/linux/list.h:376:2: note: in expansion of macro 'list_entry'
list_entry((ptr)->next, type, member)
^
include/linux/list.h:463:13: note: in expansion of macro 'list_first_entry'
for (pos = list_first_entry(head, typeof(*pos), member); \
^
drivers/video/fbdev/auo_k190x.c:330:2: note: in expansion of macro
'list_for_each_entry'
list_for_each_entry(cur, &fbdefio->pagelist, lru) {
^
In file included from include/linux/compiler.h:58:0,
from include/uapi/linux/stddef.h:1,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from drivers/video/fbdev/auo_k190x.c:11:
>> include/linux/list.h:463:43: error: dereferencing pointer to incomplete type
for (pos = list_first_entry(head, typeof(*pos), member); \
^
include/linux/compiler-gcc.h:159:21: note: in definition of macro
'__compiler_offsetof'
__builtin_offsetof(a, b)
^
include/linux/kernel.h:851:29: note: in expansion of macro 'offsetof'
(type *)( (char *)__mptr - offsetof(type,member) );})
^
include/linux/list.h:365:2: note: in expansion of macro 'container_of'
container_of(ptr, type, member)
^
include/linux/list.h:376:2: note: in expansion of macro 'list_entry'
list_entry((ptr)->next, type, member)
^
include/linux/list.h:463:13: note: in expansion of macro 'list_first_entry'
for (pos = list_first_entry(head, typeof(*pos), member); \
^
drivers/video/fbdev/auo_k190x.c:330:2: note: in expansion of macro
'list_for_each_entry'
list_for_each_entry(cur, &fbdefio->pagelist, lru) {
^
In file included from include/linux/module.h:9:0,
from drivers/video/fbdev/auo_k190x.c:11:
include/linux/list.h:464:11: error: dereferencing pointer to incomplete typ
Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images
On 19/02/17 13:33, Jan Kiszka wrote:
I would not object strongly to having conditionally compiled code in
mainline that adds support for this, but bodging the default code path
like this for a Quark quirk is out of the question imo.
I'm open for any consensus that avoids bending mainline too much and
still helps us (and maybe also other Quark X1020 integrators) getting
rid of additional patches.
We could make efi_capsule_setup_info() a weak symbol just like
drivers/firmware/efi/reboot.c:
bool __weak efi_poweroff_required(void)
that way Arm is none the wiser and we can bury the Quark Quirk in
x86/platform/efi/quirks.c - where you're right Ard it arguably belongs -
not in the core code.
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 30031d5..950663da 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -495,3 +495,19 @@ bool efi_poweroff_required(void)
{
return acpi_gbl_reduced_hardware || acpi_no_s5;
}
+
+ssize_t csh_efi_capsule_setup_info(struct capsule_info *cap_info,
+ void *kbuff, size_t hdr_bytes)
+{
+ /* Code to deal with the CSH goes here */
+ return 0;
+}
+
+ssize_t efi_capsule_setup_info(struct capsule_info *cap_info,
+ void *kbuff, size_t hdr_bytes)
+{
+ if (quark)
+ return csh_efi_capsule_setup_info(cap_info, kbuff,
hdr_bytes);
+ else
+ return __efi_capsule_setup_info(cap_info, kbuff, hdr_bytes);
+}
diff --git a/drivers/firmware/efi/capsule-loader.c
b/drivers/firmware/efi/capsule-loader.c
index 9ae6c11..d8bdc6f 100644
--- a/drivers/firmware/efi/capsule-loader.c
+++ b/drivers/firmware/efi/capsule-loader.c
@@ -53,7 +53,7 @@ static void efi_free_all_buff_pages(struct
capsule_info *cap_info)
* @kbuff: a mapped first page buffer pointer
* @hdr_bytes: the total received number of bytes for efi header
**/
-static ssize_t efi_capsule_setup_info(struct capsule_info *cap_info,
+ssize_t __efi_capsule_setup_info(struct capsule_info *cap_info,
void *kbuff, size_t hdr_bytes)
{
efi_capsule_header_t *cap_hdr;
@@ -98,6 +98,13 @@ static ssize_t efi_capsule_setup_info(struct
capsule_info *cap_info,
return 0;
}
+EXPORT_SYMBOL_GPL(__efi_capsule_setup_info);
+
+ssize_t __weak efi_capsule_setup_info(struct capsule_info *cap_info,
+void *kbuff, size_t hdr_bytes)
+{
+ return __efi_capsule_setup_info(cap_info, kbuff, hdr_bytes);
+}
One thing we want is to continue to have Quark work on ia32 builds
without having to compile a Quark specific kernel just to get this
feature working.
Jan I haven't had time to look at what you said about the BSP code not
working with capsules on Gen2 (I will during the week though). If you
currently have to strip the CSH to make this work then we're missing a
trick on tip-of-tree and need to sort that out for the final version of
this.
---
bod
linux-next: manual merge of the tip tree with the net-next tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/extable.c
between commit:
74451e66d516 ("bpf: make jited programs visible in traces")
from the net-next tree and commit:
5b485629ba0d ("kprobes, extable: Identify kprobes trampolines as kernel text
area")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/extable.c
index bd82117ad424,e1359474baa5..
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@@ -20,7 -20,7 +20,8 @@@
#include
#include
#include
+#include
+ #include
#include
#include
@@@ -105,8 -105,8 +106,10 @@@ int __kernel_text_address(unsigned lon
return 1;
if (is_ftrace_trampoline(addr))
return 1;
+ if (is_bpf_text_address(addr))
+ return 1;
+ if (is_kprobe_optinsn_slot(addr) || is_kprobe_insn_slot(addr))
+ return 1;
/*
* There might be init symbols in saved stacktraces.
* Give those symbols a chance to be printed in
@@@ -128,8 -128,8 +131,10 @@@ int kernel_text_address(unsigned long a
return 1;
if (is_ftrace_trampoline(addr))
return 1;
+ if (is_bpf_text_address(addr))
+ return 1;
+ if (is_kprobe_optinsn_slot(addr) || is_kprobe_insn_slot(addr))
+ return 1;
return 0;
}
Re: [PATCH] Input: tsc2007 - switch to using input_set_capability()
On Sat, Feb 18, 2017 at 03:58:39PM +0100, H. Nikolaus Schaller wrote: > Hi Dmitry, > > > Am 17.02.2017 um 23:56 schrieb Dmitry Torokhov : > > > > Do not manipulate evbit/keybit directly, use helper for that. > > > > Signed-off-by: Dmitry Torokhov > > --- > > drivers/input/touchscreen/tsc2007_core.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/input/touchscreen/tsc2007_core.c > > b/drivers/input/touchscreen/tsc2007_core.c > > index fdf81a2b989a..98dbefc3357d 100644 > > --- a/drivers/input/touchscreen/tsc2007_core.c > > +++ b/drivers/input/touchscreen/tsc2007_core.c > > @@ -364,8 +364,7 @@ static int tsc2007_probe(struct i2c_client *client, > > > > input_set_drvdata(input_dev, ts); > > > > - input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS); > > - input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH); > > + input_set_capability(input_dev, EV_KEY, BTN_TOUCH); > > basically a good improvement, but removing the BIT_MASK(EV_ABS) makes problems > when replacing the next lines > > > > > input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzx, 0); > > input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, ts->fuzzy, 0); > > by touchscreen_parse_properties() as done by my patch set. > > The problem is that touchscreen_parse_properties() does not call > input_set_abs_params() but touchscreen_set_params(). This does not > call some input_set_capability(dev, EV_ABS, axis) but rather checks > that it has been set before! Hence we only see warnings in the log and > no input event properties (BTN_TOUCH works but without position > information). Yes, the driver is supposed to set defaults, then OF data may augment them (or it may omit them and leave driver's defaults). You should not have removed calls to input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzx, 0); We may end up setting initial fuzz to 0, that's fine. Thanks. -- Dmitry
Re: [GIT PULL] Block pull request for- 4.11-rc1
On 02/19/2017 06:09 PM, Bart Van Assche wrote: > On 02/19/2017 04:11 PM, Jens Axboe wrote: >> - Removal of the BLOCK_PC support in struct request, and refactoring of >> carrying SCSI payloads in the block layer. This cleans up the code >> nicely, and enables us to kill the SCSI specific parts of struct >> request, shrinking it down nicely. From Christoph mainly, with help >> from Hannes. > > Hello Jens, Christoph and Mike, > > Is anyone working on a fix for the regression introduced by the BLOCK_PC > removal > changes (general protection fault) that I had reported three weeks ago? See > also > https://www.spinics.net/lists/raid/msg55494.html I don't think that's a regression in this series, it just triggers more easily with this series. The BLOCK_PC removal fixes aren't touching device life times at all. That said, we will look into this again, of course. Christoph, any idea? -- Jens Axboe
[PATCH -v2] ACPI, APEI: Fix BERT resources conflict with ACPI NVS area
From: Huang Ying
It was reported that on some machines, there is overlap between ACPI
NVS area and BERT address range. This appears reasonable because BERT
contents need to be non-volatile across reboot. But this will cause
resources conflict in current Linux kernel implementation because the
ACPI NVS area is marked as busy. The resource conflict is fixed via
excluding the ACPI NVS area when requesting IO resources for BERT.
When accessing the BERT contents, the whole BERT address range will be
ioremapped and accessed.
Reported-and-tested-by: Hans Kristian Rosbach
Signed-off-by: "Huang, Ying"
---
drivers/acpi/apei/bert.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/apei/bert.c b/drivers/acpi/apei/bert.c
index a05b5c0cf181..12771fcf0417 100644
--- a/drivers/acpi/apei/bert.c
+++ b/drivers/acpi/apei/bert.c
@@ -97,6 +97,7 @@ static int __init bert_check_table(struct acpi_table_bert
*bert_tab)
static int __init bert_init(void)
{
+ struct apei_resources bert_resources;
struct acpi_bert_region *boot_error_region;
struct acpi_table_bert *bert_tab;
unsigned int region_len;
@@ -127,13 +128,14 @@ static int __init bert_init(void)
}
region_len = bert_tab->region_length;
- if (!request_mem_region(bert_tab->address, region_len, "APEI BERT")) {
- pr_err("Can't request iomem region <%016llx-%016llx>.\n",
- (unsigned long long)bert_tab->address,
- (unsigned long long)bert_tab->address + region_len - 1);
- return -EIO;
- }
-
+ apei_resources_init(&bert_resources);
+ rc = apei_resources_add(&bert_resources, bert_tab->address,
+ region_len, true);
+ if (rc)
+ return rc;
+ rc = apei_resources_request(&bert_resources, "APEI BERT");
+ if (rc)
+ goto out_fini;
boot_error_region = ioremap_cache(bert_tab->address, region_len);
if (boot_error_region) {
bert_print_all(boot_error_region, region_len);
@@ -142,7 +144,9 @@ static int __init bert_init(void)
rc = -ENOMEM;
}
- release_mem_region(bert_tab->address, region_len);
+ apei_resources_release(&bert_resources);
+out_fini:
+ apei_resources_fini(&bert_resources);
return rc;
}
--
2.11.0
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
Hi Nikolaus,
On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
>
> > Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov :
> >
> > Hi Nikolaus,
> >
> > On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
> >> Hi Dmitry,
> >>
> >>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov
> >>> :
> >>>
> >>> Hi Nikolaus,
> >>>
> >>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function
> to
> parse the DT.
>
> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted /
> swapped axes")
> added another helper for parsing axis inversion and swapping
> and applying them to x and y coordinates.
>
> Both helpers have been integrated to accommodate any orientation of the
> touch panel in relation to the LCD.
>
> A new feature is to introduce scaling the min/max ADC values to the
> screen
> size.
>
> This makes it possible to pre-calibrate the touch so that is (almost)
> exactly matches the LCD pixel coordinates it is glued onto. This allows
> to
> well enough operate the touch before a user space calibration step can
> improve the precision.
> >>>
> >>> I question whether doing scaling in kernel is really right solution.
> >>
> >> Since lower left corner does not exactly report [0 0] and upper right
> >> corner
> >> does not report [4095 4095] from the ADC we need offset and steepness
> >> correction
> >> of the ADC values.
> >>
> >> This steepness is the scaling that must happen in kernel and I don't
> >> understand
> >> why you want to propagate this ADC errors to user-space by avoiding
> >> scaling.
> >>
> >> Let me iterate what we want to achieve:
> >> * use new common bindings
> >> * offset and steepness calibration of the ADC (called pre-calibration).
> >> This makes a real device much more reliable to operate with factory
> >> installed
> >> scaling factors.
> >> * flipping and rotation
> >>
> >> (note that touch pixel to LCD pixel scaling is not explicitly on this
> >> list!)
> >
> > That was explicitly called out in the patch:
> >
> > "A new feature is to introduce scaling the min/max ADC values to the
> > screen size."
>
> Because it is a feature that was not planned nor required, but is
> there. So it came into the description of what can be done. If this is
> the key problem I am happy with removing it from the commit messages.
>
> Anyways, scaling to screen coordinates is not my invention. It is
> based on
>
>
> http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>
> which defines the size to be in pixels. Well, a resistive touch screen
> does not have pixels. It might have a resolution/precision given by
> the ADC conversion steps but I assume this is not meant here.
>
> So this scaling to screen size was also stimulated by this DT
> bindings.
>
OK, now I see where you are coming from. You assume that pixels
mentioned in the DT binding are LCD pixels, however this is incorrect.
They are "pixels" or the touch controller, i.e. native unites in which
device reports coordinates, as opposed to points per inch, or
millimeters, or whatever. These "pixels" do not have to have 1:1
relation to the LCD pixels; in fact they rarely do.
Input driver may set resolution for given axis in units per mm (or units
per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and if you
check the binding, you can use "touchscreen-x-mm" and "touchscreen-y-mm"
to specify the size of entire touch surface and set resolution from it
so that userspace can calculate the proper scaling factor.
> >
> >>
> >> Now to achieve the ADC pre-calibration we must calculate
> >>
> >>x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ...
> >> 1.0
> >>
> >> This is scaled up to what is defined by touchscreen-size-x, i.e.
> >>
> >>x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
> >>
> >> How do you want to avoid this scaling to take place? It happens
> >> automatically.
> >> It is not even an additional line of code. And is necessary for
> >> compensating ADC
> >> offsets and steepness.
> >>
> >> So the only way to avoid the scaling option is to eliminate the
> >> precalibration/ADC
> >> compensation which is essential for a device which has no means to properly
> >> calibrate before operating the device through touch.
> >>
> >> The other option would be to avoid common bindings and set
> >>
> >>touchscreen-size-x = (ti,max-x-ti,min-x)
> >>
> >> This is heavily dependent on specific ADC offsets forwarded to user-space.
> >> IMHO the worst we can do (and the current tsc2007 driver does it that
> >> way!).
> >>
> >>>
> >>> Why do you want this?
> >>
> >> It seems that you a
RE: [GIT PULL] Block pull request for- 4.11-rc1
On 02/19/2017 04:11 PM, Jens Axboe wrote: > - Removal of the BLOCK_PC support in struct request, and refactoring of > carrying SCSI payloads in the block layer. This cleans up the code > nicely, and enables us to kill the SCSI specific parts of struct > request, shrinking it down nicely. From Christoph mainly, with help > from Hannes. Hello Jens, Christoph and Mike, Is anyone working on a fix for the regression introduced by the BLOCK_PC removal changes (general protection fault) that I had reported three weeks ago? See also https://www.spinics.net/lists/raid/msg55494.html Thanks, Bart.
Re: [RFC 01/13] Core changes for CCP2/CSI1 support.
Hi Pavel, As a general note, when posting a patch series, please include a cover letter and send all patches as replies to the cover letter. It gets very difficult to associate them together if you send them separately. -- Regards, Laurent Pinchart
Re: [PATCH] omap3isp: add support for CSI1 bus
Hi Pavel,
On Wednesday 15 Feb 2017 10:42:29 Pavel Machek wrote:
> Hi!
>
> >> diff --git a/drivers/media/platform/omap3isp/isp.c
> >> b/drivers/media/platform/omap3isp/isp.c index 0321d84..88bc7c6 100644
> >> --- a/drivers/media/platform/omap3isp/isp.c
> >> +++ b/drivers/media/platform/omap3isp/isp.c
> >> @@ -2024,21 +2024,92 @@ enum isp_of_phy {
> >>ISP_OF_PHY_CSIPHY2,
> >> };
> >>
> >> -static int isp_of_parse_node(struct device *dev, struct device_node
> >> *node,
> >> - struct isp_async_subdev *isd)
> >> +void __isp_of_parse_node_csi1(struct device *dev,
> >> + struct isp_ccp2_cfg *buscfg,
> >> + struct v4l2_of_endpoint *vep)
> >
> > This function isn't use anywhere else, you can merge it with
> > isp_of_parse_node_csi1().
>
> I'd prefer not to. First, it will be used separately in future, and
> second, expresions would be uglier.
Where will it be used ? As for the uglier part, I don't agree, otherwise I
wouldn't have proposed it.
> >> +{
> >> + buscfg->lanecfg.clk.pos = vep->bus.mipi_csi1.clock_lane;
> >> + buscfg->lanecfg.clk.pol =
> >> + vep->bus.mipi_csi1.lane_polarity[0];
> >> + dev_dbg(dev, "clock lane polarity %u, pos %u\n",
> >> + buscfg->lanecfg.clk.pol,
> >> + buscfg->lanecfg.clk.pos);
> >> +
> >> + buscfg->lanecfg.data[0].pos = vep->bus.mipi_csi2.data_lanes[0];
> >> + buscfg->lanecfg.data[0].pol =
> >> + vep->bus.mipi_csi2.lane_polarities[1];
> >
> > bus.mipi_csi2 ?
>
> Good catch. Fixed.
>
> >> - ret = v4l2_of_parse_endpoint(node, &vep);
> >> - if (ret)
> >> - return ret;
> >> + if (vep->base.port == ISP_OF_PHY_CSIPHY1)
> >> + buscfg->interface = ISP_INTERFACE_CSI2C_PHY1;
> >> + else
> >> + buscfg->interface = ISP_INTERFACE_CSI2A_PHY2;
> >
> > I would keep this code in the caller to avoid code duplication with
> > isp_of_parse_node_csi1().
>
> Take a closer look. Code in _csi1 is different.
>
> >>break;
> >>
> >>default:
> >> + return -1;
> >
> > Please use the appropriate error code.
>
> Ok.
>
> >> + return 0;
> >> +}
> >> +
> >> +static int isp_of_parse_node_endpoint(struct device *dev,
> >> +struct device_node *node,
> >> +struct isp_async_subdev *isd)
> >> +{
> >> + struct isp_bus_cfg *buscfg;
> >> + struct v4l2_of_endpoint vep;
> >> + int ret;
> >> +
> >> + isd->bus = devm_kzalloc(dev, sizeof(*isd->bus), GFP_KERNEL);
> >
> > Why do you now need to allocate this manually ?
>
> bus is now a pointer.
I've seen that, but why have you changed it ?
> >> + dev_dbg(dev, "parsing endpoint %s, interface %u\n", node->full_name,
> >> + vep.base.port);
> >> +
> >> + if (isp_endpoint_to_buscfg(dev, vep, buscfg))
> >
> > I'm fine splitting the CSI1/CSI2 parsing code to separate functions, but I
> > don't think there's a need to split isp_endpoint_to_buscfg(). You can keep
> > that part inline.
>
> I'd prefer smaller functions here. I tried to read the original and it
> was not too easy.
This function became a kzalloc (which I still don't see why you need it), a
call to v4l2_of_parse_endpoint(), and then isp_endpoint_to_buscfg(). That's
too small to be a function of its own. Please merge
isp_of_parse_node_endpoint() and isp_endpoint_to_buscfg().
> >> diff --git a/drivers/media/platform/omap3isp/ispccp2.c
> >> b/drivers/media/platform/omap3isp/ispccp2.c index ca09523..4edb55a
> >> 100644
> >> --- a/drivers/media/platform/omap3isp/ispccp2.c
> >> +++ b/drivers/media/platform/omap3isp/ispccp2.c
> >> @@ -160,6 +163,33 @@ static int ccp2_if_enable(struct isp_ccp2_device
> >> *ccp2, u8 enable) return ret;
> >>
> >>}
> >>
> >> + if (isp->revision == ISP_REVISION_2_0) {
> >
> > The isp_csiphy.c code checks phy->isp->phy_type for the same purpose,
> > shouldn't you use that too ?
>
> Do you want me to do phy->isp->phy_type == ISP_PHY_TYPE_3430 check
> here? Can do...
Yes that's what I meant.
> >> + buscfg = &((struct isp_bus_cfg *)sensor->host_priv)->bus.ccp2;
> >> +
> >> +
> >
> > One blank line is enough.
>
> Ok.
>
> >> + if (enable) {
> >> + csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ |
> >> +OMAP343X_CONTROL_CSIRXFE_RESET;
> >> +
> >> + if (buscfg->phy_layer)
> >> + csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
> >> +
> >> + if (buscfg->strobe_clk_pol)
> >> + csirxfe |= OMAP343X_CONTROL_CSIRXFE_CSIB_INV;
> >> + } else
> >> + csirxfe = 0;
> >
> > You need curly braces for the else statement too.
>
> Easy enough.
>
> >> +
> >> + regmap_write(isp->syscon, isp->syscon_offset, csirxfe);
> >
> > Isn't this already configured by csiphy_routing_cfg_3430(), called through
> > omap3isp_csiphy_acquire() ? You'll need to add support for the
Re: [PATCH] ACPI, APEI: Fix BERT resources conflict with ACPI NVS area
Borislav Petkov writes: > On Fri, Feb 17, 2017 at 08:31:12AM +0800, Huang, Ying wrote: >> I am not sure whether the NVS area is a part of the BERT area, but >> apparently they are overlapped in some way. We will access the whole >> BERT area here via ioremap the whole range. > > This is the part that was missing from the commit message - explaining > *why* we need this fix. OK. I will revise the patch description accordingly. Best Regards, Huang, Ying
Re: [PATCH net-next] virito-net: set queues after reset during xdp_set
On Fri, Feb 17, 2017 at 03:30:51PM -0800, John Fastabend wrote:
> On 17-02-16 09:10 PM, Jason Wang wrote:
> >
> >
> > On 2017年02月17日 12:53, John Fastabend wrote:
> >> On 17-02-15 01:08 AM, Jason Wang wrote:
> >>> We set queues before reset which will cause a crash[1]. This is
> >>> because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs
> >>> number to do the correct detection. So fix this by:
> >>>
> >>> - set queues after reset, to keep the old vi->curr_queue_pairs. (in
> >>>fact setting queues before reset does not works since after feature
> >>>set, all queue pairs were enabled by default during reset).
> >>> - change xdp_queue_pairs only after virtnet_reset() is succeed.
> >>>
> >>> [1]
> >> I'm guessing this occurs when enabling XDP while receiving lots of traffic?
> >
> > I hit this then disabling XDP while receiving lots of traffic.
> >
>
> [...]
>
> >>> +vi->xdp_queue_pairs = xdp_qp;
> >> But xdp_queue_pairs is being used to detect if we should allocate the XDP
> >> headroom. If we move it here do we have a set of buffers in the ring
> >> without
> >> the proper headroom when we assign the xdp program below?
> >
> > Right, so how about passing xdp_queue_pairs as a parameter to
> > virtnet_reset().
> > Then virtnet_reset() can set it after _remove_vq_common() but before
> > virtnet_restore_up()?
> >
> > Thanks
> >
>
> Sounds like a reasonable fix to me.
I'm fine with that.
> >>
> >>> +}
> >>> +
> >>> +err = _virtnet_set_queues(vi, curr_qp + xdp_qp);
> >>> +if (err) {
> >>> +dev_warn(&dev->dev, "XDP Device queue allocation failure.\n");
> >>> +goto virtio_queue_err;
> >>> }
> >>> netif_set_real_num_rx_queues(dev, curr_qp + xdp_qp);
> >>> @@ -1844,17 +1844,18 @@ static int virtnet_xdp_set(struct net_device *dev,
> >>> struct bpf_prog *prog)
> >>> return 0;
> >> Thanks,
> >> John
> >>
> >
[GIT PULL] Block pull request for- 4.11-rc1
Hi Linus, This is the collected pull request for 4.11 for the block core and drivers. It's really two different branches: for-4.11/block-signed for-4.11/next-signed for-4.11/next exists because some of Christoph's patch series were based on patches that were added after for-4.11/block was forked off, which would have caused needless merge pain. So for-4.11/next was forked off v4.10-rc5, with for-4.11/block pulled in. Feel free to pull each of these in succession instead of this pre-merged branch. Note that if you do opt for pulling the two branches, for-4.11/block will throw a trivial merge conflict in block/blk-mq.c, where you need to delete a function. for-4.11/next merges cleanly, HOWEVER, a commit that was added in mainline since v4.10-rc5 (f2e767bb5d6e) adds a line of code that is no longer valid with the changes in for-4.11/next. Hence, if you do pull in separately, you'll want to --no-commit and edit: drivers/scsi/mpt3sas/mpt3sas_scsih.c to fix up that one line, like I did in the for-4.11/linus-merge branch. With that said, this pull request contains: - blk-mq scheduling framework from me and Omar, with a port of the deadline scheduler for this framework. A port of BFQ from Paolo is in the works, and should be ready for 4.12. - Various fixups and improvements to the above scheduling framework from Omar, Paolo, Bart, me, others. - Cleanup of the exported sysfs blk-mq data into debugfs, from Omar. This allows us to export more information that helps debug hangs or performance issues, without cluttering or abusing the sysfs API. - Fixes for the sbitmap code, the scalable bitmap code that was migrated from blk-mq, from Omar. - Removal of the BLOCK_PC support in struct request, and refactoring of carrying SCSI payloads in the block layer. This cleans up the code nicely, and enables us to kill the SCSI specific parts of struct request, shrinking it down nicely. From Christoph mainly, with help from Hannes. - Support for ranged discard requests and discard merging, also from Christoph. - Support for OPAL in the block layer, and for NVMe as well. Mainly from Scott Bauer, with fixes/updates from various others folks. - Error code fixup for gdrom from Christophe. - cciss pci irq allocation cleanup from Christoph. - Making the cdrom device operations read only, from Kees Cook. - Fixes for duplicate bdi registrations and bdi/queue life time problems from Jan and Dan. - Set of fixes and updates for lightnvm, from Matias and Javier. - A few fixes for nbd from Josef, using idr to name devices and a workqueue deadlock fix on receive. Also marks Josef as the current maintainer of nbd. - Fix from Josef, overwriting queue settings when the number of hardware queues is updated for a blk-mq device. - NVMe fix from Keith, ensuring that we don't repeatedly mark and IO aborted, if we didn't end up aborting it. - SG gap merging fix from Ming Lei for block. - Loop fix also from Ming, fixing a race and crash between setting loop status and IO. - Two block race fixes from Tahsin, fixing request list iteration and fixing a race between device registration and udev device add notifiations. - Double free fix from cgroup writeback, from Tejun. - Another double free fix in blkcg, from Hou Tao. - Partition overflow fix for EFI from Alden Tondettar. Please pull! Either this pre-merged branch: git://git.kernel.dk/linux-block.git for-4.11/linus-merge-signed or git://git.kernel.dk/linux-block.git for-4.11/block-signed git://git.kernel.dk/linux-block.git for-4.11/next-signed in that order. All branches are signed tags. Alden Tondettar (1): partitions/efi: Fix integer overflow in GPT size calculation Alexander Potapenko (1): block: Initialize cfqq->ioprio_class in cfq_get_queue() Bart Van Assche (5): blk-mq-debugfs: Add missing __acquires() / __releases() annotations blk-mq-debug: Avoid that sparse complains about req_flags_t usage blk-mq-debug: Make show() operations interruptible blk-mq-debug: Introduce debugfs_create_files() block: Update comments that refer to __bio_map_user() and bio_map_user() Christoph Hellwig (39): block: add a op_is_flush helper md: cleanup bio op / flags handling in raid1_write_request block: fix elevator init check block: simplify blk_init_allocated_queue block: allow specifying size for extra command data block: cleanup tracing dm: remove incomplete BLOCK_PC support dm: always defer request allocation to the owner of the request_queue scsi: remove gfp_flags member in scsi_host_cmd_pool scsi: respect unchecked_isa_dma for blk-mq scsi: remove scsi_cmd_dma_pool scsi: remove __scsi_alloc_queue scsi: allocate scsi_cmnd structures as part of struct request block/bsg: move queue creation into bsg_setup_queue blo
linux-next: manual merge of the kspp tree with the net-next tree
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
include/linux/filter.h
between commit:
74451e66d516 ("bpf: make jited programs visible in traces")
from the net-next tree and commit:
0f5bf6d0afe4 ("arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX")
from the kspp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/filter.h
index 0c1cc9143cb2,c6dd53e88711..
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@@ -574,21 -561,8 +574,21 @@@ static inline void bpf_prog_lock_ro(str
static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
{
}
+
+static inline void bpf_jit_binary_unlock_ro(struct bpf_binary_header *hdr)
+{
+}
- #endif /* CONFIG_DEBUG_SET_MODULE_RONX */
+ #endif /* CONFIG_STRICT_MODULE_RWX */
+static inline struct bpf_binary_header *
+bpf_jit_binary_hdr(const struct bpf_prog *fp)
+{
+ unsigned long real_start = (unsigned long)fp->bpf_func;
+ unsigned long addr = real_start & PAGE_MASK;
+
+ return (void *)addr;
+}
+
int sk_filter_trim_cap(struct sock *sk, struct sk_buff *skb, unsigned int
cap);
static inline int sk_filter(struct sock *sk, struct sk_buff *skb)
{
Re: [PATCH v2 2/3] watchdog: sama5d4: Fix setting timeout when watchdog is disabled
On 19/02/2017 at 08:57:35 -0800, Guenter Roeck wrote: > > > That means if the watchdog is running, the timeout would not be updated. > > > It should be updated no matter if it is running or not. > > > > > > > No, it is enabling the watchdog, then changing WDV and WDD and finally > > disabling the watchdog if necessary. So, WDV and WDD are always changed. > > > You are correct. Sorry for the noise. > > Seems odd that the watchdog must be _running_ to change the timeout. > Usually, if there is a restriction, it is the opposite. I hope this > doesn't cause race conditions, where the watchdog fires immediately > after being enabled due to a low timeout. > While it is difficult to reproduce, I can confirm it races and sometimes reset the SoC without any good reason. It doesn't matter whether it is disabled or not I've raised the issue at Atmel last Thursday so I don't have any answer yet. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
linux-next: build warnings after merge of the drm tree
Hi Dave,
After merging the drm tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:
drivers/gpu/drm/sti/sti_vtg.c: In function 'vtg_probe':
drivers/gpu/drm/sti/sti_vtg.c:392:22: warning: unused variable 'np'
[-Wunused-variable]
struct device_node *np;
^
Introduced by commit
0c7ff84f7f9d ("drm/sti: remove deprecated legacy vtg slave")
drivers/gpu/drm/sti/sti_drv.c:120:13: warning: 'sti_drm_dbg_cleanup' defined
but not used [-Wunused-function]
static void sti_drm_dbg_cleanup(struct drm_minor *minor)
^
Introduced by commit
5e60f595d6ca ("drm/sti: use atomic_helper for commit")
[BTW, this latter commit has no Signed-off-by from its committer :-(]
--
Cheers,
Stephen Rothwell
Re: linux-next: error fetching the ipmi tree
Hi Corey, On Sun, 19 Feb 2017 16:26:18 -0600 Corey Minyard wrote: > > Dang, I was hoping SourceForge had cleaned up their act. I can ask for > an account on > kernel.org, but I'm not sure I will be able to get one. Yeah, you need a well signed GPG key ... > I'm in the process of moving userland things I support to github, which > seems more > stable than SourceForge. Would that be better? Probably better than SourceForge :-) Keep in mind that Linus requires signed tags for pulls from basically anywhere besides kernel.org. -- Cheers, Stephen Rothwell
