* [PATCH v3 05/15] ARM: dts: dra76x-mmc-iodelay: Add a new pinctrl group for clk line without pullup
From: Kishon Vijay Abraham I @ 2018-04-25 12:54 UTC (permalink / raw)
To: Benoît Cousson , Tony Lindgren
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, linux-doc, kishon,
linux-mmc, devicetree, linux-kernel, linux-omap
In-Reply-To: <20180425125449.19755-1-kishon@ti.com>
During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.
According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Physical Layer Specification Version 5.00 February 22, 2016", the
host should hold CLK line low for at least 5ms.
In order to keep the card line low during voltage switch, the pad mux of
mmc1_clk line should be configured to pull down.
Add a new pinctrl group for clock line without pullup to be used in boards
where mmc1_clk line is not connected to an external pullup.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi b/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi
index baba7b00eca7..b6327220a88e 100644
--- a/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi
+++ b/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi
@@ -38,6 +38,17 @@
>;
};
+ mmc1_pins_default_no_clk_pu: mmc1_pins_default_no_clk_pu {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
mmc1_pins_hs: mmc1_pins_hs {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_clk.clk */
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 09/15] ARM: dts: dra72-evm-common: Add wilink8 wlan support
From: Kishon Vijay Abraham I @ 2018-04-25 12:54 UTC (permalink / raw)
To: Benoît Cousson , Tony Lindgren
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, linux-doc, kishon,
linux-mmc, devicetree, linux-kernel, linux-omap, Hari Nagalla,
Eyal Reizer, Sekhar Nori
In-Reply-To: <20180425125449.19755-1-kishon@ti.com>
From: Hari Nagalla <hnagalla@ti.com>
Wilink8 module is a combo wireless connectivity card based
on Texas Instrument's wl18xx solution.
Add support for the wlan capabilities of this module by muxing
the relevant mmc lines, and setting the required device-tree
data.
Signed-off-by: Eyal Reizer <eyalr@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
[nsekhar@ti.com: drop WLAN_EN pinmux. It should be done by bootloader.
Also, some commit message adjustments]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra72-evm-common.dtsi | 42 +++++++++++++++++++++++
arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi | 11 ++++++
2 files changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index 8e3b185d864b..1e4d36e33a1b 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -44,6 +44,16 @@
regulator-boot-on;
};
+ evm_3v6: fixedregulator-evm_3v6 {
+ compatible = "regulator-fixed";
+ regulator-name = "evm_3v6";
+ regulator-min-microvolt = <3600000>;
+ regulator-max-microvolt = <3600000>;
+ vin-supply = <&evm_5v0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
vsys_3v3: fixedregulator-vsys3v3 {
/* Output 2 of TPS43351QDAPRQ1 on dra72-evm */
/* Output 2 of LM5140QRWGTQ1 on dra71-evm */
@@ -171,6 +181,15 @@
clocks = <&atl_clkin2_ck>;
};
};
+
+ vmmcwl_fixed: fixedregulator-mmcwl {
+ compatible = "regulator-fixed";
+ regulator-name = "vmmcwl_fixed";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio5 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
&dra7_pmx_core {
@@ -398,6 +417,29 @@
max-frequency = <192000000>;
};
+&mmc4 {
+ status = "okay";
+ vmmc-supply = <&evm_3v6>;
+ vqmmc-supply = <&vmmcwl_fixed>;
+ bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ non-removable;
+ pinctrl-names = "default", "hs", "sdr12", "sdr25";
+ pinctrl-0 = <&mmc4_pins_default>;
+ pinctrl-1 = <&mmc4_pins_default>;
+ pinctrl-2 = <&mmc4_pins_default>;
+ pinctrl-3 = <&mmc4_pins_default>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ wlcore: wlcore@2 {
+ compatible = "ti,wl1835";
+ reg = <2>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ };
+};
+
&mac {
status = "okay";
};
diff --git a/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi b/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
index c9351eaf97f0..4cf5482fbc33 100644
--- a/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
+++ b/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
@@ -213,6 +213,17 @@
DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a22.mmc2_dat7 */
>;
};
+
+ mmc4_pins_default: mmc4_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x37e8, PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_ctsn.mmc4_clk */
+ DRA7XX_CORE_IOPAD(0x37ec, PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_rtsn.mmc4_cmd */
+ DRA7XX_CORE_IOPAD(0x37f0, PIN_INPUT_PULLUP | MUX_MODE3) /* uart2_rxd.mmc4_dat0 */
+ DRA7XX_CORE_IOPAD(0x37f4, PIN_INPUT_PULLUP | MUX_MODE3) /* uart2_txd.mmc4_dat1 */
+ DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_PULLUP | MUX_MODE3) /* uart2_ctsn.mmc4_dat2 */
+ DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_PULLUP | MUX_MODE3) /* uart2_rtsn.mmc4_dat3 */
+ >;
+ };
};
&dra7_iodelay_core {
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 04/15] ARM: dts: dra74x-mmc-iodelay: Add a new pinctrl group for clk line without pullup
From: Kishon Vijay Abraham I @ 2018-04-25 12:54 UTC (permalink / raw)
To: Benoît Cousson , Tony Lindgren
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, linux-doc, kishon,
linux-mmc, devicetree, linux-kernel, linux-omap
In-Reply-To: <20180425125449.19755-1-kishon@ti.com>
During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.
According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Physical Layer Specification Version 5.00 February 22, 2016", the
host should hold CLK line low for at least 5ms.
In order to keep the card line low during voltage switch, the pad mux of
mmc1_clk line should be configured to pull down.
Add a new pinctrl group for clock line without pullup to be used in boards
where mmc1_clk line is not connected to an external pullup.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
index 28ebb4eb884a..30af5a03a852 100644
--- a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
+++ b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
@@ -49,6 +49,17 @@
>;
};
+ mmc1_pins_default_no_clk_pu: mmc1_pins_default_no_clk_pu {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
mmc1_pins_sdr12: mmc1_pins_sdr12 {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v1 1/1] misc: IBM Virtual Management Channel Driver
From: kbuild test robot @ 2018-04-25 12:00 UTC (permalink / raw)
To: Bryant G. Ly
Cc: kbuild-all, benh, mpe, gregkh, arnd, mikey, rdunlap, tlfalcon,
corbet, linus.walleij, mrochs, linux-doc, fbarrat, adreznec,
Bryant G. Ly, pombredanne, akpm, msuchanek, linuxppc-dev, davem,
seroyer
In-Reply-To: <1524494812-60150-2-git-send-email-bryantly@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3969 bytes --]
Hi Bryant,
I love your patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on v4.17-rc2 next-20180424]
[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/Bryant-G-Ly/misc-IBM-Virtual-Management-Channel-Driver/20180424-060306
config: powerpc64-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers//misc/ibmvmc.c: In function 'ibmvmc_probe':
>> drivers//misc/ibmvmc.c:2133:5: warning: 'rc' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (rc == H_RESOURCE)
^
drivers//misc/ibmvmc.c:2111:6: note: 'rc' was declared here
int rc;
^~
vim +/rc +2133 drivers//misc/ibmvmc.c
2097
2098 /**
2099 * ibmvmc_init_crq_queue - Init CRQ Queue
2100 *
2101 * @adapter: crq_server_adapter struct
2102 *
2103 * Return:
2104 * 0 - Success
2105 * Non-zero - Failure
2106 */
2107 static int ibmvmc_init_crq_queue(struct crq_server_adapter *adapter)
2108 {
2109 struct vio_dev *vdev = to_vio_dev(adapter->dev);
2110 struct crq_queue *queue = &adapter->queue;
2111 int rc;
2112 int retrc;
2113
2114 queue->msgs = (struct ibmvmc_crq_msg *)get_zeroed_page(GFP_KERNEL);
2115
2116 if (!queue->msgs)
2117 goto malloc_failed;
2118
2119 queue->size = PAGE_SIZE / sizeof(*queue->msgs);
2120
2121 queue->msg_token = dma_map_single(adapter->dev, queue->msgs,
2122 queue->size * sizeof(*queue->msgs),
2123 DMA_BIDIRECTIONAL);
2124
2125 if (dma_mapping_error(adapter->dev, queue->msg_token))
2126 goto map_failed;
2127
2128 retrc = plpar_hcall_norets(H_REG_CRQ,
2129 vdev->unit_address,
2130 queue->msg_token, PAGE_SIZE);
2131 retrc = rc;
2132
> 2133 if (rc == H_RESOURCE)
2134 rc = ibmvmc_reset_crq_queue(adapter);
2135
2136 if (rc == 2) {
2137 dev_warn(adapter->dev, "Partner adapter not ready\n");
2138 retrc = 0;
2139 } else if (rc != 0) {
2140 dev_err(adapter->dev, "Error %d opening adapter\n", rc);
2141 goto reg_crq_failed;
2142 }
2143
2144 queue->cur = 0;
2145 spin_lock_init(&queue->lock);
2146
2147 tasklet_init(&adapter->work_task, ibmvmc_task, (unsigned long)adapter);
2148
2149 if (request_irq(vdev->irq,
2150 ibmvmc_handle_event,
2151 0, "ibmvmc", (void *)adapter) != 0) {
2152 dev_err(adapter->dev, "couldn't register irq 0x%x\n",
2153 vdev->irq);
2154 goto req_irq_failed;
2155 }
2156
2157 rc = vio_enable_interrupts(vdev);
2158 if (rc != 0) {
2159 dev_err(adapter->dev, "Error %d enabling interrupts!!!\n", rc);
2160 goto req_irq_failed;
2161 }
2162
2163 return retrc;
2164
2165 req_irq_failed:
2166 /* Cannot have any work since we either never got our IRQ registered,
2167 * or never got interrupts enabled
2168 */
2169 tasklet_kill(&adapter->work_task);
2170 h_free_crq(vdev->unit_address);
2171 reg_crq_failed:
2172 dma_unmap_single(adapter->dev,
2173 queue->msg_token,
2174 queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL);
2175 map_failed:
2176 free_page((unsigned long)queue->msgs);
2177 malloc_failed:
2178 return -ENOMEM;
2179 }
2180
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56234 bytes --]
^ permalink raw reply
* [PATCH] PM: docs: sleep-states: Fix a typo ("includig")
From: Jonathan Neuschäfer @ 2018-04-25 10:07 UTC (permalink / raw)
To: linux-kernel
Cc: linux-pm, Jonathan Neuschäfer, Jonathan Corbet, Lukas Wunner,
Rafael J. Wysocki, linux-doc
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/admin-guide/pm/sleep-states.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/pm/sleep-states.rst b/Documentation/admin-guide/pm/sleep-states.rst
index 1e5c0f00cb2f..dbf5acd49f35 100644
--- a/Documentation/admin-guide/pm/sleep-states.rst
+++ b/Documentation/admin-guide/pm/sleep-states.rst
@@ -15,7 +15,7 @@ Sleep States That Can Be Supported
==================================
Depending on its configuration and the capabilities of the platform it runs on,
-the Linux kernel can support up to four system sleep states, includig
+the Linux kernel can support up to four system sleep states, including
hibernation and up to three variants of system suspend. The sleep states that
can be supported by the kernel are listed below.
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/2] perf: uncore: Adding documentation for ThunderX2 pmu uncore driver
From: Ganapatrao Kulkarni @ 2018-04-25 9:00 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-arm-kernel
Cc: Will.Deacon, mark.rutland, jnair, Robert.Richter, Vadim.Lomovtsev,
Jan.Glauber, gklkml16
In-Reply-To: <20180425090047.6485-1-ganapatrao.kulkarni@cavium.com>
Documentation for the UNCORE PMUs on Cavium's ThunderX2 SoC.
The SoC has PMU support in its L3 cache controller (L3C) and in the
DDR4 Memory Controller (DMC).
Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
---
Documentation/perf/thunderx2-pmu.txt | 66 ++++++++++++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
create mode 100644 Documentation/perf/thunderx2-pmu.txt
diff --git a/Documentation/perf/thunderx2-pmu.txt b/Documentation/perf/thunderx2-pmu.txt
new file mode 100644
index 0000000..9e9f535
--- /dev/null
+++ b/Documentation/perf/thunderx2-pmu.txt
@@ -0,0 +1,66 @@
+
+Cavium ThunderX2 SoC Performance Monitoring Unit (PMU UNCORE)
+==========================================================================
+
+ThunderX2 SoC PMU consists of independent system wide per Socket PMUs such
+as Level 3 Cache(L3C) and DDR4 Memory Controller(DMC).
+
+It has 8 independent DMC PMUs to capture performance events corresponding
+to 8 channels of DDR4 Memory Controller. There are 16 independent L3C PMUs
+to capture events corresponding to 16 tiles of L3 cache. Each PMU supports
+up to 4 counters.
+
+Counters are independent programmable and can be started and stopped
+individually. Each counter can be set to sample specific perf events.
+Counters are 32 bit and does not support overflow interrupt, they are
+sampled at every 2 seconds. The Counters register access are multiplexed
+across channels of DMC and L3C. The muxing(select channel) is done through
+write to a Secure register using smcc calls.
+
+PMU UNCORE (perf) driver:
+
+The thunderx2-pmu driver registers several perf PMUs for DMC and L3C devices.
+Each of the PMU provides description of its available events
+and configuration options in sysfs.
+ see /sys/devices/uncore_<l3c_S_X/dmc_S_X/>
+
+S is socket id and X represents channel number.
+Each PMU can be used to sample up to 4 events simultaneously.
+
+The "format" directory describes format of the config (event ID).
+The "events" directory provides configuration templates for all
+supported event types that can be used with perf tool.
+
+For example, "uncore_dmc_0_0/cnt_cycles/" is an
+equivalent of "uncore_dmc_0_0/config=0x1/".
+
+Each perf driver also provides a "cpumask" sysfs attribute, which contains a
+single CPU ID of the processor which is likely to be used to handle all the
+PMU events. It will be the first online CPU from the NUMA node of PMU device.
+
+Example for perf tool use:
+
+perf stat -a -e \
+uncore_dmc_0_0/cnt_cycles/,\
+uncore_dmc_0_1/cnt_cycles/,\
+uncore_dmc_0_2/cnt_cycles/,\
+uncore_dmc_0_3/cnt_cycles/,\
+uncore_dmc_0_4/cnt_cycles/,\
+uncore_dmc_0_5/cnt_cycles/,\
+uncore_dmc_0_6/cnt_cycles/,\
+uncore_dmc_0_7/cnt_cycles/ sleep 1
+
+perf stat -a -e \
+uncore_dmc_0_0/cancelled_read_txns/,\
+uncore_dmc_0_0/cnt_cycles/,\
+uncore_dmc_0_0/consumed_read_txns/,\
+uncore_dmc_0_0/data_transfers/ sleep 1
+
+perf stat -a -e \
+uncore_l3c_0_0/l3_retry/,\
+uncore_l3c_0_0/read_hit/,\
+uncore_l3c_0_0/read_request/,\
+uncore_l3c_0_0/inv_request/ sleep 1
+
+The driver does not support sampling, therefore "perf record" will
+not work. Per-task (without "-a") perf sessions are not supported.
--
2.9.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver
From: Ganapatrao Kulkarni @ 2018-04-25 9:00 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-arm-kernel
Cc: Will.Deacon, mark.rutland, jnair, Robert.Richter, Vadim.Lomovtsev,
Jan.Glauber, gklkml16
In-Reply-To: <20180425090047.6485-1-ganapatrao.kulkarni@cavium.com>
This patch adds a perf driver for the PMU UNCORE devices DDR4 Memory
Controller(DMC) and Level 3 Cache(L3C).
ThunderX2 has 8 independent DMC PMUs to capture performance events
corresponding to 8 channels of DDR4 Memory Controller and 16 independent
L3C PMUs to capture events corresponding to 16 tiles of L3 cache.
Each PMU supports up to 4 counters. All counters lack overflow interrupt
and are sampled periodically.
Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
---
drivers/perf/Kconfig | 8 +
drivers/perf/Makefile | 1 +
drivers/perf/thunderx2_pmu.c | 958 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 967 insertions(+)
create mode 100644 drivers/perf/thunderx2_pmu.c
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 28bb5a0..eafd0fc 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -85,6 +85,14 @@ config QCOM_L3_PMU
Adds the L3 cache PMU into the perf events subsystem for
monitoring L3 cache events.
+config THUNDERX2_PMU
+ bool "Cavium ThunderX2 SoC PMU UNCORE"
+ depends on ARCH_THUNDER2 && PERF_EVENTS && ACPI
+ help
+ Provides support for ThunderX2 UNCORE events.
+ The SoC has PMU support in its L3 cache controller (L3C) and
+ in the DDR4 Memory Controller (DMC).
+
config XGENE_PMU
depends on ARCH_XGENE
bool "APM X-Gene SoC PMU"
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index b3902bd..909f27f 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
obj-$(CONFIG_HISI_PMU) += hisilicon/
obj-$(CONFIG_QCOM_L2_PMU) += qcom_l2_pmu.o
obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
+obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
new file mode 100644
index 0000000..92d19b5
--- /dev/null
+++ b/drivers/perf/thunderx2_pmu.c
@@ -0,0 +1,958 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * CAVIUM THUNDERX2 SoC PMU UNCORE
+ *
+ * Copyright (C) 2018 Cavium Inc.
+ * Author: Ganapatrao Kulkarni <gkulkarni@cavium.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/acpi.h>
+#include <linux/arm-smccc.h>
+#include <linux/perf_event.h>
+#include <linux/platform_device.h>
+
+/* L3c and DMC has 16 and 8 channels per socket respectively.
+ * Each Channel supports UNCORE PMU device and consists of
+ * 4 independent programmable counters. Counters are 32 bit
+ * and does not support overflow interrupt, they needs to be
+ * sampled before overflow(i.e, at every 2 seconds).
+ */
+
+#define UNCORE_MAX_COUNTERS 4
+#define UNCORE_L3_MAX_TILES 16
+#define UNCORE_DMC_MAX_CHANNELS 8
+
+#define UNCORE_HRTIMER_INTERVAL (2 * NSEC_PER_SEC)
+#define GET_EVENTID(ev) ((ev->hw.config) & 0x1ff)
+#define GET_COUNTERID(ev) ((ev->hw.idx) & 0xf)
+#define GET_CHANNELID(pmu_uncore) (pmu_uncore->channel)
+
+#define DMC_COUNTER_CTL 0x234
+#define DMC_COUNTER_DATA 0x240
+#define L3C_COUNTER_CTL 0xA8
+#define L3C_COUNTER_DATA 0xAC
+
+#define THUNDERX2_SMC_CALL_ID 0xC200FF00
+#define THUNDERX2_SMC_SET_CHANNEL 0xB010
+
+
+enum thunderx2_uncore_l3_events {
+ L3_EVENT_NONE,
+ L3_EVENT_NBU_CANCEL,
+ L3_EVENT_DIB_RETRY,
+ L3_EVENT_DOB_RETRY,
+ L3_EVENT_DIB_CREDIT_RETRY,
+ L3_EVENT_DOB_CREDIT_RETRY,
+ L3_EVENT_FORCE_RETRY,
+ L3_EVENT_IDX_CONFLICT_RETRY,
+ L3_EVENT_EVICT_CONFLICT_RETRY,
+ L3_EVENT_BANK_CONFLICT_RETRY,
+ L3_EVENT_FILL_ENTRY_RETRY,
+ L3_EVENT_EVICT_NOT_READY_RETRY,
+ L3_EVENT_L3_RETRY,
+ L3_EVENT_READ_REQ,
+ L3_EVENT_WRITE_BACK_REQ,
+ L3_EVENT_INVALIDATE_NWRITE_REQ,
+ L3_EVENT_INV_REQ,
+ L3_EVENT_SELF_REQ,
+ L3_EVENT_REQ,
+ L3_EVENT_EVICT_REQ,
+ L3_EVENT_INVALIDATE_NWRITE_HIT,
+ L3_EVENT_INVALIDATE_HIT,
+ L3_EVENT_SELF_HIT,
+ L3_EVENT_READ_HIT,
+ L3_EVENT_MAX,
+};
+
+enum thunderx2_uncore_dmc_events {
+ DMC_EVENT_NONE,
+ DMC_EVENT_COUNT_CYCLES,
+ DMC_EVENT_RES2,
+ DMC_EVENT_RES3,
+ DMC_EVENT_RES4,
+ DMC_EVENT_RES5,
+ DMC_EVENT_RES6,
+ DMC_EVENT_RES7,
+ DMC_EVENT_RES8,
+ DMC_EVENT_READ_64B_TXNS,
+ DMC_EVENT_READ_BELOW_64B_TXNS,
+ DMC_EVENT_WRITE_TXNS,
+ DMC_EVENT_TXN_CYCLES,
+ DMC_EVENT_DATA_TRANSFERS,
+ DMC_EVENT_CANCELLED_READ_TXNS,
+ DMC_EVENT_CONSUMED_READ_TXNS,
+ DMC_EVENT_MAX,
+};
+
+enum thunderx2_uncore_type {
+ PMU_TYPE_L3C,
+ PMU_TYPE_DMC,
+ PMU_TYPE_INVALID,
+};
+
+struct active_timer {
+ struct perf_event *event;
+ struct hrtimer hrtimer;
+};
+
+/*
+ * pmu on each socket has 2 uncore devices(dmc and l3),
+ * each uncore device has up to 16 channels, each channel can sample
+ * events independently with counters up to 4.
+ *
+ * struct thunderx2_pmu_uncore_channel created per channel.
+ * struct thunderx2_pmu_uncore_dev per uncore device.
+ */
+struct thunderx2_pmu_uncore_channel {
+ struct thunderx2_pmu_uncore_dev *uncore_dev;
+ struct pmu pmu;
+ int counter;
+ int channel;
+ DECLARE_BITMAP(counter_mask, UNCORE_MAX_COUNTERS);
+ struct active_timer *active_timers;
+ /* to sync counter alloc/release */
+ raw_spinlock_t lock;
+};
+
+struct thunderx2_pmu_uncore_dev {
+ char *name;
+ struct device *dev;
+ enum thunderx2_uncore_type type;
+ unsigned long base;
+ int node;
+ u32 max_counters;
+ u32 max_channels;
+ u32 max_events;
+ u64 hrtimer_interval;
+ /* this lock synchronizes across channels */
+ raw_spinlock_t lock;
+ const struct attribute_group **attr_groups;
+ void (*init_cntr_base)(struct perf_event *event,
+ struct thunderx2_pmu_uncore_dev *uncore_dev);
+ void (*select_channel)(struct perf_event *event);
+ void (*stop_event)(struct perf_event *event);
+ void (*start_event)(struct perf_event *event, int flags);
+};
+
+static inline struct thunderx2_pmu_uncore_channel *
+pmu_to_thunderx2_pmu_uncore(struct pmu *pmu)
+{
+ return container_of(pmu, struct thunderx2_pmu_uncore_channel, pmu);
+}
+
+/*
+ * sysfs format attributes
+ */
+static ssize_t thunderx2_pmu_format_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_ext_attribute *eattr;
+
+ eattr = container_of(attr, struct dev_ext_attribute, attr);
+ return sprintf(buf, "%s\n", (char *) eattr->var);
+}
+
+#define FORMAT_ATTR(_name, _config) \
+ (&((struct dev_ext_attribute[]) { \
+ { \
+ .attr = __ATTR(_name, 0444, thunderx2_pmu_format_show, NULL), \
+ .var = (void *) _config, \
+ } \
+ })[0].attr.attr)
+
+static struct attribute *l3c_pmu_format_attrs[] = {
+ FORMAT_ATTR(event, "config:0-4"),
+ NULL,
+};
+
+static struct attribute *dmc_pmu_format_attrs[] = {
+ FORMAT_ATTR(event, "config:0-4"),
+ NULL,
+};
+
+static const struct attribute_group l3c_pmu_format_attr_group = {
+ .name = "format",
+ .attrs = l3c_pmu_format_attrs,
+};
+
+static const struct attribute_group dmc_pmu_format_attr_group = {
+ .name = "format",
+ .attrs = dmc_pmu_format_attrs,
+};
+
+/*
+ * sysfs event attributes
+ */
+static ssize_t thunderx2_pmu_event_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_ext_attribute *eattr;
+
+ eattr = container_of(attr, struct dev_ext_attribute, attr);
+ return sprintf(buf, "config=0x%lx\n", (unsigned long) eattr->var);
+}
+
+#define EVENT_ATTR(_name, _config) \
+ (&((struct dev_ext_attribute[]) { \
+ { \
+ .attr = __ATTR(_name, 0444, thunderx2_pmu_event_show, NULL), \
+ .var = (void *) _config, \
+ } \
+ })[0].attr.attr)
+
+static struct attribute *l3c_pmu_events_attrs[] = {
+ EVENT_ATTR(nbu_cancel, L3_EVENT_NBU_CANCEL),
+ EVENT_ATTR(dib_retry, L3_EVENT_DIB_RETRY),
+ EVENT_ATTR(dob_retry, L3_EVENT_DOB_RETRY),
+ EVENT_ATTR(dib_credit_retry, L3_EVENT_DIB_CREDIT_RETRY),
+ EVENT_ATTR(dob_credit_retry, L3_EVENT_DOB_CREDIT_RETRY),
+ EVENT_ATTR(force_retry, L3_EVENT_FORCE_RETRY),
+ EVENT_ATTR(idx_conflict_retry, L3_EVENT_IDX_CONFLICT_RETRY),
+ EVENT_ATTR(evict_conflict_retry, L3_EVENT_EVICT_CONFLICT_RETRY),
+ EVENT_ATTR(bank_conflict_retry, L3_EVENT_BANK_CONFLICT_RETRY),
+ EVENT_ATTR(fill_entry_retry, L3_EVENT_FILL_ENTRY_RETRY),
+ EVENT_ATTR(evict_not_ready_retry, L3_EVENT_EVICT_NOT_READY_RETRY),
+ EVENT_ATTR(l3_retry, L3_EVENT_L3_RETRY),
+ EVENT_ATTR(read_request, L3_EVENT_READ_REQ),
+ EVENT_ATTR(write_back_request, L3_EVENT_WRITE_BACK_REQ),
+ EVENT_ATTR(inv_nwrite_request, L3_EVENT_INVALIDATE_NWRITE_REQ),
+ EVENT_ATTR(inv_request, L3_EVENT_INV_REQ),
+ EVENT_ATTR(self_request, L3_EVENT_SELF_REQ),
+ EVENT_ATTR(request, L3_EVENT_REQ),
+ EVENT_ATTR(evict_request, L3_EVENT_EVICT_REQ),
+ EVENT_ATTR(inv_nwrite_hit, L3_EVENT_INVALIDATE_NWRITE_HIT),
+ EVENT_ATTR(inv_hit, L3_EVENT_INVALIDATE_HIT),
+ EVENT_ATTR(self_hit, L3_EVENT_SELF_HIT),
+ EVENT_ATTR(read_hit, L3_EVENT_READ_HIT),
+ NULL,
+};
+
+static struct attribute *dmc_pmu_events_attrs[] = {
+ EVENT_ATTR(cnt_cycles, DMC_EVENT_COUNT_CYCLES),
+ EVENT_ATTR(read_64b_txns, DMC_EVENT_READ_64B_TXNS),
+ EVENT_ATTR(read_below_64b_txns, DMC_EVENT_READ_BELOW_64B_TXNS),
+ EVENT_ATTR(write_txns, DMC_EVENT_WRITE_TXNS),
+ EVENT_ATTR(txn_cycles, DMC_EVENT_TXN_CYCLES),
+ EVENT_ATTR(data_transfers, DMC_EVENT_DATA_TRANSFERS),
+ EVENT_ATTR(cancelled_read_txns, DMC_EVENT_CANCELLED_READ_TXNS),
+ EVENT_ATTR(consumed_read_txns, DMC_EVENT_CONSUMED_READ_TXNS),
+ NULL,
+};
+
+static const struct attribute_group l3c_pmu_events_attr_group = {
+ .name = "events",
+ .attrs = l3c_pmu_events_attrs,
+};
+
+static const struct attribute_group dmc_pmu_events_attr_group = {
+ .name = "events",
+ .attrs = dmc_pmu_events_attrs,
+};
+
+/*
+ * sysfs cpumask attributes
+ */
+static ssize_t cpumask_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct cpumask cpu_mask;
+ struct thunderx2_pmu_uncore_channel *pmu_uncore =
+ pmu_to_thunderx2_pmu_uncore(dev_get_drvdata(dev));
+
+ /* Pick first online cpu from the node */
+ cpumask_clear(&cpu_mask);
+ cpumask_set_cpu(cpumask_first(
+ cpumask_of_node(pmu_uncore->uncore_dev->node)),
+ &cpu_mask);
+
+ return cpumap_print_to_pagebuf(true, buf, &cpu_mask);
+}
+
+static DEVICE_ATTR_RO(cpumask);
+
+static struct attribute *thunderx2_pmu_cpumask_attrs[] = {
+ &dev_attr_cpumask.attr,
+ NULL,
+};
+
+static const struct attribute_group pmu_cpumask_attr_group = {
+ .attrs = thunderx2_pmu_cpumask_attrs,
+};
+
+/*
+ * Per PMU device attribute groups
+ */
+static const struct attribute_group *l3c_pmu_attr_groups[] = {
+ &l3c_pmu_format_attr_group,
+ &pmu_cpumask_attr_group,
+ &l3c_pmu_events_attr_group,
+ NULL
+};
+
+static const struct attribute_group *dmc_pmu_attr_groups[] = {
+ &dmc_pmu_format_attr_group,
+ &pmu_cpumask_attr_group,
+ &dmc_pmu_events_attr_group,
+ NULL
+};
+
+static inline struct active_timer *get_active_timer(struct hrtimer *hrt)
+{
+ return container_of(hrt, struct active_timer, hrtimer);
+}
+
+static inline u32 reg_readl(unsigned long addr)
+{
+ return readl((void __iomem *)addr);
+}
+
+static inline void reg_writel(u32 val, unsigned long addr)
+{
+ writel(val, (void __iomem *)addr);
+}
+
+static int alloc_counter(struct thunderx2_pmu_uncore_channel *pmu_uncore)
+{
+ int counter;
+
+ raw_spin_lock(&pmu_uncore->lock);
+ counter = find_first_zero_bit(pmu_uncore->counter_mask,
+ pmu_uncore->uncore_dev->max_counters);
+ if (counter == pmu_uncore->uncore_dev->max_counters) {
+ raw_spin_unlock(&pmu_uncore->lock);
+ return -ENOSPC;
+ }
+ set_bit(counter, pmu_uncore->counter_mask);
+ raw_spin_unlock(&pmu_uncore->lock);
+ return counter;
+}
+
+static void free_counter(struct thunderx2_pmu_uncore_channel *pmu_uncore,
+ int counter)
+{
+ raw_spin_lock(&pmu_uncore->lock);
+ clear_bit(counter, pmu_uncore->counter_mask);
+ raw_spin_unlock(&pmu_uncore->lock);
+}
+
+/*
+ * DMC and L3 counter interface is muxed across all channels.
+ * hence we need to select the channel before accessing counter
+ * data/control registers.
+ *
+ * L3 Tile and DMC channel selection is through SMC call
+ * SMC call arguments,
+ * x0 = THUNDERX2_SMC_CALL_ID (Vendor SMC call Id)
+ * x1 = THUNDERX2_SMC_SET_CHANNEL (Id to set DMC/L3C channel)
+ * x2 = Node id
+ * x3 = DMC(1)/L3C(0)
+ * x4 = channel Id
+ */
+static void uncore_select_channel(struct perf_event *event)
+{
+ struct arm_smccc_res res;
+ struct thunderx2_pmu_uncore_channel *pmu_uncore =
+ pmu_to_thunderx2_pmu_uncore(event->pmu);
+
+ arm_smccc_smc(THUNDERX2_SMC_CALL_ID, THUNDERX2_SMC_SET_CHANNEL,
+ pmu_uncore->uncore_dev->node,
+ pmu_uncore->uncore_dev->type,
+ pmu_uncore->channel, 0, 0, 0, &res);
+
+}
+
+static void uncore_start_event_l3c(struct perf_event *event, int flags)
+{
+ u32 val;
+ struct hw_perf_event *hwc = &event->hw;
+
+ /* event id encoded in bits [07:03] */
+ val = GET_EVENTID(event) << 3;
+ reg_writel(val, hwc->config_base);
+
+ if (flags & PERF_EF_RELOAD) {
+ u64 prev_raw_count =
+ local64_read(&event->hw.prev_count);
+ reg_writel(prev_raw_count, hwc->event_base);
+ }
+ local64_set(&event->hw.prev_count,
+ reg_readl(hwc->event_base));
+}
+
+static void uncore_start_event_dmc(struct perf_event *event, int flags)
+{
+ u32 val, event_shift = 8;
+ struct hw_perf_event *hwc = &event->hw;
+
+ /* enable and start counters and read current value in prev_count */
+ val = reg_readl(hwc->config_base);
+
+ /* 8 bits for each counter,
+ * bits [05:01] of a counter to set event type.
+ */
+ reg_writel((val & ~(0x1f << (((GET_COUNTERID(event)) *
+ event_shift) + 1))) |
+ (GET_EVENTID(event) <<
+ (((GET_COUNTERID(event)) * event_shift) + 1)),
+ hwc->config_base);
+
+ if (flags & PERF_EF_RELOAD) {
+ u64 prev_raw_count =
+ local64_read(&event->hw.prev_count);
+ reg_writel(prev_raw_count, hwc->event_base);
+ }
+ local64_set(&event->hw.prev_count,
+ reg_readl(hwc->event_base));
+}
+
+static void uncore_stop_event_l3c(struct perf_event *event)
+{
+ reg_writel(0, event->hw.config_base);
+}
+
+static void uncore_stop_event_dmc(struct perf_event *event)
+{
+ u32 val, event_shift = 8;
+ struct hw_perf_event *hwc = &event->hw;
+
+ val = reg_readl(hwc->config_base);
+ reg_writel((val & ~(0xff << ((GET_COUNTERID(event)) * event_shift))),
+ hwc->config_base);
+}
+
+static void init_cntr_base_l3c(struct perf_event *event,
+ struct thunderx2_pmu_uncore_dev *uncore_dev)
+{
+
+ struct hw_perf_event *hwc = &event->hw;
+
+ /* counter ctrl/data reg offset at 8 */
+ hwc->config_base = uncore_dev->base
+ + L3C_COUNTER_CTL + (8 * GET_COUNTERID(event));
+ hwc->event_base = uncore_dev->base
+ + L3C_COUNTER_DATA + (8 * GET_COUNTERID(event));
+}
+
+static void init_cntr_base_dmc(struct perf_event *event,
+ struct thunderx2_pmu_uncore_dev *uncore_dev)
+{
+
+ struct hw_perf_event *hwc = &event->hw;
+
+ hwc->config_base = uncore_dev->base
+ + DMC_COUNTER_CTL;
+ /* counter data reg offset at 0xc */
+ hwc->event_base = uncore_dev->base
+ + DMC_COUNTER_DATA + (0xc * GET_COUNTERID(event));
+}
+
+static void thunderx2_uncore_update(struct perf_event *event)
+{
+ s64 prev, new = 0;
+ u64 delta;
+ struct hw_perf_event *hwc = &event->hw;
+ struct thunderx2_pmu_uncore_channel *pmu_uncore;
+ enum thunderx2_uncore_type type;
+
+ pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
+ type = pmu_uncore->uncore_dev->type;
+
+ if (pmu_uncore->uncore_dev->select_channel)
+ pmu_uncore->uncore_dev->select_channel(event);
+
+ new = reg_readl(hwc->event_base);
+ prev = local64_xchg(&hwc->prev_count, new);
+
+ /* handles rollover of 32 bit counter */
+ delta = (u32)(((1UL << 32) - prev) + new);
+
+ local64_add(delta, &event->count);
+}
+
+enum thunderx2_uncore_type get_uncore_device_type(struct acpi_device *adev)
+{
+ int i = 0;
+ struct acpi_uncore_device {
+ __u8 id[ACPI_ID_LEN];
+ enum thunderx2_uncore_type type;
+ } devices[] = {
+ {"CAV901D", PMU_TYPE_L3C},
+ {"CAV901F", PMU_TYPE_DMC},
+ {"", PMU_TYPE_INVALID},
+ };
+
+ while (devices[i].type != PMU_TYPE_INVALID) {
+ if (!strcmp(acpi_device_hid(adev), devices[i].id))
+ return devices[i].type;
+ i++;
+ }
+ return PMU_TYPE_INVALID;
+}
+
+/*
+ * We must NOT create groups containing events from multiple hardware PMUs,
+ * although mixing different software and hardware PMUs is allowed.
+ */
+static bool thunderx2_uncore_validate_event_group(struct perf_event *event)
+{
+ struct pmu *pmu = event->pmu;
+ struct perf_event *leader = event->group_leader;
+ struct perf_event *sibling;
+ int counters = 0;
+
+ if (leader->pmu != event->pmu && !is_software_event(leader))
+ return false;
+
+ counters++;
+
+ for_each_sibling_event(sibling, event->group_leader) {
+ if (is_software_event(sibling))
+ continue;
+ if (sibling->pmu != pmu)
+ return false;
+ counters++;
+ }
+
+ /*
+ * If the group requires more counters than the HW has,
+ * it cannot ever be scheduled.
+ */
+ return counters <= UNCORE_MAX_COUNTERS;
+}
+
+static int thunderx2_uncore_event_init(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ struct thunderx2_pmu_uncore_channel *pmu_uncore;
+
+ /* Test the event attr type check for PMU enumeration */
+ if (event->attr.type != event->pmu->type)
+ return -ENOENT;
+
+ /*
+ * SOC PMU counters are shared across all cores.
+ * Therefore, it does not support per-process mode.
+ * Also, it does not support event sampling mode.
+ */
+ if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
+ return -EINVAL;
+
+ /* SOC counters do not have usr/os/guest/host bits */
+ if (event->attr.exclude_user || event->attr.exclude_kernel ||
+ event->attr.exclude_host || event->attr.exclude_guest)
+ return -EINVAL;
+
+ if (event->cpu < 0)
+ return -EINVAL;
+
+ pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
+
+ if (!pmu_uncore)
+ return -ENODEV;
+
+ /* Pick first online cpu from the node */
+ event->cpu = cpumask_first(
+ cpumask_of_node(pmu_uncore->uncore_dev->node));
+
+ if (event->cpu >= nr_cpu_ids)
+ return -EINVAL;
+
+ if (event->attr.config >= pmu_uncore->uncore_dev->max_events)
+ return -EINVAL;
+
+ /* store event id */
+ hwc->config = event->attr.config;
+
+ /* Validate the group */
+ if (!thunderx2_uncore_validate_event_group(event))
+ return -EINVAL;
+
+ return 0;
+}
+
+static void thunderx2_uncore_start(struct perf_event *event, int flags)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ struct thunderx2_pmu_uncore_channel *pmu_uncore;
+ struct thunderx2_pmu_uncore_dev *uncore_dev;
+ unsigned long irqflags;
+ struct active_timer *active_timer;
+
+ hwc->state = 0;
+ pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
+ uncore_dev = pmu_uncore->uncore_dev;
+
+ raw_spin_lock_irqsave(&uncore_dev->lock, irqflags);
+
+ if (uncore_dev->select_channel)
+ uncore_dev->select_channel(event);
+ uncore_dev->start_event(event, flags);
+ raw_spin_unlock_irqrestore(&uncore_dev->lock, irqflags);
+
+ perf_event_update_userpage(event);
+ active_timer = &pmu_uncore->active_timers[GET_COUNTERID(event)];
+ active_timer->event = event;
+
+ hrtimer_start(&active_timer->hrtimer,
+ ns_to_ktime(uncore_dev->hrtimer_interval),
+ HRTIMER_MODE_REL_PINNED);
+}
+
+static void thunderx2_uncore_stop(struct perf_event *event, int flags)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ struct thunderx2_pmu_uncore_channel *pmu_uncore;
+ struct thunderx2_pmu_uncore_dev *uncore_dev;
+ unsigned long irqflags;
+
+ if (hwc->state & PERF_HES_UPTODATE)
+ return;
+
+ pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
+ uncore_dev = pmu_uncore->uncore_dev;
+
+ raw_spin_lock_irqsave(&uncore_dev->lock, irqflags);
+
+ if (uncore_dev->select_channel)
+ uncore_dev->select_channel(event);
+ uncore_dev->stop_event(event);
+
+ WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
+ hwc->state |= PERF_HES_STOPPED;
+ if ((flags & PERF_EF_UPDATE) && !(hwc->state & PERF_HES_UPTODATE)) {
+ thunderx2_uncore_update(event);
+ hwc->state |= PERF_HES_UPTODATE;
+ }
+ raw_spin_unlock_irqrestore(&uncore_dev->lock, irqflags);
+
+ hrtimer_cancel(
+ &pmu_uncore->active_timers[GET_COUNTERID(event)].hrtimer);
+ pmu_uncore->active_timers[GET_COUNTERID(event)].event = NULL;
+}
+
+static int thunderx2_uncore_add(struct perf_event *event, int flags)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ struct thunderx2_pmu_uncore_channel *pmu_uncore;
+ struct thunderx2_pmu_uncore_dev *uncore_dev;
+
+ pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
+ uncore_dev = pmu_uncore->uncore_dev;
+
+ /* Allocate a free counter */
+ hwc->idx = alloc_counter(pmu_uncore);
+ if (hwc->idx < 0)
+ return -EAGAIN;
+
+ /* set counter control and data registers base address */
+ uncore_dev->init_cntr_base(event, uncore_dev);
+
+ hwc->state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
+ if (flags & PERF_EF_START)
+ thunderx2_uncore_start(event, PERF_EF_RELOAD);
+
+ return 0;
+}
+
+static void thunderx2_uncore_del(struct perf_event *event, int flags)
+{
+ struct thunderx2_pmu_uncore_channel *pmu_uncore =
+ pmu_to_thunderx2_pmu_uncore(event->pmu);
+ struct hw_perf_event *hwc = &event->hw;
+
+ thunderx2_uncore_stop(event, PERF_EF_UPDATE);
+
+ /* clear the assigned counter */
+ free_counter(pmu_uncore, GET_COUNTERID(event));
+
+ perf_event_update_userpage(event);
+ hwc->idx = -1;
+}
+
+static void thunderx2_uncore_read(struct perf_event *event)
+{
+ unsigned long irqflags;
+ struct thunderx2_pmu_uncore_channel *pmu_uncore =
+ pmu_to_thunderx2_pmu_uncore(event->pmu);
+
+ raw_spin_lock_irqsave(&pmu_uncore->uncore_dev->lock, irqflags);
+ thunderx2_uncore_update(event);
+ raw_spin_unlock_irqrestore(&pmu_uncore->uncore_dev->lock, irqflags);
+}
+
+static enum hrtimer_restart thunderx2_uncore_hrtimer_callback(
+ struct hrtimer *hrt)
+{
+ struct thunderx2_pmu_uncore_channel *pmu_uncore;
+ struct perf_event *event;
+ unsigned long irqflags;
+ struct active_timer *active_timer;
+
+ active_timer = get_active_timer(hrt);
+ event = active_timer->event;
+
+ pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
+
+ raw_spin_lock_irqsave(&pmu_uncore->uncore_dev->lock, irqflags);
+ thunderx2_uncore_update(event);
+ raw_spin_unlock_irqrestore(&pmu_uncore->uncore_dev->lock, irqflags);
+
+ hrtimer_forward_now(hrt,
+ ns_to_ktime(
+ pmu_uncore->uncore_dev->hrtimer_interval));
+ return HRTIMER_RESTART;
+}
+
+static int thunderx2_pmu_uncore_register(
+ struct thunderx2_pmu_uncore_channel *pmu_uncore)
+{
+ struct device *dev = pmu_uncore->uncore_dev->dev;
+ char *name = pmu_uncore->uncore_dev->name;
+ int channel = pmu_uncore->channel;
+
+ /* Perf event registration */
+ pmu_uncore->pmu = (struct pmu) {
+ .attr_groups = pmu_uncore->uncore_dev->attr_groups,
+ .task_ctx_nr = perf_invalid_context,
+ .event_init = thunderx2_uncore_event_init,
+ .add = thunderx2_uncore_add,
+ .del = thunderx2_uncore_del,
+ .start = thunderx2_uncore_start,
+ .stop = thunderx2_uncore_stop,
+ .read = thunderx2_uncore_read,
+ };
+
+ pmu_uncore->pmu.name = devm_kasprintf(dev, GFP_KERNEL,
+ "%s_%d", name, channel);
+
+ return perf_pmu_register(&pmu_uncore->pmu, pmu_uncore->pmu.name, -1);
+}
+
+static int thunderx2_pmu_uncore_add(struct thunderx2_pmu_uncore_dev *uncore_dev,
+ int channel)
+{
+ struct thunderx2_pmu_uncore_channel *pmu_uncore;
+ int ret;
+ int counter;
+
+ pmu_uncore = devm_kzalloc(uncore_dev->dev, sizeof(*pmu_uncore),
+ GFP_KERNEL);
+ if (!pmu_uncore)
+ return -ENOMEM;
+
+ pmu_uncore->uncore_dev = uncore_dev;
+ pmu_uncore->channel = channel;
+
+ /* we can run up to (max_counters * max_channels) events
+ * simultaneously, allocate hrtimers per channel.
+ */
+ pmu_uncore->active_timers = devm_kzalloc(uncore_dev->dev,
+ sizeof(struct active_timer) * uncore_dev->max_counters,
+ GFP_KERNEL);
+
+ for (counter = 0; counter < uncore_dev->max_counters; counter++) {
+ hrtimer_init(&pmu_uncore->active_timers[counter].hrtimer,
+ CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL);
+ pmu_uncore->active_timers[counter].hrtimer.function =
+ thunderx2_uncore_hrtimer_callback;
+ }
+
+ ret = thunderx2_pmu_uncore_register(pmu_uncore);
+ if (ret) {
+ dev_err(uncore_dev->dev, "%s PMU: Failed to init driver\n",
+ uncore_dev->name);
+ return -ENODEV;
+ }
+
+ dev_dbg(uncore_dev->dev, "%s PMU UNCORE registered\n",
+ pmu_uncore->pmu.name);
+ return ret;
+}
+
+static struct thunderx2_pmu_uncore_dev *init_pmu_uncore_dev(
+ struct device *dev, acpi_handle handle,
+ struct acpi_device *adev, u32 type)
+{
+ struct thunderx2_pmu_uncore_dev *uncore_dev;
+ unsigned long base;
+ struct resource res;
+ struct resource_entry *rentry;
+ struct list_head list;
+ int ret;
+
+ INIT_LIST_HEAD(&list);
+ ret = acpi_dev_get_resources(adev, &list, NULL, NULL);
+ if (ret <= 0) {
+ dev_err(dev, "failed to parse _CRS method, error %d\n", ret);
+ return NULL;
+ }
+
+ list_for_each_entry(rentry, &list, node) {
+ if (resource_type(rentry->res) == IORESOURCE_MEM) {
+ res = *rentry->res;
+ break;
+ }
+ }
+
+ if (!rentry->res)
+ return NULL;
+
+ acpi_dev_free_resource_list(&list);
+
+ base = (unsigned long)devm_ioremap_resource(dev, &res);
+ if (IS_ERR((void *)base)) {
+ dev_err(dev, "PMU type %d: Fail to map resource\n", type);
+ return NULL;
+ }
+
+ uncore_dev = devm_kzalloc(dev, sizeof(*uncore_dev), GFP_KERNEL);
+ if (!uncore_dev)
+ return NULL;
+
+ uncore_dev->dev = dev;
+ uncore_dev->type = type;
+ uncore_dev->base = base;
+ uncore_dev->node = dev_to_node(dev);
+
+ raw_spin_lock_init(&uncore_dev->lock);
+
+ switch (uncore_dev->type) {
+ case PMU_TYPE_L3C:
+ uncore_dev->max_counters = UNCORE_MAX_COUNTERS;
+ uncore_dev->max_channels = UNCORE_L3_MAX_TILES;
+ uncore_dev->max_events = L3_EVENT_MAX;
+ uncore_dev->hrtimer_interval = UNCORE_HRTIMER_INTERVAL;
+ uncore_dev->attr_groups = l3c_pmu_attr_groups;
+ uncore_dev->name = devm_kasprintf(dev, GFP_KERNEL,
+ "uncore_l3c_%d", uncore_dev->node);
+ uncore_dev->init_cntr_base = init_cntr_base_l3c;
+ uncore_dev->start_event = uncore_start_event_l3c;
+ uncore_dev->stop_event = uncore_stop_event_l3c;
+ uncore_dev->select_channel = uncore_select_channel;
+ break;
+ case PMU_TYPE_DMC:
+ uncore_dev->max_counters = UNCORE_MAX_COUNTERS;
+ uncore_dev->max_channels = UNCORE_DMC_MAX_CHANNELS;
+ uncore_dev->max_events = DMC_EVENT_MAX;
+ uncore_dev->hrtimer_interval = UNCORE_HRTIMER_INTERVAL;
+ uncore_dev->attr_groups = dmc_pmu_attr_groups;
+ uncore_dev->name = devm_kasprintf(dev, GFP_KERNEL,
+ "uncore_dmc_%d", uncore_dev->node);
+ uncore_dev->init_cntr_base = init_cntr_base_dmc;
+ uncore_dev->start_event = uncore_start_event_dmc;
+ uncore_dev->stop_event = uncore_stop_event_dmc;
+ uncore_dev->select_channel = uncore_select_channel;
+ break;
+ case PMU_TYPE_INVALID:
+ devm_kfree(dev, uncore_dev);
+ uncore_dev = NULL;
+ break;
+ }
+
+ return uncore_dev;
+}
+
+static acpi_status thunderx2_pmu_uncore_dev_add(acpi_handle handle, u32 level,
+ void *data, void **return_value)
+{
+ struct thunderx2_pmu_uncore_dev *uncore_dev;
+ struct acpi_device *adev;
+ enum thunderx2_uncore_type type;
+ int channel;
+
+ if (acpi_bus_get_device(handle, &adev))
+ return AE_OK;
+ if (acpi_bus_get_status(adev) || !adev->status.present)
+ return AE_OK;
+
+ type = get_uncore_device_type(adev);
+ if (type == PMU_TYPE_INVALID)
+ return AE_OK;
+
+ uncore_dev = init_pmu_uncore_dev((struct device *)data, handle,
+ adev, type);
+
+ if (!uncore_dev)
+ return AE_ERROR;
+
+ for (channel = 0; channel < uncore_dev->max_channels; channel++) {
+ if (thunderx2_pmu_uncore_add(uncore_dev, channel)) {
+ /* Can't add the PMU device, abort */
+ return AE_ERROR;
+ }
+ }
+ return AE_OK;
+}
+
+static int thunderx2_uncore_dev_probe(struct device *dev)
+{
+ acpi_handle handle;
+ acpi_status status;
+
+ if (!has_acpi_companion(dev))
+ return -ENODEV;
+
+ handle = ACPI_HANDLE(dev);
+ if (!handle)
+ return -EINVAL;
+
+ status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
+ thunderx2_pmu_uncore_dev_add,
+ NULL, dev, NULL);
+ if (ACPI_FAILURE(status)) {
+ dev_err(dev, "failed to probe PMU devices\n");
+ return_ACPI_STATUS(status);
+ }
+
+ dev_info(dev, "node%d: pmu uncore registered\n", dev_to_node(dev));
+ return 0;
+}
+
+static const struct acpi_device_id thunderx2_uncore_acpi_match[] = {
+ {"CAV901C", 0},
+ {},
+};
+MODULE_DEVICE_TABLE(acpi, thunderx2_uncore_acpi_match);
+
+static int thunderx2_uncore_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct arm_smccc_res res;
+
+ set_dev_node(dev, acpi_get_node(ACPI_HANDLE(dev)));
+
+ /* Make sure firmware supports DMC/L3C set channel smc call */
+ arm_smccc_smc(THUNDERX2_SMC_CALL_ID, THUNDERX2_SMC_SET_CHANNEL,
+ dev_to_node(dev), 0, 0, 0, 0, 0, &res);
+ if (res.a0) {
+ dev_err(dev, "No Firmware support for PMU UNCORE(%d)\n",
+ dev_to_node(dev));
+ return -ENODEV;
+ }
+
+ /* Walk through the tree for all PMU UNCORE devices */
+ return thunderx2_uncore_dev_probe(dev);
+}
+
+static struct platform_driver thunderx2_uncore_driver = {
+ .probe = thunderx2_uncore_probe,
+ .driver = {
+ .name = "thunderx2-uncore-pmu",
+ .acpi_match_table = ACPI_PTR(thunderx2_uncore_acpi_match),
+ },
+};
+
+builtin_platform_driver(thunderx2_uncore_driver);
--
2.9.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver
From: Ganapatrao Kulkarni @ 2018-04-25 9:00 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-arm-kernel
Cc: Will.Deacon, mark.rutland, jnair, Robert.Richter, Vadim.Lomovtsev,
Jan.Glauber, gklkml16
This patchset adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
The SoC has PMU support in L3 cache controller (L3C) and in the
DDR4 Memory Controller (DMC).
v4:
-Incroporated review comments from Mark Rutland[1]
[1] https://www.spinics.net/lists/arm-kernel/msg588563.html
v3:
- fixed warning reported by kbuild robot
v2:
- rebased to 4.12-rc1
- Removed Arch VULCAN dependency.
- update SMC call parameters as per latest firmware.
v1:
-Initial patch
Ganapatrao Kulkarni (2):
perf: uncore: Adding documentation for ThunderX2 pmu uncore driver
ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver
Documentation/perf/thunderx2-pmu.txt | 66 +++
drivers/perf/Kconfig | 8 +
drivers/perf/Makefile | 1 +
drivers/perf/thunderx2_pmu.c | 958 +++++++++++++++++++++++++++++++++++
4 files changed, 1033 insertions(+)
create mode 100644 Documentation/perf/thunderx2-pmu.txt
create mode 100644 drivers/perf/thunderx2_pmu.c
--
2.9.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 1/1] misc: IBM Virtual Management Channel Driver
From: Linus Walleij @ 2018-04-25 8:29 UTC (permalink / raw)
To: Bryant G. Ly, christoffer.dall
Cc: Benjamin Herrenschmidt, Michael Ellerman, Greg KH, Arnd Bergmann,
Jonathan Corbet, seroyer, mrochs, adreznec, fbarrat,
David S. Miller, Andrew Morton, Randy Dunlap, mikey,
Philippe Ombredanne, tlfalcon, msuchanek, linux-doc,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <1524494812-60150-2-git-send-email-bryantly@linux.vnet.ibm.com>
I don't know why I'm included in review of this driver, but why
not :) it is good to include people.
Thanks for your patch! It looks exciting and complicated,
I like that kind of stuff.
On Mon, Apr 23, 2018 at 4:46 PM, Bryant G. Ly
<bryantly@linux.vnet.ibm.com> wrote:
> This driver is a logical device which provides an
> interface between the hypervisor and a management
> partition.
Please indicate what this management partition is to
be used for, i.e. the intended use case.
> This driver is to be used for the POWER Virtual
> Management Channel Virtual Adapter on the PowerVM
> platform.
Is that virtualization on the PowerPC platform?
> It provides both request/response and
> async message support through the /dev/ibmvmc node.
Is that a character or block device?
I guess block, but it's nice to have some specifics
in the commit message.
> diff --git a/Documentation/misc-devices/ibmvmc.txt b/Documentation/misc-devices/ibmvmc.txt
The document suffers a bit from internal lingo, so it's be great
if you improve it a bit with a style that will be welcoming for newcomers
who have no idea what you are talking about.
I will point out some items below.
> +Description
> +===========
> +
> +The Virtual Management Channel (VMC) is a logical device which provides an
> +interface between the hypervisor and a management partition.
What kind of interface? A bitstream? Message passing interface?
Marshalling of structs? Some specifics would be great.
> This
> +management partition is intended to provide an alternative to HMC-based
> +system management.
Please expand the acronym HMC for the newcomer so we do not need
to look it up, or it looks like the document is only for people who already
know everything about virtualization specifics.
> In the management partition, a Novalink application
> +exists
Is Novalink some kind of product name? In that case, can it be
instead described with some neutral technology name and state
Novalink as an examplf of this type of technology?
> which enables a system administrator to configure the system’s
> +partitioning characteristics
Exemplify "partitioning characteristics", with a sentence in this
vein: "partitioning characteristics such as FOO, BAR and BAZ".
> via a command line interface (CLI) or
> +Representational State Transfer Application (REST).
I understand what CLI is but what is a representational state
transfer application? Is that a fancy name for a GUI application
doing the same thing as a CLI program would do?
> You can also manage the
> +server by using PowerVC
There was PowerVM now there is PowerVC. What are those things
really? PowerVM I guess is virtual machine on PowerPC? What is
PowerVC? Virtual client (guest) in the PowerVM?
This kind of lingo makes the document a hard read for me.
> or other OpenStack solution.
I heard about OpenStack. I have a vague idea about what it is,
do you mean "other virtualization concepts"?
> Support for
> +conventional HMC management of the system may still be provided on a
> +system; however, when an HMC is attached to the system, the VMC
> +interface is disabled by the hypervisor.
The VMC acronym is expanded below, instead expand it at first
instance. The same for HMC (hypervisor management channel I guess?
it is never really explained.)
> +NovaLink runs on a Linux logical partition on a POWER8 or newer processor-
> +based server that is virtualized by PowerVM.
So this information needs to be in the top of the document.
> System configuration,
> +maintenance, and control functions which traditionally require an HMC can
> +be implemented in the Novalink using a combination of HMC to hypervisor
> +interfaces and existing operating system methods. This tool provides
What tool? It is unclear what tool we are referring to here.
A command line tool? A technology? etc.
> a
> +subset of the functions implemented by the HMC and enables basic partition
> +configuration. The set of HMC to hypervisor messages
This makes me think that probably the "h" in HMC stands for "hypervisor"
so now I start to puzzle things together. But it's nicer if you just expand
the acronym the first time you use it.
> supported by the
> +Novalink component
I still haven't figured out what that is, in practice.
> are passed to the hypervisor over a VMC interface, which
> +is defined below.
Maybe some illustration of how HMC, Novalink and VMC work
together would be appropriate?
> +Virtual Management Channel (VMC)
> +A logical device, called the virtual management channel (VMC), is defined
> +for communicating between the Novalink application and the hypervisor.
So is "Novalink" some specific application, as in a proprietary
piece of software or something?
I'm still confused.
> +This device, similar to a VSCSI server device,
What is that acronym now, I get completely confused.
> is presented to a designated
> +management partition as a virtual device and is only presented when the
> +system is not HMC managed.
> +This communication device borrows aspects from both VSCSI and ILLAN devices
Now there is ILLAN too.
> +and is implemented using the CRQ and the RDMA interfaces.
CRQ and RDMA. The RDMA I heard about, I wonder what CRQ is.
At this point the document is referring to so much external a priori
knowledge that I don't have that I don't understand anything at all.
So if this document is meant as an introduction to the technology
for newcomers, it's not working at all, unfortunately.
If some specific domain knowledge is needed to read and
understand the document, you need to state these prerequisites
at the beginning of the document.
Something like: "if you don't know a lot about virtualization already,
then don't even bother trying to read this document".
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
From: Atish Patra @ 2018-04-25 8:09 UTC (permalink / raw)
To: Alan Kao
Cc: Palmer Dabbelt, albert@sifive.com, peterz@infradead.org,
mingo@redhat.com, acme@kernel.org,
alexander.shishkin@linux.intel.com, jolsa@redhat.com,
namhyung@kernel.org, sols@sifive.com, corbet@lwn.net,
linux-riscv@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, greentime@andestech.com,
nickhu@andestech.com
In-Reply-To: <20180425031936.GA7303@andestech.com>
On 4/24/18 8:19 PM, Alan Kao wrote:
> Hi Atish, Palmer,
>
> On Tue, Apr 24, 2018 at 06:15:49PM -0700, Atish Patra wrote:
>> On 4/24/18 5:29 PM, Palmer Dabbelt wrote:
>>> On Tue, 24 Apr 2018 15:16:16 PDT (-0700), atish.patra@wdc.com wrote:
>>>> On 4/24/18 12:44 PM, Palmer Dabbelt wrote:
>>>>> On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.patra@wdc.com wrote:
>>>>>> On 4/24/18 11:07 AM, Atish Patra wrote:
>>>>>>> On 4/19/18 4:28 PM, Alan Kao wrote:
>>>>>>> However, I got an rcu-stall for the test "47: Event times".
>>>>>>> # ./perf test -v 47
>>>>>> Got it working. The test tries to attach the event to CPU0 which doesn't
>>>>>> exist in HighFive Unleashed. Changing it to cpu1 works.
>>>>>>
>>>>>> diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
>>>>>> index 1a2686f..eb11632f 100644
>>>>>> --- a/tools/perf/tests/event-times.c
>>>>>> +++ b/tools/perf/tests/event-times.c
>>>>>> @@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
>>>>>> *evlist)
>>>>>> struct cpu_map *cpus;
>>>>>> int err;
>>>>>>
>>>>>> - pr_debug("attaching to CPU 0 as enabled\n");
>>>>>> + pr_debug("attaching to CPU 1 as disabled\n");
>>>>>>
>>>>>> - cpus = cpu_map__new("0");
>>>>>> + cpus = cpu_map__new("1");
>>>>>> if (cpus == NULL) {
>>>>>> pr_debug("failed to call cpu_map__new\n");
>>>>>> return -1;
>>>>>> @@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
>>>>>> *evlist)
>>>>>> struct cpu_map *cpus;
>>>>>> int err;
>>>>>>
>>>>>> - pr_debug("attaching to CPU 0 as enabled\n");
>>>>>> + pr_debug("attaching to CPU 1 as enabled\n");
>>>>>>
>>>>>> - cpus = cpu_map__new("0");
>>>>>> + cpus = cpu_map__new("1");
>>>>>> if (cpus == NULL) {
>>>>>> pr_debug("failed to call cpu_map__new\n");
>>>>>> return -1;
>>>>>>
>>>>>>
>>>>>> Palmer,
>>>>>> Would it be better to officially document it somewhere that CPU0 doesn't
>>>>>> exist in the HighFive Unleashed board ?
>>>>>> I fear that there will be other standard tests/code path that may fail
>>>>>> because of inherent assumption of cpu0 presence.
>>>>>
>>>>> I think the best way to fix this is to just have BBL (or whatever the
>>>>> bootloader is) renumber the CPUs so they're contiguous and begin with 0.
>>>>
>>>> Do you mean BBL will update the device tree that kernel eventually parse
>>>> and set the hart id?
>>>> Sounds good to me unless it acts as a big hack in future boot loaders.
>>>
>>> Right now the machine-mode and supervisor-mode hart IDs are logically separate:
>>> the bootloader just provides the hart ID as a register argument when starting
>>> the kernel.
>>
>> Yes.
>>
>> BBL already needs to enumerate the harts by looking through the
>>> device tree for various other reasons (at least to mask off the harts that
>>> Linux doesn't support), so it's not that much effort to just maintain a mapping
>> >from supervisor-mode hart IDs to machine-mode hart IDs.
>>>
>>
>> But Linux also parses the device tree to get hart ID in
>> riscv_of_processor_hart(). This is used to setup the possible/present cpu
>> map in setup_smp().
>>
>> Thus, Linux also need to see a device tree with cpu0-3 instead of cpu1-4.
>> Otherwise, present cpu map will be incorrect. Isn't it ?
>>
>>> I have some patches floating around that do this, but appear to do it
>>> incorrectly enough that nothing boots so maybe I'm missing something that makes
>>> this complicated :).
>>>
>>
>> Just a wild guess: May be the because of the above reason ;)
>>
>
> Thanks for the test and discussion. It looks like am implementation issue from
> Unleash, so ... is there anything I should fix and provide a further patch?
>
Nope. Nothing for this issue.
The fix for this issue should be either in bbl or kernel as a separate
patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Documentation/i2c: direct users to i2c-tools regarding i2c/smbus.h
From: Jean Delvare @ 2018-04-25 6:05 UTC (permalink / raw)
To: Sam Hansen; +Cc: linux-i2c, wsa, corbet, linux-doc, linux-kernel
In-Reply-To: <20180419222356.242535-1-hansens@google.com>
Hi Sam,
Please don't include the same persons in To: and Cc:. It makes the
message delivered twice to them.
On Thu, 19 Apr 2018 15:23:56 -0700, Sam Hansen wrote:
> The current examples reference i2c/smbus.h, which is the first reference
> in Documentation/i2c/dev-interface to anything related to the i2c-tools
> project. This moves the existing reference to i2c-tools up into the
> C-example, directing the user to the project's git repository.
>
> Signed-off-by: Sam Hansen <hansens@google.com>
> ---
> Documentation/i2c/dev-interface | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
> index fbed645ccd75..ed20f7b7851a 100644
> --- a/Documentation/i2c/dev-interface
> +++ b/Documentation/i2c/dev-interface
> @@ -23,6 +23,10 @@ First, you need to include these two headers:
> #include <linux/i2c-dev.h>
> #include <i2c/smbus.h>
>
> +The i2c/smbus header file is provided by the i2c-tools project. For more info
> +about i2c-tools, see:
> +https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/
> +
> Now, you have to decide which adapter you want to access. You should
> inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
> Adapter numbers are assigned somewhat dynamically, so you can not
> @@ -163,10 +167,6 @@ what happened. The 'write' transactions return 0 on success; the
> returns the number of values read. The block buffers need not be longer
> than 32 bytes.
>
> -The above functions are made available by linking against the libi2c library,
> -which is provided by the i2c-tools project. See:
> -https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/.
> -
I'm fine with moving the pointer to i2c-tools up in the document.
However I find it unfortunate to remove the only reference to libi2c.
Typically, distributions will only include the tools in i2c-tools, and
they are not relevant in this case. The library will be in a separate
package (libi2c or similar), and the header file in yet another package
(libi2c-devel or similar.) Although the exact package names are
distribution specific, it would be convenient to hint the reader at
which packages he is supposed to install. You could also mention that
the C program must be compiled with -li2c.
>
> Implementation details
> ======================
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
From: Alan Kao @ 2018-04-25 3:19 UTC (permalink / raw)
To: Atish Patra
Cc: Palmer Dabbelt, albert@sifive.com, peterz@infradead.org,
mingo@redhat.com, acme@kernel.org,
alexander.shishkin@linux.intel.com, jolsa@redhat.com,
namhyung@kernel.org, sols@sifive.com, corbet@lwn.net,
linux-riscv@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, greentime@andestech.com,
nickhu@andestech.com
In-Reply-To: <6b211b64-5c17-2884-5b6a-6ff1d3287b16@wdc.com>
Hi Atish, Palmer,
On Tue, Apr 24, 2018 at 06:15:49PM -0700, Atish Patra wrote:
> On 4/24/18 5:29 PM, Palmer Dabbelt wrote:
> >On Tue, 24 Apr 2018 15:16:16 PDT (-0700), atish.patra@wdc.com wrote:
> >>On 4/24/18 12:44 PM, Palmer Dabbelt wrote:
> >>>On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.patra@wdc.com wrote:
> >>>>On 4/24/18 11:07 AM, Atish Patra wrote:
> >>>>>On 4/19/18 4:28 PM, Alan Kao wrote:
> >>>>>However, I got an rcu-stall for the test "47: Event times".
> >>>>># ./perf test -v 47
> >>>>Got it working. The test tries to attach the event to CPU0 which doesn't
> >>>>exist in HighFive Unleashed. Changing it to cpu1 works.
> >>>>
> >>>>diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
> >>>>index 1a2686f..eb11632f 100644
> >>>>--- a/tools/perf/tests/event-times.c
> >>>>+++ b/tools/perf/tests/event-times.c
> >>>>@@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
> >>>>*evlist)
> >>>> struct cpu_map *cpus;
> >>>> int err;
> >>>>
> >>>>- pr_debug("attaching to CPU 0 as enabled\n");
> >>>>+ pr_debug("attaching to CPU 1 as disabled\n");
> >>>>
> >>>>- cpus = cpu_map__new("0");
> >>>>+ cpus = cpu_map__new("1");
> >>>> if (cpus == NULL) {
> >>>> pr_debug("failed to call cpu_map__new\n");
> >>>> return -1;
> >>>>@@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
> >>>>*evlist)
> >>>> struct cpu_map *cpus;
> >>>> int err;
> >>>>
> >>>>- pr_debug("attaching to CPU 0 as enabled\n");
> >>>>+ pr_debug("attaching to CPU 1 as enabled\n");
> >>>>
> >>>>- cpus = cpu_map__new("0");
> >>>>+ cpus = cpu_map__new("1");
> >>>> if (cpus == NULL) {
> >>>> pr_debug("failed to call cpu_map__new\n");
> >>>> return -1;
> >>>>
> >>>>
> >>>>Palmer,
> >>>>Would it be better to officially document it somewhere that CPU0 doesn't
> >>>>exist in the HighFive Unleashed board ?
> >>>>I fear that there will be other standard tests/code path that may fail
> >>>>because of inherent assumption of cpu0 presence.
> >>>
> >>>I think the best way to fix this is to just have BBL (or whatever the
> >>>bootloader is) renumber the CPUs so they're contiguous and begin with 0.
> >>
> >>Do you mean BBL will update the device tree that kernel eventually parse
> >>and set the hart id?
> >>Sounds good to me unless it acts as a big hack in future boot loaders.
> >
> >Right now the machine-mode and supervisor-mode hart IDs are logically separate:
> >the bootloader just provides the hart ID as a register argument when starting
> >the kernel.
>
> Yes.
>
> BBL already needs to enumerate the harts by looking through the
> >device tree for various other reasons (at least to mask off the harts that
> >Linux doesn't support), so it's not that much effort to just maintain a mapping
> >from supervisor-mode hart IDs to machine-mode hart IDs.
> >
>
> But Linux also parses the device tree to get hart ID in
> riscv_of_processor_hart(). This is used to setup the possible/present cpu
> map in setup_smp().
>
> Thus, Linux also need to see a device tree with cpu0-3 instead of cpu1-4.
> Otherwise, present cpu map will be incorrect. Isn't it ?
>
> >I have some patches floating around that do this, but appear to do it
> >incorrectly enough that nothing boots so maybe I'm missing something that makes
> >this complicated :).
> >
>
> Just a wild guess: May be the because of the above reason ;)
>
Thanks for the test and discussion. It looks like am implementation issue from
Unleash, so ... is there anything I should fix and provide a further patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
From: Atish Patra @ 2018-04-25 1:15 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: alankao@andestech.com, albert@sifive.com, peterz@infradead.org,
mingo@redhat.com, acme@kernel.org,
alexander.shishkin@linux.intel.com, jolsa@redhat.com,
namhyung@kernel.org, sols@sifive.com, corbet@lwn.net,
linux-riscv@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, greentime@andestech.com,
nickhu@andestech.com
In-Reply-To: <mhng-0abe4f84-0dd3-437c-8cf2-b87def246796@palmer-si-x1c4>
On 4/24/18 5:29 PM, Palmer Dabbelt wrote:
> On Tue, 24 Apr 2018 15:16:16 PDT (-0700), atish.patra@wdc.com wrote:
>> On 4/24/18 12:44 PM, Palmer Dabbelt wrote:
>>> On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.patra@wdc.com wrote:
>>>> On 4/24/18 11:07 AM, Atish Patra wrote:
>>>>> On 4/19/18 4:28 PM, Alan Kao wrote:
>>>>> However, I got an rcu-stall for the test "47: Event times".
>>>>> # ./perf test -v 47
>>>> Got it working. The test tries to attach the event to CPU0 which doesn't
>>>> exist in HighFive Unleashed. Changing it to cpu1 works.
>>>>
>>>> diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
>>>> index 1a2686f..eb11632f 100644
>>>> --- a/tools/perf/tests/event-times.c
>>>> +++ b/tools/perf/tests/event-times.c
>>>> @@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
>>>> *evlist)
>>>> struct cpu_map *cpus;
>>>> int err;
>>>>
>>>> - pr_debug("attaching to CPU 0 as enabled\n");
>>>> + pr_debug("attaching to CPU 1 as disabled\n");
>>>>
>>>> - cpus = cpu_map__new("0");
>>>> + cpus = cpu_map__new("1");
>>>> if (cpus == NULL) {
>>>> pr_debug("failed to call cpu_map__new\n");
>>>> return -1;
>>>> @@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
>>>> *evlist)
>>>> struct cpu_map *cpus;
>>>> int err;
>>>>
>>>> - pr_debug("attaching to CPU 0 as enabled\n");
>>>> + pr_debug("attaching to CPU 1 as enabled\n");
>>>>
>>>> - cpus = cpu_map__new("0");
>>>> + cpus = cpu_map__new("1");
>>>> if (cpus == NULL) {
>>>> pr_debug("failed to call cpu_map__new\n");
>>>> return -1;
>>>>
>>>>
>>>> Palmer,
>>>> Would it be better to officially document it somewhere that CPU0 doesn't
>>>> exist in the HighFive Unleashed board ?
>>>> I fear that there will be other standard tests/code path that may fail
>>>> because of inherent assumption of cpu0 presence.
>>>
>>> I think the best way to fix this is to just have BBL (or whatever the
>>> bootloader is) renumber the CPUs so they're contiguous and begin with 0.
>>
>> Do you mean BBL will update the device tree that kernel eventually parse
>> and set the hart id?
>> Sounds good to me unless it acts as a big hack in future boot loaders.
>
> Right now the machine-mode and supervisor-mode hart IDs are logically separate:
> the bootloader just provides the hart ID as a register argument when starting
> the kernel.
Yes.
BBL already needs to enumerate the harts by looking through the
> device tree for various other reasons (at least to mask off the harts that
> Linux doesn't support), so it's not that much effort to just maintain a mapping
> from supervisor-mode hart IDs to machine-mode hart IDs.
>
But Linux also parses the device tree to get hart ID in
riscv_of_processor_hart(). This is used to setup the possible/present
cpu map in setup_smp().
Thus, Linux also need to see a device tree with cpu0-3 instead of
cpu1-4. Otherwise, present cpu map will be incorrect. Isn't it ?
> I have some patches floating around that do this, but appear to do it
> incorrectly enough that nothing boots so maybe I'm missing something that makes
> this complicated :).
>
Just a wild guess: May be the because of the above reason ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
From: Palmer Dabbelt @ 2018-04-25 0:29 UTC (permalink / raw)
To: atish.patra
Cc: alankao, albert, peterz, mingo, acme, alexander.shishkin, jolsa,
namhyung, sols, corbet, linux-riscv, linux-doc, linux-kernel,
greentime, nickhu
In-Reply-To: <054df682-c002-23ba-075b-a38c9085260c@wdc.com>
On Tue, 24 Apr 2018 15:16:16 PDT (-0700), atish.patra@wdc.com wrote:
> On 4/24/18 12:44 PM, Palmer Dabbelt wrote:
>> On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.patra@wdc.com wrote:
>>> On 4/24/18 11:07 AM, Atish Patra wrote:
>>>> On 4/19/18 4:28 PM, Alan Kao wrote:
>>>> However, I got an rcu-stall for the test "47: Event times".
>>>> # ./perf test -v 47
>>> Got it working. The test tries to attach the event to CPU0 which doesn't
>>> exist in HighFive Unleashed. Changing it to cpu1 works.
>>>
>>> diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
>>> index 1a2686f..eb11632f 100644
>>> --- a/tools/perf/tests/event-times.c
>>> +++ b/tools/perf/tests/event-times.c
>>> @@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
>>> *evlist)
>>> struct cpu_map *cpus;
>>> int err;
>>>
>>> - pr_debug("attaching to CPU 0 as enabled\n");
>>> + pr_debug("attaching to CPU 1 as disabled\n");
>>>
>>> - cpus = cpu_map__new("0");
>>> + cpus = cpu_map__new("1");
>>> if (cpus == NULL) {
>>> pr_debug("failed to call cpu_map__new\n");
>>> return -1;
>>> @@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
>>> *evlist)
>>> struct cpu_map *cpus;
>>> int err;
>>>
>>> - pr_debug("attaching to CPU 0 as enabled\n");
>>> + pr_debug("attaching to CPU 1 as enabled\n");
>>>
>>> - cpus = cpu_map__new("0");
>>> + cpus = cpu_map__new("1");
>>> if (cpus == NULL) {
>>> pr_debug("failed to call cpu_map__new\n");
>>> return -1;
>>>
>>>
>>> Palmer,
>>> Would it be better to officially document it somewhere that CPU0 doesn't
>>> exist in the HighFive Unleashed board ?
>>> I fear that there will be other standard tests/code path that may fail
>>> because of inherent assumption of cpu0 presence.
>>
>> I think the best way to fix this is to just have BBL (or whatever the
>> bootloader is) renumber the CPUs so they're contiguous and begin with 0.
>
> Do you mean BBL will update the device tree that kernel eventually parse
> and set the hart id?
> Sounds good to me unless it acts as a big hack in future boot loaders.
Right now the machine-mode and supervisor-mode hart IDs are logically separate:
the bootloader just provides the hart ID as a register argument when starting
the kernel. BBL already needs to enumerate the harts by looking through the
device tree for various other reasons (at least to mask off the harts that
Linux doesn't support), so it's not that much effort to just maintain a mapping
from supervisor-mode hart IDs to machine-mode hart IDs.
I have some patches floating around that do this, but appear to do it
incorrectly enough that nothing boots so maybe I'm missing something that makes
this complicated :).
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Documentation/i2c: direct users to i2c-tools regarding i2c/smbus.h
From: Sam Hansen @ 2018-04-25 0:00 UTC (permalink / raw)
To: linux-i2c, Jean Delvare, Sam Hansen, Wolfram Sang,
Jonathan Corbet, linux-doc, linux-kernel
In-Reply-To: <20180419222356.242535-1-hansens@google.com>
friendly ping :)
This was an incremental patch requested by Wolfram.
On Thu, Apr 19, 2018 at 3:23 PM, Sam Hansen <hansens@google.com> wrote:
> The current examples reference i2c/smbus.h, which is the first reference
> in Documentation/i2c/dev-interface to anything related to the i2c-tools
> project. This moves the existing reference to i2c-tools up into the
> C-example, directing the user to the project's git repository.
>
> Signed-off-by: Sam Hansen <hansens@google.com>
> ---
> Documentation/i2c/dev-interface | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
> index fbed645ccd75..ed20f7b7851a 100644
> --- a/Documentation/i2c/dev-interface
> +++ b/Documentation/i2c/dev-interface
> @@ -23,6 +23,10 @@ First, you need to include these two headers:
> #include <linux/i2c-dev.h>
> #include <i2c/smbus.h>
>
> +The i2c/smbus header file is provided by the i2c-tools project. For more info
> +about i2c-tools, see:
> +https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/
> +
> Now, you have to decide which adapter you want to access. You should
> inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
> Adapter numbers are assigned somewhat dynamically, so you can not
> @@ -163,10 +167,6 @@ what happened. The 'write' transactions return 0 on success; the
> returns the number of values read. The block buffers need not be longer
> than 32 bytes.
>
> -The above functions are made available by linking against the libi2c library,
> -which is provided by the i2c-tools project. See:
> -https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/.
> -
>
> Implementation details
> ======================
> --
> 2.17.0.484.g0c8726318c-goog
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
From: Atish Patra @ 2018-04-24 22:16 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: alankao@andestech.com, albert@sifive.com, peterz@infradead.org,
mingo@redhat.com, acme@kernel.org,
alexander.shishkin@linux.intel.com, jolsa@redhat.com,
namhyung@kernel.org, sols@sifive.com, corbet@lwn.net,
linux-riscv@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, greentime@andestech.com,
nickhu@andestech.com
In-Reply-To: <mhng-355dc09a-ef4a-4cb0-b7fe-c2ac57a04a5c@palmer-si-x1c4>
On 4/24/18 12:44 PM, Palmer Dabbelt wrote:
> On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.patra@wdc.com wrote:
>> On 4/24/18 11:07 AM, Atish Patra wrote:
>>> On 4/19/18 4:28 PM, Alan Kao wrote:
>>>> This implements the baseline PMU for RISC-V platforms.
>>>>
>>>> To ease future PMU portings, a guide is also written, containing
>>>> perf concepts, arch porting practices and some hints.
>>>>
>>>> Changes in v5:
>>>> - Fix patch errors from checkpatch.pl.
>>>>
>>>> Changes in v4:
>>>> - Fix several compilation errors. Sorry for that.
>>>> - Raise a warning in the write_counter body.
>>>>
>>>> Changes in v3:
>>>> - Fix typos in the document.
>>>> - Change the initialization routine from statically assigning PMU to
>>>> device-tree-based methods, and set default to the PMU proposed in
>>>> this patch.
>>>>
>>>> Changes in v2:
>>>> - Fix the bug reported by Alex, which was caused by not sufficient
>>>> initialization. Check https://lkml.org/lkml/2018/3/31/251 for the
>>>> discussion.
>>>>
>>>> Alan Kao (2):
>>>> perf: riscv: preliminary RISC-V support
>>>> perf: riscv: Add Document for Future Porting Guide
>>>>
>>>> Documentation/riscv/pmu.txt | 249 ++++++++++++++
>>>> arch/riscv/Kconfig | 13 +
>>>> arch/riscv/include/asm/perf_event.h | 79 ++++-
>>>> arch/riscv/kernel/Makefile | 1 +
>>>> arch/riscv/kernel/perf_event.c | 485 ++++++++++++++++++++++++++++
>>>> 5 files changed, 823 insertions(+), 4 deletions(-)
>>>> create mode 100644 Documentation/riscv/pmu.txt
>>>> create mode 100644 arch/riscv/kernel/perf_event.c
>>>>
>>> Most of the perf tests either pass or fail because of unsupported
>>> event/trace point which is fine.
>>>
>>> However, I got an rcu-stall for the test "47: Event times".
>>> # ./perf test -v 47
>>> 47: Event times :
>>> --- start ---
>>> test child forked, pid 2774
>>> attaching to spawned child, enable on exec
>>> OK : ena 2243000, run 2243000
>>> attaching to current thread as enabled
>>> OK : ena 19000, run 19000
>>> attaching to current thread as disabled
>>> OK : ena 5000, run 5000
>>> attaching to CPU 0 as enabled
>>> [ 1001.466578] INFO: rcu_sched self-detected stall on CPU
>>> [ 1001.470947] 4-....: (29999 ticks this GP) idle=5fa/140000000000001/0
>>> softirq=19762/19762 fqs=14602
>>> [ 1001.480053] (t=30001 jiffies g=3471 c=3470 q=125)
>>> [ 1001.484917] Task dump for CPU 4:
>>> [ 1001.488129] perf R running task 0 2774 2773
>>> 0x00000008
>>> [ 1001.495161] Call Trace:
>>> [ 1001.497606] [<000000006a3d4f87>] walk_stackframe+0x0/0xc0
>>> [ 1001.502980] [<000000004b4b0780>] show_stack+0x3c/0x46
>>> [ 1001.508024] [<0000000060c96ab8>] sched_show_task+0xd0/0x122
>>> [ 1001.513573] [<000000007d8bd54e>] dump_cpu_task+0x50/0x5a
>>> [ 1001.518870] [<0000000053990e11>] rcu_dump_cpu_stacks+0x98/0xd2
>>> [ 1001.524685] [<00000000fe94c593>] rcu_check_callbacks+0x614/0x822
>>> [ 1001.530680] [<0000000057688dd3>] update_process_times+0x38/0x6a
>>> [ 1001.536585] [<0000000063a96de0>] tick_periodic+0x58/0xd8
>>> [ 1001.541876] [<0000000013d712f1>] tick_handle_periodic+0x2e/0x7c
>>> [ 1001.547780] [<000000009e2ef428>] riscv_timer_interrupt+0x34/0x3c
>>> [ 1001.553774] [<00000000ff6b1f18>] riscv_intc_irq+0xbc/0xe0
>>> [ 1001.559153] [<00000000c8614c3b>] ret_from_exception+0x0/0xc
>>>
>>> It is quite possible that we don't support some dependency
>>> infrastructure. I am looking into it.
>>>
>>> Regards,
>>> Atish
>>>
>>>
>>>
>>>
>>>
>>
>> Got it working. The test tries to attach the event to CPU0 which doesn't
>> exist in HighFive Unleashed. Changing it to cpu1 works.
>>
>> diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
>> index 1a2686f..eb11632f 100644
>> --- a/tools/perf/tests/event-times.c
>> +++ b/tools/perf/tests/event-times.c
>> @@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
>> *evlist)
>> struct cpu_map *cpus;
>> int err;
>>
>> - pr_debug("attaching to CPU 0 as enabled\n");
>> + pr_debug("attaching to CPU 1 as disabled\n");
>>
>> - cpus = cpu_map__new("0");
>> + cpus = cpu_map__new("1");
>> if (cpus == NULL) {
>> pr_debug("failed to call cpu_map__new\n");
>> return -1;
>> @@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
>> *evlist)
>> struct cpu_map *cpus;
>> int err;
>>
>> - pr_debug("attaching to CPU 0 as enabled\n");
>> + pr_debug("attaching to CPU 1 as enabled\n");
>>
>> - cpus = cpu_map__new("0");
>> + cpus = cpu_map__new("1");
>> if (cpus == NULL) {
>> pr_debug("failed to call cpu_map__new\n");
>> return -1;
>>
>>
>> Palmer,
>> Would it be better to officially document it somewhere that CPU0 doesn't
>> exist in the HighFive Unleashed board ?
>> I fear that there will be other standard tests/code path that may fail
>> because of inherent assumption of cpu0 presence.
>
> I think the best way to fix this is to just have BBL (or whatever the
> bootloader is) renumber the CPUs so they're contiguous and begin with 0.
Do you mean BBL will update the device tree that kernel eventually parse
and set the hart id?
Sounds good to me unless it acts as a big hack in future boot loaders.
> Documenting it it just a way to tell people their code needs to be changed,
> it'll still break.
>
Agreed.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/7] powerpc: use task_pid_nr() for TID allocation
From: Sukadev Bhattiprolu @ 2018-04-24 21:12 UTC (permalink / raw)
To: Andrew Donnellan
Cc: Alastair D'Silva, linuxppc-dev, linux-kernel, linux-doc,
mikey, vaibhav, aneesh.kumar, malat, felix, pombredanne, sukadev,
npiggin, gregkh, arnd, fbarrat, corbet, Alastair D'Silva,
Christophe Lombard
In-Reply-To: <b088d063-058a-2557-812c-6d5659f9d67b@au1.ibm.com>
Andrew Donnellan [andrew.donnellan@au1.ibm.com] wrote:
> [+ Sukadev, Christophe]
>
> On 18/04/18 11:08, Alastair D'Silva wrote:
> > From: Alastair D'Silva <alastair@d-silva.org>
> >
> > The current implementation of TID allocation, using a global IDR, may
> > result in an errant process starving the system of available TIDs.
> > Instead, use task_pid_nr(), as mentioned by the original author. The
> > scenario described which prevented it's use is not applicable, as
> > set_thread_tidr can only be called after the task struct has been
> > populated.
> >
> > Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
>
> So it's too late in the evening for me to completely get my head around
> what's going on here enough to give my Reviewed-by:, but my current thinking
> is:
>
> - In the first version of the patch to add TIDR support
> (https://patchwork.ozlabs.org/patch/799494/), it was originally proposed to
> call assign_thread_id() (as it was then called) from copy_thread()
>
> - The comment block documents the reason why we can't use task_pid_nr() but
> assumes that we're trying to assign a TIDR from within copy_thread()
>
> - The final patch that was accepted
> (https://patchwork.ozlabs.org/patch/835552/,
> ec233ede4c8654894610ea54f4dae7adc954ac62) instead sets the TIDR to 0 from
> copy_thread(), so the original reasoning regarding not using task_pid_nr()
> within copy_thread() is no longer applicable.
>
> Sukadev: does this sound right?
Yes. Like with PIDR, was trying to assign TIDR initially to all threads.
But since only a subset of threads need/use TIDR, we can assign the
value later (when set_thread_tidr() is called). So we should be able to
use task_pid_nr() then.
Sukadev
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
From: Palmer Dabbelt @ 2018-04-24 19:44 UTC (permalink / raw)
To: atish.patra
Cc: alankao, albert, peterz, mingo, acme, alexander.shishkin, jolsa,
namhyung, sols, corbet, linux-riscv, linux-doc, linux-kernel,
greentime, nickhu
In-Reply-To: <661405fd-7b23-5f95-568d-0e2eb1925217@wdc.com>
On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.patra@wdc.com wrote:
> On 4/24/18 11:07 AM, Atish Patra wrote:
>> On 4/19/18 4:28 PM, Alan Kao wrote:
>>> This implements the baseline PMU for RISC-V platforms.
>>>
>>> To ease future PMU portings, a guide is also written, containing
>>> perf concepts, arch porting practices and some hints.
>>>
>>> Changes in v5:
>>> - Fix patch errors from checkpatch.pl.
>>>
>>> Changes in v4:
>>> - Fix several compilation errors. Sorry for that.
>>> - Raise a warning in the write_counter body.
>>>
>>> Changes in v3:
>>> - Fix typos in the document.
>>> - Change the initialization routine from statically assigning PMU to
>>> device-tree-based methods, and set default to the PMU proposed in
>>> this patch.
>>>
>>> Changes in v2:
>>> - Fix the bug reported by Alex, which was caused by not sufficient
>>> initialization. Check https://lkml.org/lkml/2018/3/31/251 for the
>>> discussion.
>>>
>>> Alan Kao (2):
>>> perf: riscv: preliminary RISC-V support
>>> perf: riscv: Add Document for Future Porting Guide
>>>
>>> Documentation/riscv/pmu.txt | 249 ++++++++++++++
>>> arch/riscv/Kconfig | 13 +
>>> arch/riscv/include/asm/perf_event.h | 79 ++++-
>>> arch/riscv/kernel/Makefile | 1 +
>>> arch/riscv/kernel/perf_event.c | 485 ++++++++++++++++++++++++++++
>>> 5 files changed, 823 insertions(+), 4 deletions(-)
>>> create mode 100644 Documentation/riscv/pmu.txt
>>> create mode 100644 arch/riscv/kernel/perf_event.c
>>>
>> Most of the perf tests either pass or fail because of unsupported
>> event/trace point which is fine.
>>
>> However, I got an rcu-stall for the test "47: Event times".
>> # ./perf test -v 47
>> 47: Event times :
>> --- start ---
>> test child forked, pid 2774
>> attaching to spawned child, enable on exec
>> OK : ena 2243000, run 2243000
>> attaching to current thread as enabled
>> OK : ena 19000, run 19000
>> attaching to current thread as disabled
>> OK : ena 5000, run 5000
>> attaching to CPU 0 as enabled
>> [ 1001.466578] INFO: rcu_sched self-detected stall on CPU
>> [ 1001.470947] 4-....: (29999 ticks this GP) idle=5fa/140000000000001/0
>> softirq=19762/19762 fqs=14602
>> [ 1001.480053] (t=30001 jiffies g=3471 c=3470 q=125)
>> [ 1001.484917] Task dump for CPU 4:
>> [ 1001.488129] perf R running task 0 2774 2773
>> 0x00000008
>> [ 1001.495161] Call Trace:
>> [ 1001.497606] [<000000006a3d4f87>] walk_stackframe+0x0/0xc0
>> [ 1001.502980] [<000000004b4b0780>] show_stack+0x3c/0x46
>> [ 1001.508024] [<0000000060c96ab8>] sched_show_task+0xd0/0x122
>> [ 1001.513573] [<000000007d8bd54e>] dump_cpu_task+0x50/0x5a
>> [ 1001.518870] [<0000000053990e11>] rcu_dump_cpu_stacks+0x98/0xd2
>> [ 1001.524685] [<00000000fe94c593>] rcu_check_callbacks+0x614/0x822
>> [ 1001.530680] [<0000000057688dd3>] update_process_times+0x38/0x6a
>> [ 1001.536585] [<0000000063a96de0>] tick_periodic+0x58/0xd8
>> [ 1001.541876] [<0000000013d712f1>] tick_handle_periodic+0x2e/0x7c
>> [ 1001.547780] [<000000009e2ef428>] riscv_timer_interrupt+0x34/0x3c
>> [ 1001.553774] [<00000000ff6b1f18>] riscv_intc_irq+0xbc/0xe0
>> [ 1001.559153] [<00000000c8614c3b>] ret_from_exception+0x0/0xc
>>
>> It is quite possible that we don't support some dependency
>> infrastructure. I am looking into it.
>>
>> Regards,
>> Atish
>>
>>
>>
>>
>>
>
> Got it working. The test tries to attach the event to CPU0 which doesn't
> exist in HighFive Unleashed. Changing it to cpu1 works.
>
> diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
> index 1a2686f..eb11632f 100644
> --- a/tools/perf/tests/event-times.c
> +++ b/tools/perf/tests/event-times.c
> @@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
> *evlist)
> struct cpu_map *cpus;
> int err;
>
> - pr_debug("attaching to CPU 0 as enabled\n");
> + pr_debug("attaching to CPU 1 as disabled\n");
>
> - cpus = cpu_map__new("0");
> + cpus = cpu_map__new("1");
> if (cpus == NULL) {
> pr_debug("failed to call cpu_map__new\n");
> return -1;
> @@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
> *evlist)
> struct cpu_map *cpus;
> int err;
>
> - pr_debug("attaching to CPU 0 as enabled\n");
> + pr_debug("attaching to CPU 1 as enabled\n");
>
> - cpus = cpu_map__new("0");
> + cpus = cpu_map__new("1");
> if (cpus == NULL) {
> pr_debug("failed to call cpu_map__new\n");
> return -1;
>
>
> Palmer,
> Would it be better to officially document it somewhere that CPU0 doesn't
> exist in the HighFive Unleashed board ?
> I fear that there will be other standard tests/code path that may fail
> because of inherent assumption of cpu0 presence.
I think the best way to fix this is to just have BBL (or whatever the
bootloader is) renumber the CPUs so they're contiguous and begin with 0.
Documenting it it just a way to tell people their code needs to be changed,
it'll still break.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] doc: dev-tools: kselftest.rst: update contributing new tests
From: Shuah Khan @ 2018-04-24 19:35 UTC (permalink / raw)
To: Anders Roxell, corbet
Cc: linux-kselftest, linux-doc, linux-kernel, Shuah Khan
In-Reply-To: <20180419102825.2990-1-anders.roxell@linaro.org>
On 04/19/2018 04:28 AM, Anders Roxell wrote:
> Add a description that the kernel headers should be used as far as it is
> possible and then the system headers.
>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
> ---
> Documentation/dev-tools/kselftest.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst
> index e80850eefe13..3bf371a938d0 100644
> --- a/Documentation/dev-tools/kselftest.rst
> +++ b/Documentation/dev-tools/kselftest.rst
> @@ -151,6 +151,11 @@ Contributing new tests (details)
> TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
> test.
>
> + * First use the headers inside the kernel source and/or git repo, and then the
> + system headers. Headers for the kernel release as opposed to headers
> + installed by the distro on the system should be the primary focus to be able
> + to find regressions.
> +
> Test Harness
> ============
>
>
Here is my reviewed by for this to go through documentation tree.
Reviewed-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
thanks,
-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
From: Atish Patra @ 2018-04-24 19:27 UTC (permalink / raw)
To: Alan Kao, Palmer Dabbelt, Albert Ou, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Alex Solomatnikov, Jonathan Corbet,
linux-riscv@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Greentime Hu, Nick Hu
In-Reply-To: <c352b159-4bed-8ee6-d7fc-4c82c17e29be@wdc.com>
On 4/24/18 11:07 AM, Atish Patra wrote:
> On 4/19/18 4:28 PM, Alan Kao wrote:
>> This implements the baseline PMU for RISC-V platforms.
>>
>> To ease future PMU portings, a guide is also written, containing
>> perf concepts, arch porting practices and some hints.
>>
>> Changes in v5:
>> - Fix patch errors from checkpatch.pl.
>>
>> Changes in v4:
>> - Fix several compilation errors. Sorry for that.
>> - Raise a warning in the write_counter body.
>>
>> Changes in v3:
>> - Fix typos in the document.
>> - Change the initialization routine from statically assigning PMU to
>> device-tree-based methods, and set default to the PMU proposed in
>> this patch.
>>
>> Changes in v2:
>> - Fix the bug reported by Alex, which was caused by not sufficient
>> initialization. Check https://lkml.org/lkml/2018/3/31/251 for the
>> discussion.
>>
>> Alan Kao (2):
>> perf: riscv: preliminary RISC-V support
>> perf: riscv: Add Document for Future Porting Guide
>>
>> Documentation/riscv/pmu.txt | 249 ++++++++++++++
>> arch/riscv/Kconfig | 13 +
>> arch/riscv/include/asm/perf_event.h | 79 ++++-
>> arch/riscv/kernel/Makefile | 1 +
>> arch/riscv/kernel/perf_event.c | 485 ++++++++++++++++++++++++++++
>> 5 files changed, 823 insertions(+), 4 deletions(-)
>> create mode 100644 Documentation/riscv/pmu.txt
>> create mode 100644 arch/riscv/kernel/perf_event.c
>>
> Most of the perf tests either pass or fail because of unsupported
> event/trace point which is fine.
>
> However, I got an rcu-stall for the test "47: Event times".
> # ./perf test -v 47
> 47: Event times :
> --- start ---
> test child forked, pid 2774
> attaching to spawned child, enable on exec
> OK : ena 2243000, run 2243000
> attaching to current thread as enabled
> OK : ena 19000, run 19000
> attaching to current thread as disabled
> OK : ena 5000, run 5000
> attaching to CPU 0 as enabled
> [ 1001.466578] INFO: rcu_sched self-detected stall on CPU
> [ 1001.470947] 4-....: (29999 ticks this GP) idle=5fa/140000000000001/0
> softirq=19762/19762 fqs=14602
> [ 1001.480053] (t=30001 jiffies g=3471 c=3470 q=125)
> [ 1001.484917] Task dump for CPU 4:
> [ 1001.488129] perf R running task 0 2774 2773
> 0x00000008
> [ 1001.495161] Call Trace:
> [ 1001.497606] [<000000006a3d4f87>] walk_stackframe+0x0/0xc0
> [ 1001.502980] [<000000004b4b0780>] show_stack+0x3c/0x46
> [ 1001.508024] [<0000000060c96ab8>] sched_show_task+0xd0/0x122
> [ 1001.513573] [<000000007d8bd54e>] dump_cpu_task+0x50/0x5a
> [ 1001.518870] [<0000000053990e11>] rcu_dump_cpu_stacks+0x98/0xd2
> [ 1001.524685] [<00000000fe94c593>] rcu_check_callbacks+0x614/0x822
> [ 1001.530680] [<0000000057688dd3>] update_process_times+0x38/0x6a
> [ 1001.536585] [<0000000063a96de0>] tick_periodic+0x58/0xd8
> [ 1001.541876] [<0000000013d712f1>] tick_handle_periodic+0x2e/0x7c
> [ 1001.547780] [<000000009e2ef428>] riscv_timer_interrupt+0x34/0x3c
> [ 1001.553774] [<00000000ff6b1f18>] riscv_intc_irq+0xbc/0xe0
> [ 1001.559153] [<00000000c8614c3b>] ret_from_exception+0x0/0xc
>
> It is quite possible that we don't support some dependency
> infrastructure. I am looking into it.
>
> Regards,
> Atish
>
>
>
>
>
Got it working. The test tries to attach the event to CPU0 which doesn't
exist in HighFive Unleashed. Changing it to cpu1 works.
diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
index 1a2686f..eb11632f 100644
--- a/tools/perf/tests/event-times.c
+++ b/tools/perf/tests/event-times.c
@@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
*evlist)
struct cpu_map *cpus;
int err;
- pr_debug("attaching to CPU 0 as enabled\n");
+ pr_debug("attaching to CPU 1 as disabled\n");
- cpus = cpu_map__new("0");
+ cpus = cpu_map__new("1");
if (cpus == NULL) {
pr_debug("failed to call cpu_map__new\n");
return -1;
@@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
*evlist)
struct cpu_map *cpus;
int err;
- pr_debug("attaching to CPU 0 as enabled\n");
+ pr_debug("attaching to CPU 1 as enabled\n");
- cpus = cpu_map__new("0");
+ cpus = cpu_map__new("1");
if (cpus == NULL) {
pr_debug("failed to call cpu_map__new\n");
return -1;
Palmer,
Would it be better to officially document it somewhere that CPU0 doesn't
exist in the HighFive Unleashed board ?
I fear that there will be other standard tests/code path that may fail
because of inherent assumption of cpu0 presence.
Regards,
Atish
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
From: Atish Patra @ 2018-04-24 18:07 UTC (permalink / raw)
To: Alan Kao, Palmer Dabbelt, Albert Ou, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Alex Solomatnikov, Jonathan Corbet,
linux-riscv@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Greentime Hu, Nick Hu
In-Reply-To: <1524180470-8622-1-git-send-email-alankao@andestech.com>
On 4/19/18 4:28 PM, Alan Kao wrote:
> This implements the baseline PMU for RISC-V platforms.
>
> To ease future PMU portings, a guide is also written, containing
> perf concepts, arch porting practices and some hints.
>
> Changes in v5:
> - Fix patch errors from checkpatch.pl.
>
> Changes in v4:
> - Fix several compilation errors. Sorry for that.
> - Raise a warning in the write_counter body.
>
> Changes in v3:
> - Fix typos in the document.
> - Change the initialization routine from statically assigning PMU to
> device-tree-based methods, and set default to the PMU proposed in
> this patch.
>
> Changes in v2:
> - Fix the bug reported by Alex, which was caused by not sufficient
> initialization. Check https://lkml.org/lkml/2018/3/31/251 for the
> discussion.
>
> Alan Kao (2):
> perf: riscv: preliminary RISC-V support
> perf: riscv: Add Document for Future Porting Guide
>
> Documentation/riscv/pmu.txt | 249 ++++++++++++++
> arch/riscv/Kconfig | 13 +
> arch/riscv/include/asm/perf_event.h | 79 ++++-
> arch/riscv/kernel/Makefile | 1 +
> arch/riscv/kernel/perf_event.c | 485 ++++++++++++++++++++++++++++
> 5 files changed, 823 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/riscv/pmu.txt
> create mode 100644 arch/riscv/kernel/perf_event.c
>
Most of the perf tests either pass or fail because of unsupported
event/trace point which is fine.
However, I got an rcu-stall for the test "47: Event times".
# ./perf test -v 47
47: Event times :
--- start ---
test child forked, pid 2774
attaching to spawned child, enable on exec
OK : ena 2243000, run 2243000
attaching to current thread as enabled
OK : ena 19000, run 19000
attaching to current thread as disabled
OK : ena 5000, run 5000
attaching to CPU 0 as enabled
[ 1001.466578] INFO: rcu_sched self-detected stall on CPU
[ 1001.470947] 4-....: (29999 ticks this GP) idle=5fa/140000000000001/0
softirq=19762/19762 fqs=14602
[ 1001.480053] (t=30001 jiffies g=3471 c=3470 q=125)
[ 1001.484917] Task dump for CPU 4:
[ 1001.488129] perf R running task 0 2774 2773
0x00000008
[ 1001.495161] Call Trace:
[ 1001.497606] [<000000006a3d4f87>] walk_stackframe+0x0/0xc0
[ 1001.502980] [<000000004b4b0780>] show_stack+0x3c/0x46
[ 1001.508024] [<0000000060c96ab8>] sched_show_task+0xd0/0x122
[ 1001.513573] [<000000007d8bd54e>] dump_cpu_task+0x50/0x5a
[ 1001.518870] [<0000000053990e11>] rcu_dump_cpu_stacks+0x98/0xd2
[ 1001.524685] [<00000000fe94c593>] rcu_check_callbacks+0x614/0x822
[ 1001.530680] [<0000000057688dd3>] update_process_times+0x38/0x6a
[ 1001.536585] [<0000000063a96de0>] tick_periodic+0x58/0xd8
[ 1001.541876] [<0000000013d712f1>] tick_handle_periodic+0x2e/0x7c
[ 1001.547780] [<000000009e2ef428>] riscv_timer_interrupt+0x34/0x3c
[ 1001.553774] [<00000000ff6b1f18>] riscv_intc_irq+0xbc/0xe0
[ 1001.559153] [<00000000c8614c3b>] ret_from_exception+0x0/0xc
It is quite possible that we don't support some dependency
infrastructure. I am looking into it.
Regards,
Atish
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 10/10] tools: PCI: Add MSI-X support
From: Gustavo Pimentel @ 2018-04-24 17:18 UTC (permalink / raw)
To: Alan Douglas, bhelgaas@google.com, lorenzo.pieralisi@arm.com,
Joao.Pinto@synopsys.com, jingoohan1@gmail.com, kishon@ti.com,
niklas.cassel@axis.com, jesper.nilsson@axis.com
Cc: linux-pci@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <SN6PR07MB45126298F09735193B0F0F00D8880@SN6PR07MB4512.namprd07.prod.outlook.com>
Hi Alan,
On 24/04/2018 10:57, Alan Douglas wrote:
> Hi Gustavo,
>
> On 10 April 2018 18:15, Gustavo Pimentel wrote:
>> Adds MSI-X support to the pcitest tool and modified the pcitest.sh script to
>> accomodate this new type of interruption test.
>>
>> Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
>> ---
>> include/uapi/linux/pcitest.h | 1 +
>> tools/pci/pcitest.c | 18 +++++++++++++++++-
>> tools/pci/pcitest.sh | 25 +++++++++++++++++++++++++
>> 3 files changed, 43 insertions(+), 1 deletion(-)
> I found some possible problems when testing with the Cadence EP driver. The problem
> is that pcitest uses the BARs for tests, but we also use one for the MSI-X tables
>
> In Cadence core the MSI-X table is in BAR0 by default, but this is configured to a size
> of 0x80 in the test driver, since it is used as the test_reg_bar. So, I changed the
> configuration to use BAR4 instead, which is configured to a size of 131072
> in pci-efp-test.c, and this gives me enough space.
>
> However, if I run the BAR tests in pcitest before running the MSI-X tests, the
> MSI-X tests fail, since the BAR content is overwritten. It's not a problem with the
> scenario in pcitest.sh, but it would be if the module wasn't re-loaded.
>
> So, wondering if we need to come up with some mechanism to specify that a specific
> BAR will be used for MSI-X, and that its size and content shouldn't be modified by
> pcitest?
I see your point. I have bypassed the problem by doing the module load/unload
(to avoid having to fight on multiple fronts).
I like your suggestion. Maybe we could have a bool variable for each BARs that
could be set to false if a resource have intent to use it.
However this change must be accepted by Kishon.
>
> Regards,
> Alan
>
Regards,
Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 03/10] drivers/peci: Add support for PECI bus driver core
From: Jae Hyun Yoo @ 2018-04-24 16:29 UTC (permalink / raw)
To: Andy Shevchenko, Alan Cox, Andrew Jeffery, Andrew Lunn,
Arnd Bergmann, Benjamin Herrenschmidt, Fengguang Wu, Greg KH,
Guenter Roeck, Haiyue Wang, James Feist, Jason M Biils,
Jean Delvare, Joel Stanley, Julia Cartwright, Miguel Ojeda,
Milton Miller II, Pavel Machek, Randy Dunlap, Stef van Os,
Sumeet R Pawnikar, Vernon Mauery
Cc: linux-kernel, linux-doc, devicetree, linux-hwmon,
linux-arm-kernel, openbmc
In-Reply-To: <1524585717.21176.504.camel@linux.intel.com>
On 4/24/2018 9:01 AM, Andy Shevchenko wrote:
> On Tue, 2018-04-10 at 11:32 -0700, Jae Hyun Yoo wrote:
>> This commit adds driver implementation for PECI bus core into linux
>> driver framework.
>>
>
> All comments you got for patch 6 are applicable here.
>
> And perhaps in the rest of the series.
>
> The rule of thumb: when you get even single comment in a certain place,
> re-check _entire_ series for the same / similar patterns!
>
Thanks for your advice. I'll keep that in mind.
Jae
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers
From: Jae Hyun Yoo @ 2018-04-24 16:26 UTC (permalink / raw)
To: Andy Shevchenko, Alan Cox, Andrew Jeffery, Andrew Lunn,
Arnd Bergmann, Benjamin Herrenschmidt, Fengguang Wu, Greg KH,
Guenter Roeck, Haiyue Wang, James Feist, Jason M Biils,
Jean Delvare, Joel Stanley, Julia Cartwright, Miguel Ojeda,
Milton Miller II, Pavel Machek, Randy Dunlap, Stef van Os,
Sumeet R Pawnikar, Vernon Mauery
Cc: linux-kernel, linux-doc, devicetree, linux-hwmon,
linux-arm-kernel, openbmc
In-Reply-To: <1524585397.21176.502.camel@linux.intel.com>
Hi Andy,
Thanks a lot for your review. Please check my inline answers.
On 4/24/2018 8:56 AM, Andy Shevchenko wrote:
> On Tue, 2018-04-10 at 11:32 -0700, Jae Hyun Yoo wrote:
>
>> drivers/hwmon/peci-cputemp.c | 783
>> ++++++++++++++++++++++++++++++++++++++++++
>> drivers/hwmon/peci-dimmtemp.c | 432 +++++++++++++++++++++++
>
> Does it make sense one driver per patch?
>
Yes, I'll separate it into two patches.
>> +#define CLIENT_CPU_ID_MASK 0xf0ff0 /* Mask for Family / Model
>> info */
>
>> +struct cpu_gen_info {
>> + u32 type;
>> + u32 cpu_id;
>> + u32 core_max;
>> +};
>>
>
>> +static const struct cpu_gen_info cpu_gen_info_table[] = {
>> + { .type = CPU_GEN_HSX,
>> + .cpu_id = 0x306f0, /* Family code: 6, Model number: 63
>> (0x3f) */
>> + .core_max = CORE_MAX_ON_HSX },
>> + { .type = CPU_GEN_BRX,
>> + .cpu_id = 0x406f0, /* Family code: 6, Model number: 79
>> (0x4f) */
>> + .core_max = CORE_MAX_ON_BDX },
>> + { .type = CPU_GEN_SKX,
>> + .cpu_id = 0x50650, /* Family code: 6, Model number: 85
>> (0x55) */
>> + .core_max = CORE_MAX_ON_SKX },
>> +};
>
> Are we talking about x86 CPU IDs here?
> If so, why x86 corresponding headers, including intel-family.h are not
> used?
>
Yes, that would make more sense. I'll include the intel-family.h and
will use these defines instead:
INTEL_FAM6_HASWELL_X
INTEL_FAM6_BROADWELL_X
INTEL_FAM6_SKYLAKE_X
Thanks,
Jae
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 03/10] drivers/peci: Add support for PECI bus driver core
From: Andy Shevchenko @ 2018-04-24 16:01 UTC (permalink / raw)
To: Jae Hyun Yoo, Alan Cox, Andrew Jeffery, Andrew Lunn,
Arnd Bergmann, Benjamin Herrenschmidt, Fengguang Wu, Greg KH,
Guenter Roeck, Haiyue Wang, James Feist, Jason M Biils,
Jean Delvare, Joel Stanley, Julia Cartwright, Miguel Ojeda,
Milton Miller II, Pavel Machek, Randy Dunlap, Stef van Os,
Sumeet R Pawnikar, Vernon Mauery
Cc: linux-kernel, linux-doc, devicetree, linux-hwmon,
linux-arm-kernel, openbmc
In-Reply-To: <20180410183212.16787-4-jae.hyun.yoo@linux.intel.com>
On Tue, 2018-04-10 at 11:32 -0700, Jae Hyun Yoo wrote:
> This commit adds driver implementation for PECI bus core into linux
> driver framework.
>
All comments you got for patch 6 are applicable here.
And perhaps in the rest of the series.
The rule of thumb: when you get even single comment in a certain place,
re-check _entire_ series for the same / similar patterns!
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox