All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/8] ARM: dts: porter: Add missing PMIC nodes
From: Simon Horman @ 2018-07-23 12:06 UTC (permalink / raw)
  To: linux-renesas-soc
  Cc: linux-arm-kernel, Magnus Damm, Marek Vasut, Marek Vasut,
	Simon Horman
In-Reply-To: <cover.1532345886.git.horms+renesas@verge.net.au>

From: Marek Vasut <marek.vasut@gmail.com>

Add PMIC nodes to Porter and connect CPU DVFS supply. There is
one DA9063L and one DA9210 on Porter, the only difference from
the other boards is that DA9063L is at I2C address 0x5a rather
than 0x58 .

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/boot/dts/r8a7791-porter.dts | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index a01101b49d99..5f77d73d7462 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -375,10 +375,43 @@
 	clock-frequency = <400000>;
 };
 
+&i2c6 {
+	status = "okay";
+	clock-frequency = <100000>;
+
+	pmic@5a {
+		compatible = "dlg,da9063l";
+		reg = <0x5a>;
+		interrupt-parent = <&irqc0>;
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-controller;
+
+		wdt {
+			compatible = "dlg,da9063-watchdog";
+		};
+	};
+
+	vdd_dvfs: regulator@68 {
+		compatible = "dlg,da9210";
+		reg = <0x68>;
+		interrupt-parent = <&irqc0>;
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+		regulator-min-microvolt = <1000000>;
+		regulator-max-microvolt = <1000000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+};
+
 &sata0 {
 	status = "okay";
 };
 
+&cpu0 {
+	cpu0-supply = <&vdd_dvfs>;
+};
+
 /* composite video input */
 &vin0 {
 	status = "okay";
-- 
2.11.0

^ permalink raw reply related

* [PATCH 2/8] ARM: dts: r8a77(43|9[013]): Add missing OPP properties for CPUs
From: Simon Horman @ 2018-07-23 12:06 UTC (permalink / raw)
  To: linux-renesas-soc
  Cc: linux-arm-kernel, Magnus Damm, Viresh Kumar, Simon Horman
In-Reply-To: <cover.1532345886.git.horms+renesas@verge.net.au>

From: Viresh Kumar <viresh.kumar@linaro.org>

The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.

Add such missing properties.

Fix other missing properties (like, clock latency, voltage tolerance,
etc) as well to make it all work.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/boot/dts/r8a7743.dtsi |  9 +++++++++
 arch/arm/boot/dts/r8a7790.dtsi | 34 ++++++++++++++++++++++++++++++++--
 arch/arm/boot/dts/r8a7791.dtsi | 14 ++++++++++++--
 arch/arm/boot/dts/r8a7793.dtsi | 15 +++++++++++++--
 4 files changed, 66 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 142949d7066f..e4fb31c4f0ee 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -98,8 +98,17 @@
 			reg = <1>;
 			clock-frequency = <1500000000>;
 			clocks = <&cpg CPG_CORE R8A7743_CLK_Z>;
+			clock-latency = <300000>; /* 300 us */
 			power-domains = <&sysc R8A7743_PD_CA15_CPU1>;
 			next-level-cache = <&L2_CA15>;
+
+			/* kHz - uV - OPPs unknown yet */
+			operating-points = <1500000 1000000>,
+					   <1312500 1000000>,
+					   <1125000 1000000>,
+					   < 937500 1000000>,
+					   < 750000 1000000>,
+					   < 375000 1000000>;
 		};
 
 		L2_CA15: cache-controller-0 {
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 4d06b154bd7e..c4324b1a2ec4 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -79,12 +79,12 @@
 			compatible = "arm,cortex-a15";
 			reg = <0>;
 			clock-frequency = <1300000000>;
-			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg CPG_CORE R8A7790_CLK_Z>;
-			clock-latency = <300000>; /* 300 us */
 			power-domains = <&sysc R8A7790_PD_CA15_CPU0>;
 			next-level-cache = <&L2_CA15>;
 			capacity-dmips-mhz = <1024>;
+			voltage-tolerance = <1>; /* 1% */
+			clock-latency = <300000>; /* 300 us */
 
 			/* kHz - uV - OPPs unknown yet */
 			operating-points = <1400000 1000000>,
@@ -104,6 +104,16 @@
 			power-domains = <&sysc R8A7790_PD_CA15_CPU1>;
 			next-level-cache = <&L2_CA15>;
 			capacity-dmips-mhz = <1024>;
+			voltage-tolerance = <1>; /* 1% */
+			clock-latency = <300000>; /* 300 us */
+
+			/* kHz - uV - OPPs unknown yet */
+			operating-points = <1400000 1000000>,
+					   <1225000 1000000>,
+					   <1050000 1000000>,
+					   < 875000 1000000>,
+					   < 700000 1000000>,
+					   < 350000 1000000>;
 		};
 
 		cpu2: cpu@2 {
@@ -115,6 +125,16 @@
 			power-domains = <&sysc R8A7790_PD_CA15_CPU2>;
 			next-level-cache = <&L2_CA15>;
 			capacity-dmips-mhz = <1024>;
+			voltage-tolerance = <1>; /* 1% */
+			clock-latency = <300000>; /* 300 us */
+
+			/* kHz - uV - OPPs unknown yet */
+			operating-points = <1400000 1000000>,
+					   <1225000 1000000>,
+					   <1050000 1000000>,
+					   < 875000 1000000>,
+					   < 700000 1000000>,
+					   < 350000 1000000>;
 		};
 
 		cpu3: cpu@3 {
@@ -126,6 +146,16 @@
 			power-domains = <&sysc R8A7790_PD_CA15_CPU3>;
 			next-level-cache = <&L2_CA15>;
 			capacity-dmips-mhz = <1024>;
+			voltage-tolerance = <1>; /* 1% */
+			clock-latency = <300000>; /* 300 us */
+
+			/* kHz - uV - OPPs unknown yet */
+			operating-points = <1400000 1000000>,
+					   <1225000 1000000>,
+					   <1050000 1000000>,
+					   < 875000 1000000>,
+					   < 700000 1000000>,
+					   < 350000 1000000>;
 		};
 
 		cpu4: cpu@100 {
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 6e1dd7ad7bd6..d1d726a1364a 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -78,11 +78,11 @@
 			compatible = "arm,cortex-a15";
 			reg = <0>;
 			clock-frequency = <1500000000>;
-			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg CPG_CORE R8A7791_CLK_Z>;
-			clock-latency = <300000>; /* 300 us */
 			power-domains = <&sysc R8A7791_PD_CA15_CPU0>;
 			next-level-cache = <&L2_CA15>;
+			voltage-tolerance = <1>; /* 1% */
+			clock-latency = <300000>; /* 300 us */
 
 			/* kHz - uV - OPPs unknown yet */
 			operating-points = <1500000 1000000>,
@@ -101,6 +101,16 @@
 			clocks = <&cpg CPG_CORE R8A7791_CLK_Z>;
 			power-domains = <&sysc R8A7791_PD_CA15_CPU1>;
 			next-level-cache = <&L2_CA15>;
+			voltage-tolerance = <1>; /* 1% */
+			clock-latency = <300000>; /* 300 us */
+
+			/* kHz - uV - OPPs unknown yet */
+			operating-points = <1500000 1000000>,
+					   <1312500 1000000>,
+					   <1125000 1000000>,
+					   < 937500 1000000>,
+					   < 750000 1000000>,
+					   < 375000 1000000>;
 		};
 
 		L2_CA15: cache-controller-0 {
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 4abecfc0ca98..1e6439b85a6b 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -70,10 +70,10 @@
 			compatible = "arm,cortex-a15";
 			reg = <0>;
 			clock-frequency = <1500000000>;
-			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg CPG_CORE R8A7793_CLK_Z>;
-			clock-latency = <300000>; /* 300 us */
 			power-domains = <&sysc R8A7793_PD_CA15_CPU0>;
+			voltage-tolerance = <1>; /* 1% */
+			clock-latency = <300000>; /* 300 us */
 
 			/* kHz - uV - OPPs unknown yet */
 			operating-points = <1500000 1000000>,
@@ -92,6 +92,17 @@
 			clock-frequency = <1500000000>;
 			clocks = <&cpg CPG_CORE R8A7793_CLK_Z>;
 			power-domains = <&sysc R8A7793_PD_CA15_CPU1>;
+			voltage-tolerance = <1>; /* 1% */
+			clock-latency = <300000>; /* 300 us */
+
+			/* kHz - uV - OPPs unknown yet */
+			operating-points = <1500000 1000000>,
+					   <1312500 1000000>,
+					   <1125000 1000000>,
+					   < 937500 1000000>,
+					   < 750000 1000000>,
+					   < 375000 1000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 
 		L2_CA15: cache-controller-0 {
-- 
2.11.0

^ permalink raw reply related

* [GIT PULL v2] Renesas ARM Based SoC DT Updates for v4.19
From: Simon Horman @ 2018-07-23 12:04 UTC (permalink / raw)
  To: arm
  Cc: linux-renesas-soc, Olof Johansson, Kevin Hilman, Arnd Bergmann,
	linux-arm-kernel, Magnus Damm, Simon Horman

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC DT updates for v4.19.

Changes since v1:
* Dropped patch which removes MTD partitioning from DT,
  Olof requested more discussion of this
* Trimmed text in tag, as per suggestions from Olof

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm-dt-for-v4.19

for you to fetch changes up to c03e2f12a2967f1639ee53299b72922ee3472528:

  ARM: dts: r8a77470: Use r8a77470-cpg-mssr binding definitions (2018-07-23 13:33:06 +0200)

----------------------------------------------------------------
Renesas ARM Based SoC DT Updates for v4.19

* RZ/G1C (r8a77470) SoC: Use r8a77470-cpg-mssr binding definitions
* Add GR-Peach audio camera shield support with MT9V111 image sensor
* Add initial support for RZ/N1D (r9a06g032) SoC and its RZN1D-DB board
* Use SPDX identifiers in DT for all SoCs and boards
* Add missing OPP properties for all CPUs on various SoCs
* Add missing PMIC nodes to R-Car Gen2 M2-W (r8a7791) based porter board

----------------------------------------------------------------
Geert Uytterhoeven (1):
      ARM: dts: r8a77470: Use r8a77470-cpg-mssr binding definitions

Jacopo Mondi (1):
      ARM: dts: gr-peach: Add GR-Peach audiocamerashield support

Marek Vasut (1):
      ARM: dts: porter: Add missing PMIC nodes

Michel Pollet (3):
      ARM: dts: Renesas R9A06G032 base device tree file
      ARM: dts: Renesas RZN1D-DB Board base file
      ARM: dts: Renesas R9A06G032 SMP enable method

Viresh Kumar (1):
      ARM: dts: r8a77(43|9[013]): Add missing OPP properties for CPUs

Wolfram Sang (1):
      ARM: dts: convert to SPDX identifier for Renesas boards

 MAINTAINERS                                        |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/emev2-kzm9d.dts                  |   5 +-
 arch/arm/boot/dts/emev2.dtsi                       |   5 +-
 arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi  |  79 ++++++++++++++
 arch/arm/boot/dts/iwg20d-q7-common.dtsi            |   5 +-
 arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi           |   5 +-
 arch/arm/boot/dts/r7s72100-genmai.dts              |   5 +-
 arch/arm/boot/dts/r7s72100-gr-peach.dts            |   5 +-
 arch/arm/boot/dts/r7s72100-rskrza1.dts             |   5 +-
 arch/arm/boot/dts/r7s72100.dtsi                    |   5 +-
 arch/arm/boot/dts/r8a73a4-ape6evm.dts              |   5 +-
 arch/arm/boot/dts/r8a73a4.dtsi                     |   5 +-
 arch/arm/boot/dts/r8a7740-armadillo800eva.dts      |   5 +-
 arch/arm/boot/dts/r8a7740.dtsi                     |   5 +-
 arch/arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dts    |   5 +-
 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts            |   5 +-
 arch/arm/boot/dts/r8a7743-iwg20m.dtsi              |   5 +-
 arch/arm/boot/dts/r8a7743-sk-rzg1m.dts             |   5 +-
 arch/arm/boot/dts/r8a7743.dtsi                     |  14 ++-
 .../arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts |   5 +-
 arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts        |   5 +-
 arch/arm/boot/dts/r8a7745-iwg22m.dtsi              |   5 +-
 arch/arm/boot/dts/r8a7745-sk-rzg1e.dts             |   5 +-
 arch/arm/boot/dts/r8a7745.dtsi                     |   5 +-
 arch/arm/boot/dts/r8a77470.dtsi                    |  16 +--
 arch/arm/boot/dts/r8a7778-bockw.dts                |   5 +-
 arch/arm/boot/dts/r8a7778.dtsi                     |   5 +-
 arch/arm/boot/dts/r8a7779-marzen.dts               |   5 +-
 arch/arm/boot/dts/r8a7779.dtsi                     |   5 +-
 arch/arm/boot/dts/r8a7790-lager.dts                |   5 +-
 arch/arm/boot/dts/r8a7790.dtsi                     |  39 +++++--
 arch/arm/boot/dts/r8a7791-koelsch.dts              |   5 +-
 arch/arm/boot/dts/r8a7791-porter.dts               |  38 ++++++-
 arch/arm/boot/dts/r8a7791.dtsi                     |  19 ++--
 arch/arm/boot/dts/r8a7792-blanche.dts              |   5 +-
 arch/arm/boot/dts/r8a7792-wheat.dts                |   5 +-
 arch/arm/boot/dts/r8a7792.dtsi                     |   5 +-
 arch/arm/boot/dts/r8a7793-gose.dts                 |   5 +-
 arch/arm/boot/dts/r8a7793.dtsi                     |  20 ++--
 arch/arm/boot/dts/r8a7794-alt.dts                  |   5 +-
 arch/arm/boot/dts/r8a7794-silk.dts                 |   5 +-
 arch/arm/boot/dts/r8a7794.dtsi                     |   5 +-
 arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi     |   5 +-
 arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi     |   5 +-
 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts        |  28 +++++
 arch/arm/boot/dts/r9a06g032.dtsi                   | 115 +++++++++++++++++++++
 arch/arm/boot/dts/sh73a0-kzm9g.dts                 |   5 +-
 arch/arm/boot/dts/sh73a0.dtsi                      |   5 +-
 49 files changed, 374 insertions(+), 186 deletions(-)
 create mode 100644 arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi
 create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
 create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi

^ permalink raw reply

* [PATCH v2 2/2] compression/qat: add sgl feature
From: Fiona Trahe @ 2018-07-23 13:06 UTC (permalink / raw)
  To: dev; +Cc: pablo.de.lara.guarch, fiona.trahe, tomaszx.jozwiak
In-Reply-To: <1531850150-21767-1-git-send-email-fiona.trahe@intel.com>

This patch adds sgl feature to QAT compression PMD

Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
---
v2 : no change - just resubmit with the changed 1/2 patch 

 config/common_base                       |  1 +
 config/rte_config.h                      |  1 +
 doc/guides/compressdevs/features/qat.ini |  3 +++
 doc/guides/compressdevs/qat_comp.rst     |  2 --
 drivers/compress/qat/qat_comp.c          | 41 ++++++++++++++++++++++++++++----
 drivers/compress/qat/qat_comp.h          |  9 +++++++
 drivers/compress/qat/qat_comp_pmd.c      | 25 ++++++++++++++++++-
 7 files changed, 75 insertions(+), 7 deletions(-)

diff --git a/config/common_base b/config/common_base
index a061c21..6d82b91 100644
--- a/config/common_base
+++ b/config/common_base
@@ -499,6 +499,7 @@ CONFIG_RTE_LIBRTE_PMD_QAT_SYM=n
 # Max. number of QuickAssist devices, which can be detected and attached
 #
 CONFIG_RTE_PMD_QAT_MAX_PCI_DEVICES=48
+CONFIG_RTE_PMD_QAT_COMP_SGL_MAX_SEGMENTS=16
 
 #
 # Compile PMD for virtio crypto devices
diff --git a/config/rte_config.h b/config/rte_config.h
index 28f04b4..a8e4797 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -89,6 +89,7 @@
 /* QuickAssist device */
 /* Max. number of QuickAssist devices which can be attached */
 #define RTE_PMD_QAT_MAX_PCI_DEVICES 48
+#define RTE_PMD_QAT_COMP_SGL_MAX_SEGMENTS 16
 
 /* virtio crypto defines */
 #define RTE_MAX_VIRTIO_CRYPTO 32
diff --git a/doc/guides/compressdevs/features/qat.ini b/doc/guides/compressdevs/features/qat.ini
index 12bfb21..5cd4524 100644
--- a/doc/guides/compressdevs/features/qat.ini
+++ b/doc/guides/compressdevs/features/qat.ini
@@ -5,6 +5,9 @@
 ;
 [Features]
 HW Accelerated      = Y
+OOP SGL In SGL Out  = Y
+OOP SGL In LB  Out  = Y
+OOP LB  In SGL Out  = Y
 Deflate             = Y
 Adler32             = Y
 Crc32               = Y
diff --git a/doc/guides/compressdevs/qat_comp.rst b/doc/guides/compressdevs/qat_comp.rst
index 167f816..8b1270b 100644
--- a/doc/guides/compressdevs/qat_comp.rst
+++ b/doc/guides/compressdevs/qat_comp.rst
@@ -35,8 +35,6 @@ Checksum generation:
 Limitations
 -----------
 
-* Chained mbufs are not yet supported, therefore max data size which can be passed to the PMD in a single mbuf is 64K - 1. If data is larger than this it will need to be split up and sent as multiple operations.
-
 * Compressdev level 0, no compression, is not supported.
 
 * Dynamic Huffman encoding is not yet supported.
diff --git a/drivers/compress/qat/qat_comp.c b/drivers/compress/qat/qat_comp.c
index e8019eb..cbf7614 100644
--- a/drivers/compress/qat/qat_comp.c
+++ b/drivers/compress/qat/qat_comp.c
@@ -21,10 +21,12 @@
 
 int
 qat_comp_build_request(void *in_op, uint8_t *out_msg,
-		       void *op_cookie __rte_unused,
+		       void *op_cookie,
 		       enum qat_device_gen qat_dev_gen __rte_unused)
 {
 	struct rte_comp_op *op = in_op;
+	struct qat_comp_op_cookie *cookie =
+			(struct qat_comp_op_cookie *)op_cookie;
 	struct qat_comp_xform *qat_xform = op->private_xform;
 	const uint8_t *tmpl = (uint8_t *)&qat_xform->qat_comp_req_tmpl;
 	struct icp_qat_fw_comp_req *comp_req =
@@ -44,12 +46,43 @@ qat_comp_build_request(void *in_op, uint8_t *out_msg,
 	comp_req->comp_pars.comp_len = op->src.length;
 	comp_req->comp_pars.out_buffer_sz = rte_pktmbuf_pkt_len(op->m_dst);
 
-	/* sgl */
 	if (op->m_src->next != NULL || op->m_dst->next != NULL) {
-		QAT_DP_LOG(ERR, "QAT PMD doesn't support scatter gather");
-		return -EINVAL;
+		/* sgl */
+		int ret = 0;
+
+		ICP_QAT_FW_COMN_PTR_TYPE_SET(comp_req->comn_hdr.comn_req_flags,
+				QAT_COMN_PTR_TYPE_SGL);
+		ret = qat_sgl_fill_array(op->m_src,
+				rte_pktmbuf_mtophys_offset(op->m_src,
+							op->src.offset),
+				&cookie->qat_sgl_src,
+				op->src.length,
+				RTE_PMD_QAT_COMP_SGL_MAX_SEGMENTS);
+		if (ret) {
+			QAT_DP_LOG(ERR, "QAT PMD Cannot fill sgl array");
+			return ret;
+		}
+
+		ret = qat_sgl_fill_array(op->m_dst,
+				rte_pktmbuf_mtophys_offset(op->m_dst,
+							op->dst.offset),
+				&cookie->qat_sgl_dst,
+				comp_req->comp_pars.out_buffer_sz,
+				RTE_PMD_QAT_COMP_SGL_MAX_SEGMENTS);
+		if (ret) {
+			QAT_DP_LOG(ERR, "QAT PMD Cannot fill sgl array");
+			return ret;
+		}
+
+		comp_req->comn_mid.src_data_addr =
+				cookie->qat_sgl_src_phys_addr;
+		comp_req->comn_mid.dest_data_addr =
+				cookie->qat_sgl_dst_phys_addr;
+		comp_req->comn_mid.src_length = 0;
+		comp_req->comn_mid.dst_length = 0;
 
 	} else {
+		/* flat aka linear buffer */
 		ICP_QAT_FW_COMN_PTR_TYPE_SET(comp_req->comn_hdr.comn_req_flags,
 				QAT_COMN_PTR_TYPE_FLAT);
 		comp_req->comn_mid.src_length = rte_pktmbuf_data_len(op->m_src);
diff --git a/drivers/compress/qat/qat_comp.h b/drivers/compress/qat/qat_comp.h
index 9e6861b..8d315ef 100644
--- a/drivers/compress/qat/qat_comp.h
+++ b/drivers/compress/qat/qat_comp.h
@@ -24,7 +24,16 @@ enum qat_comp_request_type {
 	REQ_COMP_END
 };
 
+struct qat_comp_sgl {
+	qat_sgl_hdr;
+	struct qat_flat_buf buffers[RTE_PMD_QAT_COMP_SGL_MAX_SEGMENTS];
+} __rte_packed __rte_cache_aligned;
+
 struct qat_comp_op_cookie {
+	struct qat_comp_sgl qat_sgl_src;
+	struct qat_comp_sgl qat_sgl_dst;
+	phys_addr_t qat_sgl_src_phys_addr;
+	phys_addr_t qat_sgl_dst_phys_addr;
 };
 
 struct qat_comp_xform {
diff --git a/drivers/compress/qat/qat_comp_pmd.c b/drivers/compress/qat/qat_comp_pmd.c
index 764c053..b89975f 100644
--- a/drivers/compress/qat/qat_comp_pmd.c
+++ b/drivers/compress/qat/qat_comp_pmd.c
@@ -13,7 +13,10 @@ static const struct rte_compressdev_capabilities qat_comp_gen_capabilities[] = {
 				RTE_COMP_FF_ADLER32_CHECKSUM |
 				RTE_COMP_FF_CRC32_ADLER32_CHECKSUM |
 				RTE_COMP_FF_SHAREABLE_PRIV_XFORM |
-				RTE_COMP_FF_HUFFMAN_FIXED,
+				RTE_COMP_FF_HUFFMAN_FIXED |
+				RTE_COMP_FF_OOP_SGL_IN_SGL_OUT |
+				RTE_COMP_FF_OOP_SGL_IN_LB_OUT |
+				RTE_COMP_FF_OOP_LB_IN_SGL_OUT,
 	 .window_size = {.min = 15, .max = 15, .increment = 0} },
 	{RTE_COMP_ALGO_LIST_END, 0, {0, 0, 0} } };
 
@@ -71,7 +74,9 @@ static int
 qat_comp_qp_setup(struct rte_compressdev *dev, uint16_t qp_id,
 		  uint32_t max_inflight_ops, int socket_id)
 {
+	struct qat_qp *qp;
 	int ret = 0;
+	uint32_t i;
 	struct qat_qp_config qat_qp_conf;
 
 	struct qat_qp **qp_addr =
@@ -109,6 +114,24 @@ qat_comp_qp_setup(struct rte_compressdev *dev, uint16_t qp_id,
 	qat_private->qat_dev->qps_in_use[QAT_SERVICE_COMPRESSION][qp_id]
 							= *qp_addr;
 
+	qp = (struct qat_qp *)*qp_addr;
+
+	for (i = 0; i < qp->nb_descriptors; i++) {
+
+		struct qat_comp_op_cookie *cookie =
+				qp->op_cookies[i];
+
+		cookie->qat_sgl_src_phys_addr =
+				rte_mempool_virt2iova(cookie) +
+				offsetof(struct qat_comp_op_cookie,
+				qat_sgl_src);
+
+		cookie->qat_sgl_dst_phys_addr =
+				rte_mempool_virt2iova(cookie) +
+				offsetof(struct qat_comp_op_cookie,
+				qat_sgl_dst);
+	}
+
 	return ret;
 }
 
-- 
2.7.4

^ permalink raw reply related

* [RESEND][PATCH] ASoC: Intel: Power down links before turning off display audio power
From: Sriram Periyasamy @ 2018-07-23 13:02 UTC (permalink / raw)
  To: ALSA ML, Mark Brown
  Cc: Takashi Iwai, Liam Girdwood, Sanyog Kale, Sriram Periyasamy,
	Patches Audio

On certain platforms, Display HDMI HDA codec was not going to sleep state
after the use when links are powered down after turning off the display
power. As per the HW recommendation, links are powered down before turning
off the display power to ensure that the codec goes to sleep state.

Signed-off-by: Sriram Periyasamy <sriramx.periyasamy@intel.com>
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
---
 sound/soc/codecs/hdac_hdmi.c  | 12 +++++-------
 sound/soc/intel/skylake/skl.c | 11 ++++++-----
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c
index 0cdceca2b216..c98c4c2babc9 100644
--- a/sound/soc/codecs/hdac_hdmi.c
+++ b/sound/soc/codecs/hdac_hdmi.c
@@ -2235,12 +2235,6 @@ static int hdac_hdmi_runtime_suspend(struct device *dev)
 	 */
 	snd_hdac_codec_read(hdev, hdev->afg, 0,	AC_VERB_SET_POWER_STATE,
 							AC_PWRST_D3);
-	err = snd_hdac_display_power(bus, false);
-	if (err < 0) {
-		dev_err(bus->dev, "Cannot turn on display power on i915\n");
-		return err;
-	}
-
 	hlink = snd_hdac_ext_bus_get_link(ebus, dev_name(dev));
 	if (!hlink) {
 		dev_err(dev, "hdac link not found\n");
@@ -2249,7 +2243,11 @@ static int hdac_hdmi_runtime_suspend(struct device *dev)
 
 	snd_hdac_ext_bus_link_put(ebus, hlink);
 
-	return 0;
+	err = snd_hdac_display_power(bus, false);
+	if (err < 0)
+		dev_err(bus->dev, "Cannot turn off display power on i915\n");
+
+	return err;
 }
 
 static int hdac_hdmi_runtime_resume(struct device *dev)
diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index 670ff9aaca55..c62e474717ff 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -762,6 +762,12 @@ static void skl_probe_work(struct work_struct *work)
 		}
 	}
 
+	/*
+	 * we are done probing so decrement link counts
+	 */
+	list_for_each_entry(hlink, &ebus->hlink_list, list)
+		snd_hdac_ext_bus_link_put(ebus, hlink);
+
 	if (IS_ENABLED(CONFIG_SND_SOC_HDAC_HDMI)) {
 		err = snd_hdac_display_power(bus, false);
 		if (err < 0) {
@@ -771,11 +777,6 @@ static void skl_probe_work(struct work_struct *work)
 		}
 	}
 
-	/*
-	 * we are done probing so decrement link counts
-	 */
-	list_for_each_entry(hlink, &ebus->hlink_list, list)
-		snd_hdac_ext_bus_link_put(ebus, hlink);
 
 	/* configure PM */
 	pm_runtime_put_noidle(bus->dev);
-- 
2.7.4

^ permalink raw reply related

* [GIT PULL] am654 changes for v4.19 merge window
From: Nishanth Menon @ 2018-07-23 13:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180722064041.GM99251@atomide.com>

On 06:40-20180722, Tony Lindgren wrote:
> * Olof Johansson <olof@lixom.net> [180721 22:28]:
> > On Fri, Jul 20, 2018 at 11:05:16PM -0700, Tony Lindgren wrote:
> > > From: "Tony Lindgren" <tony@atomide.com>
> > > 
> > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> > > 
> > >   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/am654-for-v4.19-signed
> > > 
> > > for you to fetch changes up to d0a064bec75e20a526c7bc0d626912f2660b6e81:
> > > 
> > >   arm64: dts: ti: Add support for AM654 EVM base board (2018-07-18 11:48:36 -0700)
> > > 
> > > ----------------------------------------------------------------
> > > TI AM654 support for v4.19 merge window
> > > 
> > > This branch adds initial support for new Texas Instruments AM654
> > > quad core A53 ARMv8 SoC. It's the first device for TI K3 multicore SoC
> > > architecture.
> > > 
> > > Initially only basic devices are configured, support for more devices
> > > will follow later on. And many of the internal devices familiar from
> > > earlier TI SoCs should work with existing kernel device drivers.
> > 
> > I squinted a bit and merged this into next/dt. Might have been a bit cleaner to
> > split it in a SoC and a DT branch, but either way it's pretty small changes.
> 
> OK yeah I could have done a separate branch for Kconfig changes.

Thanks a bunch.

> 
> > Should the support be enabled in arm64's defconfig?
> 
> Yes it should, Nishanth, care to check Linux next once your
> patches are merged and send a patch for that?

Just checked next-20180723 - Seems to work for me[1]. I was holding off
the defconfig update to get the driver changes for base to get in. I
will send a ping on those and if i dont see any response, will send a
defconfig update by tomorrow.


[1] https://pastebin.ubuntu.com/p/MQ9cFH6Xzd/

-- 
Regards,
Nishanth Menon

^ permalink raw reply

* [PATCH 3/2 for pb/bisect-helper-2] squash! bisect--helper: `bisect_start` shell function partially in C
From: SZEDER Gábor @ 2018-07-23 13:06 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Lars Schneider, Derrick Stolee,
	Nguyễn Thái Ngọc Duy, SZEDER Gábor
In-Reply-To: <20180723130230.22491-1-szeder.dev@gmail.com>

bisect--helper: use oid_to_hex()

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
 builtin/bisect--helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
index fc02f889e6..eac4c27787 100644
--- a/builtin/bisect--helper.c
+++ b/builtin/bisect--helper.c
@@ -547,7 +547,7 @@ static int bisect_start(struct bisect_terms *terms, int no_checkout,
 		if (!get_oid(head, &head_oid) &&
 		    !starts_with(head, "refs/heads/")) {
 			strbuf_reset(&start_head);
-			strbuf_addstr(&start_head, sha1_to_hex(head_oid.hash));
+			strbuf_addstr(&start_head, oid_to_hex(&head_oid));
 		} else if (!get_oid(head, &head_oid) &&
 			   skip_prefix(head, "refs/heads/", &head)) {
 			/*
-- 
2.18.0.408.g42635c01bc


^ permalink raw reply related

* [PATCH v2 1/2] common/qat: add sgl header
From: Fiona Trahe @ 2018-07-23 13:05 UTC (permalink / raw)
  To: dev; +Cc: pablo.de.lara.guarch, fiona.trahe, tomaszx.jozwiak
In-Reply-To: <1531850150-21767-1-git-send-email-fiona.trahe@intel.com>

This patch refactors the sgl struct so it includes a flexible
array of flat buffers as sym and compress PMDs can have
different size sgls.

Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
---
v2 changes:
 - changed max_segs from int32_t to uint16_t to match max allowed by mbuf
 - declared loop index outside for statement to work for all compilers

 drivers/common/qat/qat_common.c | 57 +++++++++++++++++++++++++++++++----------
 drivers/common/qat/qat_common.h | 23 +++++++++--------
 drivers/crypto/qat/qat_sym.c    | 12 +++++----
 drivers/crypto/qat/qat_sym.h    | 14 ++++++++--
 4 files changed, 75 insertions(+), 31 deletions(-)

diff --git a/drivers/common/qat/qat_common.c b/drivers/common/qat/qat_common.c
index c206d3b..81a99c1 100644
--- a/drivers/common/qat/qat_common.c
+++ b/drivers/common/qat/qat_common.c
@@ -8,40 +8,53 @@
 
 int
 qat_sgl_fill_array(struct rte_mbuf *buf, uint64_t buf_start,
-		struct qat_sgl *list, uint32_t data_len)
+		void *list_in, uint32_t data_len,
+		const uint16_t max_segs)
 {
 	int nr = 1;
-
-	uint32_t buf_len = rte_pktmbuf_iova(buf) -
-			buf_start + rte_pktmbuf_data_len(buf);
+	struct qat_sgl *list = (struct qat_sgl *)list_in;
+	/* buf_start allows the first buffer to start at an address before or
+	 * after the mbuf data start. It's used to either optimally align the
+	 * dma to 64 or to start dma from an offset.
+	 */
+	uint32_t buf_len;
+	uint32_t first_buf_len = rte_pktmbuf_data_len(buf) +
+			(rte_pktmbuf_mtophys(buf) - buf_start);
+#if RTE_LOG_DP_LEVEL >= RTE_LOG_DEBUG
+	uint8_t *virt_addr[max_segs];
+	virt_addr[0] = rte_pktmbuf_mtod(buf, uint8_t*) +
+			(rte_pktmbuf_mtophys(buf) - buf_start);
+#endif
 
 	list->buffers[0].addr = buf_start;
 	list->buffers[0].resrvd = 0;
-	list->buffers[0].len = buf_len;
+	list->buffers[0].len = first_buf_len;
 
-	if (data_len <= buf_len) {
+	if (data_len <= first_buf_len) {
 		list->num_bufs = nr;
 		list->buffers[0].len = data_len;
-		return 0;
+		goto sgl_end;
 	}
 
 	buf = buf->next;
+	buf_len = first_buf_len;
 	while (buf) {
-		if (unlikely(nr == QAT_SGL_MAX_NUMBER)) {
-			QAT_LOG(ERR,
-				"QAT PMD exceeded size of QAT SGL entry(%u)",
-					QAT_SGL_MAX_NUMBER);
+		if (unlikely(nr == max_segs)) {
+			QAT_DP_LOG(ERR, "Exceeded max segments in QAT SGL (%u)",
+					max_segs);
 			return -EINVAL;
 		}
 
 		list->buffers[nr].len = rte_pktmbuf_data_len(buf);
 		list->buffers[nr].resrvd = 0;
-		list->buffers[nr].addr = rte_pktmbuf_iova(buf);
-
+		list->buffers[nr].addr = rte_pktmbuf_mtophys(buf);
+#if RTE_LOG_DP_LEVEL >= RTE_LOG_DEBUG
+		virt_addr[nr] = rte_pktmbuf_mtod(buf, uint8_t*);
+#endif
 		buf_len += list->buffers[nr].len;
 		buf = buf->next;
 
-		if (buf_len > data_len) {
+		if (buf_len >= data_len) {
 			list->buffers[nr].len -=
 				buf_len - data_len;
 			buf = NULL;
@@ -50,6 +63,22 @@ qat_sgl_fill_array(struct rte_mbuf *buf, uint64_t buf_start,
 	}
 	list->num_bufs = nr;
 
+sgl_end:
+#if RTE_LOG_DP_LEVEL >= RTE_LOG_DEBUG
+	{
+		uint16_t i;
+		QAT_DP_LOG(INFO, "SGL with %d buffers:", list->num_bufs);
+		for (i = 0; i < list->num_bufs; i++) {
+			QAT_DP_LOG(INFO,
+				"QAT SGL buf %d, len = %d, iova = 0x%012lx",
+				i, list->buffers[i].len,
+				list->buffers[i].addr);
+			QAT_DP_HEXDUMP_LOG(DEBUG, "qat SGL",
+					virt_addr[i], list->buffers[i].len);
+		}
+	}
+#endif
+
 	return 0;
 }
 
diff --git a/drivers/common/qat/qat_common.h b/drivers/common/qat/qat_common.h
index db85d54..b26aa26 100644
--- a/drivers/common/qat/qat_common.h
+++ b/drivers/common/qat/qat_common.h
@@ -10,11 +10,6 @@
 
 /**< Intel(R) QAT device name for PCI registration */
 #define QAT_PCI_NAME	qat
-/*
- * Maximum number of SGL entries
- */
-#define QAT_SGL_MAX_NUMBER	16
-
 #define QAT_64_BTYE_ALIGN_MASK (~0x3f)
 
 /* Intel(R) QuickAssist Technology device generation is enumerated
@@ -31,6 +26,7 @@ enum qat_service_type {
 	QAT_SERVICE_COMPRESSION,
 	QAT_SERVICE_INVALID
 };
+
 #define QAT_MAX_SERVICES		(QAT_SERVICE_INVALID)
 
 /**< Common struct for scatter-gather list operations */
@@ -40,11 +36,17 @@ struct qat_flat_buf {
 	uint64_t addr;
 } __rte_packed;
 
+#define qat_sgl_hdr  struct { \
+	uint64_t resrvd; \
+	uint32_t num_bufs; \
+	uint32_t num_mapped_bufs; \
+}
+
+__extension__
 struct qat_sgl {
-	uint64_t resrvd;
-	uint32_t num_bufs;
-	uint32_t num_mapped_bufs;
-	struct qat_flat_buf buffers[QAT_SGL_MAX_NUMBER];
+	qat_sgl_hdr;
+	/* flexible array of flat buffers*/
+	struct qat_flat_buf buffers[0];
 } __rte_packed __rte_cache_aligned;
 
 /** Common, i.e. not service-specific, statistics */
@@ -64,7 +66,8 @@ struct qat_pci_device;
 
 int
 qat_sgl_fill_array(struct rte_mbuf *buf, uint64_t buf_start,
-		struct qat_sgl *list, uint32_t data_len);
+		void *list_in, uint32_t data_len,
+		const uint16_t max_segs);
 void
 qat_stats_get(struct qat_pci_device *dev,
 		struct qat_common_stats *stats,
diff --git a/drivers/crypto/qat/qat_sym.c b/drivers/crypto/qat/qat_sym.c
index 4ed7d95..8273968 100644
--- a/drivers/crypto/qat/qat_sym.c
+++ b/drivers/crypto/qat/qat_sym.c
@@ -495,8 +495,9 @@ qat_sym_build_request(void *in_op, uint8_t *out_msg,
 		ICP_QAT_FW_COMN_PTR_TYPE_SET(qat_req->comn_hdr.comn_req_flags,
 				QAT_COMN_PTR_TYPE_SGL);
 		ret = qat_sgl_fill_array(op->sym->m_src, src_buf_start,
-				&cookie->qat_sgl_src,
-				qat_req->comn_mid.src_length);
+					&cookie->qat_sgl_src,
+					qat_req->comn_mid.src_length,
+					QAT_SYM_SGL_MAX_NUMBER);
 
 		if (unlikely(ret)) {
 			QAT_DP_LOG(ERR, "QAT PMD Cannot fill sgl array");
@@ -509,9 +510,10 @@ qat_sym_build_request(void *in_op, uint8_t *out_msg,
 				cookie->qat_sgl_src_phys_addr;
 		else {
 			ret = qat_sgl_fill_array(op->sym->m_dst,
-					dst_buf_start,
-					&cookie->qat_sgl_dst,
-						qat_req->comn_mid.dst_length);
+						 dst_buf_start,
+						 &cookie->qat_sgl_dst,
+						 qat_req->comn_mid.dst_length,
+						 QAT_SYM_SGL_MAX_NUMBER);
 
 			if (unlikely(ret)) {
 				QAT_DP_LOG(ERR, "QAT PMD can't fill sgl array");
diff --git a/drivers/crypto/qat/qat_sym.h b/drivers/crypto/qat/qat_sym.h
index e4e1ae8..bc6426c 100644
--- a/drivers/crypto/qat/qat_sym.h
+++ b/drivers/crypto/qat/qat_sym.h
@@ -21,11 +21,21 @@
  */
 #define BPI_MAX_ENCR_IV_LEN ICP_QAT_HW_AES_BLK_SZ
 
+/*
+ * Maximum number of SGL entries
+ */
+#define QAT_SYM_SGL_MAX_NUMBER	16
+
 struct qat_sym_session;
 
+struct qat_sym_sgl {
+	qat_sgl_hdr;
+	struct qat_flat_buf buffers[QAT_SYM_SGL_MAX_NUMBER];
+} __rte_packed __rte_cache_aligned;
+
 struct qat_sym_op_cookie {
-	struct qat_sgl qat_sgl_src;
-	struct qat_sgl qat_sgl_dst;
+	struct qat_sym_sgl qat_sgl_src;
+	struct qat_sym_sgl qat_sgl_dst;
 	phys_addr_t qat_sgl_src_phys_addr;
 	phys_addr_t qat_sgl_dst_phys_addr;
 };
-- 
2.7.4

^ permalink raw reply related

* [PATCH 5/5] ARM: multi_v7_defconfig: Enable support for RZN1D-DB
From: Simon Horman @ 2018-07-23 12:04 UTC (permalink / raw)
  To: linux-renesas-soc
  Cc: linux-arm-kernel, Magnus Damm, Geert Uytterhoeven, Simon Horman
In-Reply-To: <cover.1532346690.git.horms+renesas@verge.net.au>

From: Geert Uytterhoeven <geert+renesas@glider.be>

Enable support for the Renesas RZN1D-DB Board:
  - RZ/N1D (R9A06G032) base SoC support.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 7e1c543162c3..874813d7c08e 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -98,6 +98,7 @@ CONFIG_ARCH_R8A7791=y
 CONFIG_ARCH_R8A7792=y
 CONFIG_ARCH_R8A7793=y
 CONFIG_ARCH_R8A7794=y
+CONFIG_ARCH_R9A06G032=y
 CONFIG_ARCH_SH73A0=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_SIRF=y
-- 
2.11.0

^ permalink raw reply related

* [PATCH 4/5] ARM: shmobile: defconfig: Disable /sbin/hotplug fork-bomb
From: Simon Horman @ 2018-07-23 12:04 UTC (permalink / raw)
  To: linux-renesas-soc
  Cc: linux-arm-kernel, Magnus Damm, Geert Uytterhoeven, Simon Horman
In-Reply-To: <cover.1532346690.git.horms+renesas@verge.net.au>

From: Geert Uytterhoeven <geert+renesas@glider.be>

No recent mainstream system uses the /sbin/hotplug fork-bomb any more.
Commit 7934779a69f1184f29d786b89e77dd14519bd226 ("Driver-Core: disable
/sbin/hotplug by default") disabled it in Kconfig, but the various
defconfigs weren't updated.

According to the systemd requirements, this option must be disabled, as
it slows down the system and confuses udev.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/shmobile_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index a0d88af9ec22..f8faf3729464 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -58,7 +58,6 @@ CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
 CONFIG_CAN=y
 CONFIG_CAN_RCAR=y
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_DMA_CMA=y
-- 
2.11.0

^ permalink raw reply related

* [PATCH 3/5] ARM: shmobile: defconfig: Enable support for RZN1D-DB
From: Simon Horman @ 2018-07-23 12:04 UTC (permalink / raw)
  To: linux-renesas-soc
  Cc: linux-arm-kernel, Magnus Damm, Geert Uytterhoeven, Simon Horman
In-Reply-To: <cover.1532346690.git.horms+renesas@verge.net.au>

From: Geert Uytterhoeven <geert+renesas@glider.be>

Enable support for the Renesas RZN1D-DB Board:
  - RZ/N1D (R9A06G032) base SoC support,
  - Synopsys DesignWare 8250 serial port support.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/shmobile_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 152d16ad7c91..a0d88af9ec22 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -22,6 +22,7 @@ CONFIG_ARCH_R8A7791=y
 CONFIG_ARCH_R8A7792=y
 CONFIG_ARCH_R8A7793=y
 CONFIG_ARCH_R8A7794=y
+CONFIG_ARCH_R9A06G032=y
 CONFIG_ARCH_SH73A0=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_754322=y
@@ -87,6 +88,7 @@ CONFIG_INPUT_ADXL34X=y
 # CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_DW=y
 CONFIG_SERIAL_8250_EM=y
 CONFIG_SERIAL_SH_SCI=y
 CONFIG_I2C_CHARDEV=y
-- 
2.11.0

^ permalink raw reply related

* [PATCH 1/5] ARM: shmobile: defconfig: Drop NET_VENDOR_<FOO>=n
From: Simon Horman @ 2018-07-23 12:04 UTC (permalink / raw)
  To: linux-renesas-soc
  Cc: linux-arm-kernel, Magnus Damm, Geert Uytterhoeven, Simon Horman
In-Reply-To: <cover.1532346690.git.horms+renesas@verge.net.au>

From: Geert Uytterhoeven <geert+renesas@glider.be>

Enabling NET_VENDOR_* Kconfig options does not directly affect the
kernel, so there is no need to explicitly disable them.
The individual network drivers under them are still disabled.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/shmobile_defconfig | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index b49887e86a3d..e30e51809cfc 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -72,22 +72,9 @@ CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_SATA_RCAR=y
 CONFIG_NETDEVICES=y
-# CONFIG_NET_VENDOR_ARC is not set
-# CONFIG_NET_CADENCE is not set
-# CONFIG_NET_VENDOR_BROADCOM is not set
-# CONFIG_NET_VENDOR_CIRRUS is not set
-# CONFIG_NET_VENDOR_FARADAY is not set
-# CONFIG_NET_VENDOR_INTEL is not set
-# CONFIG_NET_VENDOR_MARVELL is not set
-# CONFIG_NET_VENDOR_MICREL is not set
-# CONFIG_NET_VENDOR_NATSEMI is not set
 CONFIG_SH_ETH=y
 CONFIG_RAVB=y
-# CONFIG_NET_VENDOR_SEEQ is not set
 CONFIG_SMSC911X=y
-# CONFIG_NET_VENDOR_STMICRO is not set
-# CONFIG_NET_VENDOR_VIA is not set
-# CONFIG_NET_VENDOR_WIZNET is not set
 CONFIG_MICREL_PHY=y
 CONFIG_SMSC_PHY=y
 CONFIG_INPUT_EVDEV=y
-- 
2.11.0

^ permalink raw reply related

* [PATCH 2/5] ARM: shmobile: defconfig: Enable reset controller support
From: Simon Horman @ 2018-07-23 12:04 UTC (permalink / raw)
  To: linux-renesas-soc
  Cc: linux-arm-kernel, Magnus Damm, Geert Uytterhoeven, Simon Horman
In-Reply-To: <cover.1532346690.git.horms+renesas@verge.net.au>

From: Geert Uytterhoeven <geert+renesas@glider.be>

R-Car Gen2 and RZ/G1 SoCs can make use of the optional reset controller
support in the Renesas CPG/MSSR driver.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index e30e51809cfc..152d16ad7c91 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -192,6 +192,7 @@ CONFIG_AK8975=y
 CONFIG_PWM=y
 CONFIG_PWM_RCAR=y
 CONFIG_PWM_RENESAS_TPU=y
+CONFIG_RESET_CONTROLLER=y
 CONFIG_GENERIC_PHY=y
 CONFIG_PHY_RCAR_GEN2=y
 # CONFIG_DNOTIFY is not set
-- 
2.11.0

^ permalink raw reply related

* [GIT PULL v2] Renesas ARM Based SoC Defconfig Updates for v4.19
From: Simon Horman @ 2018-07-23 12:04 UTC (permalink / raw)
  To: arm
  Cc: linux-renesas-soc, Olof Johansson, Kevin Hilman, Arnd Bergmann,
	linux-arm-kernel, Magnus Damm, Simon Horman

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC defconfig updates for v4.19.

Changes since v1:
* Dropped patch to set CONFIG_LOCALVERSION as requested by Olof
* Dropped patch to Enable MTD command line partition parsing as
  Olof has asked for more discussion on the related DTS change


The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm-defconfig-for-v4.19

for you to fetch changes up to b036e6420b9aed3498cbd0429f12300139cc5a28:

  ARM: multi_v7_defconfig: Enable support for RZN1D-DB (2018-07-23 13:48:02 +0200)

----------------------------------------------------------------
Renesas ARM Based SoC Defconfig Updates for v4.19

multi_v7_defconfig and shmobile_defconfig Enhancement:

* Enable support for recently upstreamed RZN1D-DB board
  in multi_v7_defconfig and shmobile_defconfig. This is
  to give better test coverage.

shmobile_defconfig Clean-Up:

* Drop NET_VENDOR_<FOO>=n

  This reduces the size of the defconfig without any change in the
  resulting kernel config.

shmobile_defconfig Enhancements:

* Disable long deprecated /sbin/hotplug helper

* Enable reset controller support

  This is to give better test coverage.
  This may be used by reset controller support in the Renesas CPG/MSSR
  driver when used by R-Car Gen2 and RZ/G1 SoCs.

----------------------------------------------------------------
Geert Uytterhoeven (5):
      ARM: shmobile: defconfig: Drop NET_VENDOR_<FOO>=n
      ARM: shmobile: defconfig: Enable reset controller support
      ARM: shmobile: defconfig: Enable support for RZN1D-DB
      ARM: shmobile: defconfig: Disable /sbin/hotplug fork-bomb
      ARM: multi_v7_defconfig: Enable support for RZN1D-DB

 arch/arm/configs/multi_v7_defconfig |  1 +
 arch/arm/configs/shmobile_defconfig | 17 +++--------------
 2 files changed, 4 insertions(+), 14 deletions(-)

^ permalink raw reply

* Re: Memory barrier pairing question
From: Paul E. McKenney @ 2018-07-23 12:03 UTC (permalink / raw)
  To: Artem Polyakov; +Cc: perfbook
In-Reply-To: <CAJ2Qj5qCC11ZfE5m1-i1DCegFV=CYm1yP7vDXrjEdPqqxPrF-w@mail.gmail.com>

On Sun, Jul 22, 2018 at 09:52:27PM -0700, Artem Polyakov wrote:
> Thank you, Paul!
> 
> I was wondering why in the following tutorial (section 4.4):
> https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
> They were putting "if ( r1 == r1)" before "isync" and your explanation
> makes it less confusing.
> 
> What was (and somewhat still) confusing in Power ISA (v2.07) is the
> isync description:
> "Executing an isync instruction ensures that all instructions preceding the
> isync instruction have completed before the isync instruction completes,
> and that no subsequent instructions are initiated until after the isync
> instruction completes."
> The term "completes" I guess was understood by me as "committed", but
> according to your explanation, it only means that the instruction is deep
> enough in the pipeline to ensure it's successful commit in the future. And
> the same is with the phrase "no subsequent instructions are initiated until
> after the isync instruction completes". The term "completion" seems obscure
> to me.

I wasn't around for the early PowerPC days, but I could easily imagine
that the word "committed" was a much better match for the much simpler
CPUs of that day.  Things are a bit more complicated these days.  ;-)

> But you did get my question perfectly precise and thank you once again!

Glad that it helped!

							Thanx, Paul

> вс, 22 июля 2018 г. в 19:37, Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> 
> > On Sun, Jul 22, 2018 at 06:42:45PM -0700, Artem Polyakov wrote:
> > > Hello,
> > > I have a question about the following scenario (considering POWER arch):
> > >
> > > initial { x = 0; y = 0; }
> > >
> > > thread0 {
> > >     x = 1;
> > >     lwsync;
> > >     y = 1;
> > > }
> > >
> > > thread1 {
> > >     a = y;
> > >     isync;
> > >     b = x;
> > > }
> > >
> > > Because "isync" is not a memory barrier this example doesn't have
> > > read/write barrier pairing. However, if I understand correctly, lwsync
> > will
> > > ensure that "x = 1" will become visible to thread1 before lwsync is done
> > > and before "y = 1" will become visible. So "isync" here can be sort of
> > > control dependency as it ensures that "a = y" will be performed before
> > "b =
> > > x" and even will flush the pipeline according to POWER9 spec.
> > >
> > > Can someone comment on this scenario and tell if I am right or where I am
> > > wrong.
> >
> > I am not a Power hardware architect, but here is my understanding.
> >
> > The isync waits until all the prior instructions "execute", but for
> > a limited definition of "execute".  One way to think of isync is as
> > an instruction that does not allow subsequent instructions to start
> > until it can be proven that execution really will reach the isync
> > instruction.
> >
> > So given a load, how could it be that execution would be prevented
> > from reaching the isync instruction?  One possibility is a SEGV.
> > But once address translation completes successfully, SEGV cannot
> > happen.  So isync doesn't need to wait for the load to return an
> > actual value, but instead only for its execution to reach a point
> > where the hardware knows that a value will eventually be returned.
> >
> > And that is why you need a compare and conditional branch before the
> > isync to ensure that the load has completed.  In that case, the
> > hardware cannot prove that execution will actually reach the isync
> > until the load completes, the compare sets the condition code,
> > and the branch condition is evaluated.  Therefore, anything after
> > the compare-branch-isync series cannot start executing until after
> > the load returns its value.
> >
> > Make sense, or am I missing the point of your question?
> >
> >                                                         Thanx, Paul
> >
> >


^ permalink raw reply

* Re: [PATCH 1/3] f2fs: turn off atomic writes when deteting abnormal behaviors
From: Jaegeuk Kim @ 2018-07-23 13:03 UTC (permalink / raw)
  To: Chao Yu; +Cc: linux-kernel, linux-f2fs-devel
In-Reply-To: <29151284-ef34-2eb2-1060-7e214fe8834a@huawei.com>

On 07/16, Chao Yu wrote:
> On 2018/7/15 9:11, Jaegeuk Kim wrote:
> > In order to prevent abusing atomic writes by abnormal users, we've added a
> > threshold, 20% over memory footprint, which disallows further atomic writes.
> > Previously, however, SQLite doesn't know the files became normal, so that
> > it could write stale data and commit on revoked normal database file.
> > 
> > Once f2fs detects such the abnormal behavior, this patch simply disables
> > all the atomic operations such as:
> > - write_begin() gives EINVAL to avoid stale data writes, and SQLite will call
> >   F2FS_IOC_ABORT_VOLATILE_WRITE to notify aborting the transaction,
> > - F2FS_IOC_START_ATOMIC_WRITE gives EINVAL for SQLite to fall back normal
> >   journal_mode,
> > - F2FS_IOC_COMMIT_ATOMIC_WRITE gives EINVAL, if the file was revoked, so that
> >   Framework retries to submit the transaction given propagated SQLite error.
> > 
> > Note that, this patch also turns off atomic operations, if foreground GC tries
> > to move atomic files too frequently.
> 
> Well, how about just keeping original implementation: shutdown atomic write for
> those files which are really affect fggc? Since intention of the original
> behavior is targeting to abnormal atomic write usage, e.g. open atomic_write
> file for very long time, then fggc will be blocked each time when moving its
> block. So shutdown it, fggc will recover.

The point here is stopping sqlite to keep going wrong data writes even after
we already revoked blocks.

Thanks,

> 
> Thanks,
> 
> > 
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> >  fs/f2fs/data.c    |  7 ++++---
> >  fs/f2fs/f2fs.h    |  4 ++--
> >  fs/f2fs/file.c    |  6 +++++-
> >  fs/f2fs/gc.c      |  4 +---
> >  fs/f2fs/segment.c | 21 +++++++++++----------
> >  5 files changed, 23 insertions(+), 19 deletions(-)
> > 
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 5e53d210e222..c9e75aa61c24 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -2247,8 +2247,9 @@ static int f2fs_write_begin(struct file *file, struct address_space *mapping,
> >  	trace_f2fs_write_begin(inode, pos, len, flags);
> >  
> >  	if (f2fs_is_atomic_file(inode) &&
> > -			!f2fs_available_free_memory(sbi, INMEM_PAGES)) {
> > -		err = -ENOMEM;
> > +			(is_sbi_flag_set(sbi, SBI_DISABLE_ATOMIC_WRITE) ||
> > +			!f2fs_available_free_memory(sbi, INMEM_PAGES))) {
> > +		err = -EINVAL;
> >  		drop_atomic = true;
> >  		goto fail;
> >  	}
> > @@ -2331,7 +2332,7 @@ static int f2fs_write_begin(struct file *file, struct address_space *mapping,
> >  	f2fs_put_page(page, 1);
> >  	f2fs_write_failed(mapping, pos + len);
> >  	if (drop_atomic)
> > -		f2fs_drop_inmem_pages_all(sbi, false);
> > +		f2fs_disable_atomic_write(sbi);
> >  	return err;
> >  }
> >  
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 4d8b1de83143..1d5c8d543eda 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -621,7 +621,6 @@ enum {
> >  
> >  enum {
> >  	GC_FAILURE_PIN,
> > -	GC_FAILURE_ATOMIC,
> >  	MAX_GC_FAILURE
> >  };
> >  
> > @@ -1066,6 +1065,7 @@ enum {
> >  	SBI_POR_DOING,				/* recovery is doing or not */
> >  	SBI_NEED_SB_WRITE,			/* need to recover superblock */
> >  	SBI_NEED_CP,				/* need to checkpoint */
> > +	SBI_DISABLE_ATOMIC_WRITE,		/* turn off atomic write */
> >  };
> >  
> >  enum {
> > @@ -2833,7 +2833,7 @@ void f2fs_destroy_node_manager_caches(void);
> >   */
> >  bool f2fs_need_SSR(struct f2fs_sb_info *sbi);
> >  void f2fs_register_inmem_page(struct inode *inode, struct page *page);
> > -void f2fs_drop_inmem_pages_all(struct f2fs_sb_info *sbi, bool gc_failure);
> > +void f2fs_disable_atomic_write(struct f2fs_sb_info *sbi);
> >  void f2fs_drop_inmem_pages(struct inode *inode);
> >  void f2fs_drop_inmem_page(struct inode *inode, struct page *page);
> >  int f2fs_commit_inmem_pages(struct inode *inode);
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index 6880c6f78d58..b029a4ed3bb0 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -1682,6 +1682,9 @@ static int f2fs_ioc_start_atomic_write(struct file *filp)
> >  	if (!S_ISREG(inode->i_mode))
> >  		return -EINVAL;
> >  
> > +	if (is_sbi_flag_set(F2FS_I_SB(inode), SBI_DISABLE_ATOMIC_WRITE))
> > +		return -EINVAL;
> > +
> >  	ret = mnt_want_write_file(filp);
> >  	if (ret)
> >  		return ret;
> > @@ -1750,7 +1753,6 @@ static int f2fs_ioc_commit_atomic_write(struct file *filp)
> >  		ret = f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true);
> >  		if (!ret) {
> >  			clear_inode_flag(inode, FI_ATOMIC_FILE);
> > -			F2FS_I(inode)->i_gc_failures[GC_FAILURE_ATOMIC] = 0;
> >  			stat_dec_atomic_write(inode);
> >  		}
> >  	} else {
> > @@ -1853,6 +1855,8 @@ static int f2fs_ioc_abort_volatile_write(struct file *filp)
> >  		ret = f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true);
> >  	}
> >  
> > +	clear_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
> > +
> >  	inode_unlock(inode);
> >  
> >  	mnt_drop_write_file(filp);
> > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> > index 9093be6e7a7d..6d762f3cdfc7 100644
> > --- a/fs/f2fs/gc.c
> > +++ b/fs/f2fs/gc.c
> > @@ -629,7 +629,6 @@ static void move_data_block(struct inode *inode, block_t bidx,
> >  		goto out;
> >  
> >  	if (f2fs_is_atomic_file(inode)) {
> > -		F2FS_I(inode)->i_gc_failures[GC_FAILURE_ATOMIC]++;
> >  		F2FS_I_SB(inode)->skipped_atomic_files[gc_type]++;
> >  		goto out;
> >  	}
> > @@ -745,7 +744,6 @@ static void move_data_page(struct inode *inode, block_t bidx, int gc_type,
> >  		goto out;
> >  
> >  	if (f2fs_is_atomic_file(inode)) {
> > -		F2FS_I(inode)->i_gc_failures[GC_FAILURE_ATOMIC]++;
> >  		F2FS_I_SB(inode)->skipped_atomic_files[gc_type]++;
> >  		goto out;
> >  	}
> > @@ -1100,7 +1098,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
> >  		if (has_not_enough_free_secs(sbi, sec_freed, 0)) {
> >  			if (skipped_round > MAX_SKIP_ATOMIC_COUNT &&
> >  				skipped_round * 2 >= round)
> > -				f2fs_drop_inmem_pages_all(sbi, true);
> > +				f2fs_disable_atomic_write(sbi);
> >  			segno = NULL_SEGNO;
> >  			goto gc_more;
> >  		}
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index 9efce174c51a..05877a2f1894 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -274,11 +274,14 @@ static int __revoke_inmem_pages(struct inode *inode,
> >  	return err;
> >  }
> >  
> > -void f2fs_drop_inmem_pages_all(struct f2fs_sb_info *sbi, bool gc_failure)
> > +void f2fs_disable_atomic_write(struct f2fs_sb_info *sbi)
> >  {
> >  	struct list_head *head = &sbi->inode_list[ATOMIC_FILE];
> >  	struct inode *inode;
> >  	struct f2fs_inode_info *fi;
> > +
> > +	/* just turn it off */
> > +	set_sbi_flag(sbi, SBI_DISABLE_ATOMIC_WRITE);
> >  next:
> >  	spin_lock(&sbi->inode_lock[ATOMIC_FILE]);
> >  	if (list_empty(head)) {
> > @@ -290,17 +293,16 @@ void f2fs_drop_inmem_pages_all(struct f2fs_sb_info *sbi, bool gc_failure)
> >  	spin_unlock(&sbi->inode_lock[ATOMIC_FILE]);
> >  
> >  	if (inode) {
> > -		if (gc_failure) {
> > -			if (fi->i_gc_failures[GC_FAILURE_ATOMIC])
> > -				goto drop;
> > -			goto skip;
> > +		inode_lock(inode);
> > +		/* need to check whether it was already revoked */
> > +		if (f2fs_is_atomic_file(inode)) {
> > +			f2fs_drop_inmem_pages(inode);
> > +			set_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
> >  		}
> > -drop:
> > -		set_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
> > -		f2fs_drop_inmem_pages(inode);
> > +		inode_unlock(inode);
> >  		iput(inode);
> >  	}
> > -skip:
> > +
> >  	congestion_wait(BLK_RW_ASYNC, HZ/50);
> >  	cond_resched();
> >  	goto next;
> > @@ -320,7 +322,6 @@ void f2fs_drop_inmem_pages(struct inode *inode)
> >  	mutex_unlock(&fi->inmem_lock);
> >  
> >  	clear_inode_flag(inode, FI_ATOMIC_FILE);
> > -	fi->i_gc_failures[GC_FAILURE_ATOMIC] = 0;
> >  	stat_dec_atomic_write(inode);
> >  }
> >  
> > 

^ permalink raw reply

* [PATCH 2/2] travis-ci: fail if Coccinelle static analysis found something to transform
From: SZEDER Gábor @ 2018-07-23 13:02 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Lars Schneider, Derrick Stolee,
	Nguyễn Thái Ngọc Duy, SZEDER Gábor
In-Reply-To: <20180723130230.22491-1-szeder.dev@gmail.com>

Coccinelle's and in turn 'make coccicheck's exit code only indicates
that Coccinelle managed to finish its analysis without any errors
(e.g. no unknown --options, no missing files, no syntax errors in the
semantic patches, etc.), but it doesn't indicate whether it found any
undesired code patterns to transform or not.  To find out the latter,
one has to look closer at 'make coccicheck's standard output and look
for lines like:

  SPATCH result: contrib/coccinelle/<something>.cocci.patch

And this only indicates that there is something to transform, but to
see what the suggested transformations are one has to actually look
into those '*.cocci.patch' files.

This makes the automated static analysis build job on Travis CI not
particularly useful, because it neither draws our attention to
Coccinelle's findings, nor shows the actual findings.  Consequently,
new topics introducing undesired code patterns graduated to master
on several occasions without anyone noticing.

The only way to draw attention in such an automated setting is to fail
the build job.  Therefore, modify the 'ci/run-static-analysis.sh'
build script to check all the resulting '*.cocci.patch' files, and
fail the build job if any of them turns out to be not empty.  Include
those files' contents, i.e. Coccinelle's suggested transformations, in
the build job's trace log, so we'll know why it failed.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
 ci/run-static-analysis.sh | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/ci/run-static-analysis.sh b/ci/run-static-analysis.sh
index fa719c9ef9..5688f261d0 100755
--- a/ci/run-static-analysis.sh
+++ b/ci/run-static-analysis.sh
@@ -7,4 +7,23 @@
 
 make --jobs=2 coccicheck
 
+set +x
+
+fail=
+for cocci_patch in contrib/coccinelle/*.patch
+do
+	if test -s "$cocci_patch"
+	then
+		echo "$(tput setaf 1)Coccinelle suggests the following changes in '$cocci_patch':$(tput sgr0)"
+		cat "$cocci_patch"
+		fail=UnfortunatelyYes
+	fi
+done
+
+if test -n "$fail"
+then
+	echo "$(tput setaf 1)error: Coccinelle suggested some changes$(tput sgr0)"
+	exit 1
+fi
+
 save_good_tree
-- 
2.18.0.408.g42635c01bc


^ permalink raw reply related

* [PATCH 1/2] travis-ci: run Coccinelle static analysis with two parallel jobs
From: SZEDER Gábor @ 2018-07-23 13:02 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Lars Schneider, Derrick Stolee,
	Nguyễn Thái Ngọc Duy, SZEDER Gábor
In-Reply-To: <20180723130230.22491-1-szeder.dev@gmail.com>

Currently the static analysis build job runs Coccinelle using a single
'make' job.  Using two parallel jobs cuts down the build job's run
time from around 10-12mins to 6-7mins, sometimes even under 6mins
(there is quite large variation between build job runtimes).  More
than two parallel jobs don't seem to bring further runtime benefits.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
 ci/run-static-analysis.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ci/run-static-analysis.sh b/ci/run-static-analysis.sh
index fe4ee4e06b..fa719c9ef9 100755
--- a/ci/run-static-analysis.sh
+++ b/ci/run-static-analysis.sh
@@ -5,6 +5,6 @@
 
 . ${0%/*}/lib-travisci.sh
 
-make coccicheck
+make --jobs=2 coccicheck
 
 save_good_tree
-- 
2.18.0.408.g42635c01bc


^ permalink raw reply related

* [PATCH 0/2] travis-ci: fail if Coccinelle found something to transform
From: SZEDER Gábor @ 2018-07-23 13:02 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Lars Schneider, Derrick Stolee,
	Nguyễn Thái Ngọc Duy, SZEDER Gábor

The first patch makes the static analysis build job on Travis CI
faster by running it with 'make -j2'.

The second patch makes it more more useful by failing the build job if
Coccinelle finds something to transform, thereby drawing our attention
to undesired code patterns trying to enter the codebase.


With these patches applied, the static analysis build job would fail
on current 'pu' because of two small issues on two branches:

  - js/range-diff: Dscho has sent out v4 of this series over the
    weekend, which already incorporates Coccinelle's suggestion, so
    it's basically done.
  
  - pb/bisect-helper-2: this topic has not seen an update in about 9
    months, so I'll send a followup patch 3/2 to be applied on top or
    squashed in, whichever is deemed better.


SZEDER Gábor (2):
  travis-ci: run Coccinelle static analysis with two parallel jobs
  travis-ci: fail if Coccinelle static analysis found something to
    transform

 ci/run-static-analysis.sh | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

-- 
2.18.0.408.g42635c01bc


^ permalink raw reply

* Re: [Bug 200105] High paging activity as soon as the swap is touched (with steps and code to reproduce it)
From: Michal Hocko @ 2018-07-23 13:02 UTC (permalink / raw)
  To: Daniel Jordan
  Cc: john terragon, linux-mm@kvack.org,
	bugzilla-daemon@bugzilla.kernel.org, Andrew Morton, Daniel Jordan
In-Reply-To: <f20b1529-fcb9-8d0a-6259-fe76977e00d6@gmail.com>

[I am really sorry to be slow on responding]

On Sat 21-07-18 10:39:05, Daniel Jordan wrote:
> John's issue only happens using a LUKS encrypted swap partition,
> unencrypted swap or swap encrypted without LUKS works fine.
> 
> In one test (out5.txt) where most system memory is taken by anon pages
> beforehand, the heavy direct reclaim that Michal noticed lasts for 24
> seconds, during which on average if I've crunched my numbers right,
> John's test program was allocating at 4MiB/s, the system overall
> (pgalloc_normal) was allocating at 235MiB/s, and the system was
> swapping out (pswpout) at 673MiB/s. pgalloc_normal and pswpout stay
> roughly the same each second, no big swings.
>
> Is the disparity between allocation and swapout rate expected?
> 
> John ran perf during another test right before the last test program
> was started (this doesn't include the initial large allocation
> bringing the system close to swapping).  The top five allocators
> (kmem:mm_page_alloc):
> 
> # Overhead      Pid:Command
> # ........  .......................
> #
>     48.45%     2005:memeater     # the test program
>     32.08%       73:kswapd0
>      3.16%     1957:perf_4.17
>      1.41%     1748:watch
>      1.16%     2043:free

Huh, kswapd allocating memory sounds really wrong here. Is it possible
that the swap device driver is double buffering and allocating a new
page for each one to swap out?
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply

* Re: [PATCH] brcmfmac: fix regression in parsing NVRAM for multiple devices
From: Arend van Spriel @ 2018-07-23 12:01 UTC (permalink / raw)
  To: Rafał Miłecki, Kalle Valo
  Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
	Pieter-Paul Giesberts, Chung-Hsien Hsu, Aditya Xavier,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	Rafał Miłecki
In-Reply-To: <20180722214625.12101-1-zajec5@gmail.com>

On 7/22/2018 11:46 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> NVRAM is designed to work with Broadcom's SDK Linux kernel which fakes
> PCI domain 0 for all internal MMIO devices. Since official Linux kernel
> uses platform devices for that purpose there is a mismatch in numbering
> PCI domains.
>
> There used to be a fix for that problem but it was accidentally dropped
> during the last firmware loading rework. That resulted in brcmfmac not
> being able to extract device specific NVRAM content and all kind of
> calibration problems.
>
> Reported-by: Aditya Xavier <adityaxavier@gmail.com>
> Fixes: 2baa3aaee27f ("brcmfmac: introduce brcmf_fw_alloc_request() function")
> Cc: stable@vger.kernel.org # v4.17+

oops. my bad.

Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 45928b5b8d97..4fffa6988087 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -1785,7 +1785,8 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
>   	fwreq->items[BRCMF_PCIE_FW_CODE].type = BRCMF_FW_TYPE_BINARY;
>   	fwreq->items[BRCMF_PCIE_FW_NVRAM].type = BRCMF_FW_TYPE_NVRAM;
>   	fwreq->items[BRCMF_PCIE_FW_NVRAM].flags = BRCMF_FW_REQF_OPTIONAL;
> -	fwreq->domain_nr = pci_domain_nr(devinfo->pdev->bus);
> +	/* NVRAM reserves PCI domain 0 for Broadcom's SDK faked bus */
> +	fwreq->domain_nr = pci_domain_nr(devinfo->pdev->bus) + 1;
>   	fwreq->bus_nr = devinfo->pdev->bus->number;
>
>   	return fwreq;
>

^ permalink raw reply

* [LTP] [PATCH] read_all: Define FNM_EXTMATCH if not already (like under musl).
From: Petr Vorel @ 2018-07-23 13:01 UTC (permalink / raw)
  To: ltp
In-Reply-To: <1529939900-28259-1-git-send-email-daniel.diaz@linaro.org>

Hi Daniel,

> With musl, FNM_EXTMATCH is not defined:
> | read_all.c: In function 'read_test':
> | read_all.c:201:41: error: 'FNM_EXTMATCH' undeclared (first use in this function); did you mean 'FNM_NOMATCH'?
> |   if (exclude && !fnmatch(exclude, path, FNM_EXTMATCH)) {
> |                                          ^~~~~~~~~~~~
> |                                          FNM_NOMATCH
> | read_all.c:201:41: note: each undeclared identifier is reported only once for each function it appears in
> | <builtin>: recipe for target 'read_all' failed
> | make[4]: *** [read_all] Error 1

> Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
> ---
>  testcases/kernel/fs/read_all/read_all.c | 4 ++++
>  1 file changed, 4 insertions(+)

> diff --git a/testcases/kernel/fs/read_all/read_all.c b/testcases/kernel/fs/read_all/read_all.c
> index 42babae..f68217b 100644
> --- a/testcases/kernel/fs/read_all/read_all.c
> +++ b/testcases/kernel/fs/read_all/read_all.c
> @@ -60,6 +60,10 @@
>  #define MAX_PATH 4096
>  #define MAX_DISPLAY 40

> +#if !defined(FNM_EXTMATCH)
Maybe just
#ifndef FNM_EXTMATCH

And maybe it'd be good to put this definition into include/lapi/fnmatch.h
(create it), so it can be reused.

FYI: LTP isn't musl ready atm.

> +#define FNM_EXTMATCH 0
> +#endif
> +
>  struct queue {
>  	sem_t sem;
>  	int front;


Kind regards,
Petr

^ permalink raw reply

* Re: [PATCH V3] xen/altp2m: set access_required properly for all altp2ms
From: George Dunlap @ 2018-07-23 13:00 UTC (permalink / raw)
  To: Julien Grall, Jan Beulich, Razvan Cojocaru
  Cc: Tim Deegan, Stefano Stabellini, Wei Liu, George Dunlap,
	Andrew Cooper, Ian Jackson, Xen-devel, tamas
In-Reply-To: <5252abfd-f242-fb5f-b383-1889aa63c8f4@arm.com>

On 07/23/2018 01:58 PM, Julien Grall wrote:
> Hi,
> 
> On 23/07/18 12:40, George Dunlap wrote:
>> On 07/16/2018 09:53 AM, Jan Beulich wrote:
>>>>>> On 16.07.18 at 10:35, <rcojocaru@bitdefender.com> wrote:
>>>> On 06/28/2018 07:19 PM, Tamas K Lengyel wrote:
>>>>> On Thu, Jun 28, 2018 at 1:54 AM Razvan Cojocaru
>>>>> <rcojocaru@bitdefender.com> wrote:
>>>>>>
>>>>>> For the hostp2m, access_required starts off as 0, then it can be
>>>>>> set with xc_domain_set_access_required(). However, all the altp2ms
>>>>>> set it to 1 on init, and ignore both the hostp2m and the hypercall.
>>>>>> This patch sets access_required to the value from the hostp2m
>>>>>> on altp2m init, and propagates the values received via hypercall
>>>>>> to all the active altp2ms, when applicable.
>>>>>>
>>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>>>
>>>>> LGTM
>>>>>
>>>>> Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
>>>>
>>>> Thanks Tamas!
>>>>
>>>> Does the patch need additional action before it can go in (sorry for
>>>> the
>>>> noise if it only hasn't gone in because it at the back of the queue).
>>>
>>> Once again - George's ack is missing. Please remember that generally
>>> it's the submitter to chase ack-s, not reviewers or committers.
>>
>> Do we need Julien's ack too?
> 
> Ravzan and Tamas are maintaining arm/mem_access.c. So Tamas's ack should
> be enough here.

Ah, got it.

> Just in case:
> 
> Acked-by: Julien Grall <julien.grall@arm.com>

Thanks.
 -G

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply

* Re: [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
From: De Lara Guarch, Pablo @ 2018-07-23 13:00 UTC (permalink / raw)
  To: Verma, Shally
  Cc: dev@dpdk.org, Athreya, Narayana Prasad, Challa, Mahipal,
	Gupta, Ashish, Sahu, Sunila, Sahu, Sunila
In-Reply-To: <CY4PR0701MB363474EF64B1AF37BC97537BF0560@CY4PR0701MB3634.namprd07.prod.outlook.com>



> -----Original Message-----
> From: Verma, Shally [mailto:Shally.Verma@cavium.com]
> Sent: Monday, July 23, 2018 1:53 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; Athreya, Narayana Prasad
> <NarayanaPrasad.Athreya@cavium.com>; Challa, Mahipal
> <Mahipal.Challa@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>;
> Sahu, Sunila <Sunila.Sahu@cavium.com>; Sahu, Sunila
> <Sunila.Sahu@cavium.com>
> Subject: RE: [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
> 
> Hi Pablo
> 
> >-----Original Message-----
> >From: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> >Sent: 23 July 2018 18:07
> >To: Verma, Shally <Shally.Verma@cavium.com>
> >Cc: dev@dpdk.org; Athreya, Narayana Prasad
> ><NarayanaPrasad.Athreya@cavium.com>; Challa, Mahipal
> ><Mahipal.Challa@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>;
> >Sahu, Sunila <Sunila.Sahu@cavium.com>; Sahu, Sunila
> ><Sunila.Sahu@cavium.com>
> >Subject: RE: [PATCH v3 4/5] compress/zlib: support burst
> >enqueue/dequeue
> >
> >External Email
> >
> >> -----Original Message-----
> >> From: Shally Verma [mailto:shally.verma@caviumnetworks.com]
> >> Sent: Saturday, July 21, 2018 7:18 PM
> >> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> >> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> >> mchalla@caviumnetworks.com; ashish.gupta@caviumnetworks.com;
> >> sunila.sahu@caviumnetworks.com; Sunila Sahu
> >> <ssahu@caviumnetworks.com>
> >> Subject: [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
> >>
> >> From: Sunila Sahu <ssahu@caviumnetworks.com>
> >>
> >> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> >> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> >> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> >> ---
> >>  drivers/compress/zlib/zlib_pmd.c | 254
> >
> >...
> >
> >> +def_end:
> >> +     /* Update op stats */
> >> +     switch (op->status) {
> >> +     case RTE_COMP_OP_STATUS_SUCCESS:
> >> +             op->consumed += strm->total_in;
> >
> >Compilation issue here:
> >
> >drivers/compress/zlib/zlib_pmd.c:94:16: error: this statement may fall through
> [-Werror=implicit-fallthrough=]
> >   op->consumed += strm->total_in;
> >   ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
> >
> >I think you are missing a "/* Fall-through */" comment here.
> OK. I will send next patch immediately with this fix. But which compiler version
> you following, since this isn't seen during our build (which we did on multiple
> platforms) so want to understand what is the environment we need to have to
> avoid such regressions.

I see this with gcc 7.2.1 (on Fedora 27).

Pablo

> 
> Thanks
> Shally
> 
> >
> >Thanks,
> >Pablo
> >
> >> +     case RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED:
> >> +             op->produced += strm->total_out;
> >> +             break;

^ permalink raw reply

* [Bug 107334] Artifacts in Unigine Valley with RX 580
From: bugzilla-daemon @ 2018-07-23 12:59 UTC (permalink / raw)
  To: dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 1483 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=107334

            Bug ID: 107334
           Summary: Artifacts in Unigine Valley with RX 580
           Product: Mesa
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: cwidmer@umbrox.de
        QA Contact: dri-devel@lists.freedesktop.org

Created attachment 140780
  --> https://bugs.freedesktop.org/attachment.cgi?id=140780&action=edit
Screenshot showing the issue

In a certain scene during the Unigine Valley benchmark, render artifacts
briefly flash on the screen multiple times. This does not occur with the same
card in another machine running Windows 10 -- neither with the DirectX 11 nor
with the OpenGL renderer -- and it does also not occur on this machine when
using a NVIDIA GeForce GTX 660 instead of the RX 580.
When I tried to get an apitrace, the benchmark slows down a lot during the
scene, skipping parts of it and not showing the artifacts. Additionally, the
replay is stuck on the loading screen and major shader compiler errors are
thrown.

I am using Gentoo with kernel 4.17.9 (with the gentoo patchset) and mesa git
(commit d0ee0a0a5d5fb658c87fed82cbcf9b48437abb2c).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2995 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.